Now, as chatchipiti, who are shooting vines to explain gritty, it just gave one answer.
Is that that I should invite my very good friends?
And as I can, I will officially say, the friend of the Godev room.
Here's to the again.
And he gladly accept it.
And he even came up with an actual presentation of a go-go for sitting in a race car, drinking some green tea.
So, give a round of applause.
Okay, perfect.
Thank you.
Well, we're going to bring for a speed.
I say, let's talk about the new green tea, go to graduate collector.
So, let me introduce myself a bit.
I'm so familiar at Onan.
That is an AI agent in the cloud.
I'm an open source and to see as that in the computer.
I really love open source.
This is why, first thing is, probably my favorite conference in the world.
I'm not big fan of the knowledge of understanding things, how things work and the truth.
Also, I have a book out there.
I wrote more on a race API as a moment ago.
But recently, I started the blog about how things work and the truth.
So, if you, well, there's a series of posts about the compiler.
Another one about postgres.
I'm going to write another about five systems.
I'm about a development time.
Very soon.
So, yep.
That's me.
We are going to talk here about the new green tea garbage collector.
But for that, I want to start explaining how the current garbage collector,
the quality of the collector that is in the 1.25 version, is it works.
And then I'm going to talk a bit about the memory indicator,
because I think it's interesting for understanding better how the green tea garbage collector works.
And then I'm going to get into the real innovation behind the green tea garbage collector.
Well, as always, this is something that I, I'm not in the go team or something like that.
I just learned this by reading the code, exploring things,
reading the documentation, all that stuff.
So, doing my investigation, doing my homework.
So, there's some simplification.
So, oversimplification, certain things.
But I think it explained more or less how it works.
So, let's jump into the go classic garbage collector.
The one that is in the 1.25 version.
The go garbage collector, it's not super special in that sense.
It's a regular market sweep garbage collector.
It's a technique that is using many other garbage collectors.
The technique in the market sweep is finding all the root objects.
So, the objects that are truly accessible for sure,
because they are global buy-outs, for example,
and start exploring them and finding and tracing objects,
finding what objects point to another objects, et cetera,
and marking them.
And whenever you finish marking everything, whatever it is,
and being rich, whatever it is, and being marked,
it's a ritual.
So, you can swipe that.
So, that's the market sweep algorithm.
Let's see here.
This is an example of how will work.
The first thing is those root objects, those root objects
from global buy-outs, and the stack of the go routines.
So, it is going to scan the stacks of the go routines,
scan all the global buy-outs, and try to find objects
that point to something.
For example, imagine that we have two alive group objects,
and they have two pointers.
So, it's going to say, oh, I have two objects here
that I have to scan.
Because I need to scan those objects,
and can be many, what I'm going to do is accumulate those objects
in a work stack.
It's important to understand that that's a stack,
because it's a last in-first out,
and that gives the map face of the garbage collector's set in properties.
So, let's trace how it goes.
I found these two objects.
I put those two objects in the stack.
So, I pick from the top of the stack,
and I take that object.
So, I start scanning that object.
While I'm scanning that object, I found this or the one.
So, I put that in the stack,
and mark this as a visit, it's already done,
and done with that object.
So, then I have to scan another object.
So, I pick one from the stack from the top of the stack.
There's one that I just added.
So, it's there.
I visited that.
I keep going and putting in the stack,
scanning, putting in the stack,
scanning, putting in the stack, scanning.
It's important to see that this stack,
and that is going to lead into a depth-first scanning.
So, we are moving down the path of one object.
And whenever we finish with that,
we go back and keep going and get all over the ramifications
of that objects.
And whenever I reach that point,
where I visited the one, I visited that one.
There's no more objects.
So, I go into go back to the stack,
and pick one from the top,
that is the second one that we found.
So, we go there and do all the scanning,
the scanning, and find the objects,
putting in the stack, and all the stuff.
Now, I at the result point where the work queue is empty.
So, what the work stack is empty.
So, everything else in the memory,
it's unreachable.
So, I can just swipe that.
So, this is how the mark face of the go garbage collector works.
I'm going to focus on the mark face,
because the green tea innovation,
it's basically down in the mark face.
The sweeping of the unreachable objects,
it's down exactly the same in both garbage collectors.
So, let's talk a bit about the memory locator.
The memory locator is a piece of the runtime
that decides where your data,
where your variables are stored.
So, whenever you ask for a new object,
it's going to ask the memory locator
and the memory locator is going to follow up very smart approach, actually.
It's going to divide all the data
in what they call mspans.
mspans is a memory spam,
it's just a set of pages, a set of memory pages
of 8kW each.
That are that only contains objects of that size.
That's not exactly true.
They contain objects up to that size.
So, oh sorry.
They contain objects up to that size.
That means that, for example,
if you have an object of 22 bytes,
it's going to fall in the span of 24 bytes,
because it's the first one that is going to be able to store that.
But the pages are divided in as lots of that size.
So, if you have a page that is part of the 24 bytes spam,
it's going to have as lot of 24 bytes.
So, everything is same size inside that page.
So, you can, it's easy to parallelize the things.
I mean, easy to index, easy to find the things.
So, it's a very smart approach,
and we are going to see how the green tickabets collector leverage that later.
So, let's talk about what is the green tick here,
how green tick it's gaining all these performance.
The idea is there's some difference here.
This is what we saw before with the green tick,
with the regular, the classic garbage collector.
But now, what we are introducing here is those pages
from the memory allocator.
Those pages that have very specific size.
So, all these objects belong to specific pages.
So, those of these are all in the same size,
and all well organized and well structured.
Again, so, sorry, let me go back to this.
In the garbage collector,
what's the problem of the garbage collector?
What's the problem?
The current garbage collector.
The problem is whenever we start scanning in the marketplace,
we are going to go to one object,
and we are going to jump into another object,
and then jump into another object,
and you are going to jump in all over the memory.
So, it's not predictable what I going to scan next.
It's not predictable for the CPU.
It's not predictable.
It's not, there's no data locality on that.
So, I can jump all over the memory.
So, that is going to fight really hard against the CPU cache
and the CPU pipelines.
So, the CPU can leverage prediction of what you are going to index.
The CPU can't leverage the current cache
that already have in the L1 cache of the CPU.
So, it has to go to memory.
That sounds like very fast,
but it's compared to L1 cache.
It's 100 times lower,
something like that.
It's crazy, it's lower,
and it's doing that all the time
because you are jumping all over the memory.
So, the green tea trick,
basically, is instead of scanning
of just one after another,
it starts scanning pages.
So, it starts thinking about the memory
and about the memory scanning
in terms of pages.
So, we have here,
our object's organizing pages,
then you have also here a set of a couple of minutes.
One is saying,
is this object has been seen already in this page?
And the other one is,
is this object has been a scanner already?
And that's another thing
that we are going to see how it works
because we are going to go through the process.
The other thing,
it's no longer a stack of objects.
Now, it's a queue,
so, last thing, first out,
sorry,
first thing, first out,
it's a queue,
but also it's not a foggex,
it's a pages.
So, we are the unit of work
for the new go garbage collector,
it's going to be per page.
So, let's see how it works.
Imagine that I have these two
root objects that I found
in the growth on global variables,
so why I'm also in coding stocks?
I found these two objects
that I'm pointing to two objects in this page.
So, I just marked that object in the page as seen
and put that page in the queue.
So, next step, I'm going to scan that page.
I scan that page,
I found these two objects,
I have to scan these two objects
that are the ones that have been seen.
So, I say,
oh, they are pointing to other two objects,
so I marked the other two objects in the other page
and put that page in the queue again.
And now, those objects are already scanned.
So, next step, I take another page.
So, I started scanning that page from the queue
and I found another two objects,
so I marked those objects seen in the other page
and put that page in the queue
and started scanning that page and so on.
This one case here,
where you can see that the first object,
the first object in the page,
is pointing to the second object in the page that I already scanned.
But that's okay.
The green tea can scan again,
multiple pages.
Can scan again the pages
for finding objects that haven't been seen before.
So, what we are going to do is,
magazine there,
and we are going to go again to that page
and scan that and go there
and keep going that we revisited some pages
because it needed.
And we finally have
a no more pages in the queue,
so we have a scan everything
and everything else is unreachable.
Another thing that is important to understand here
is because it's a queue
and because it's a scan in things
and marking in other pages,
this process is very kind of linear.
I'm marking this page and then the next page
and then the next page.
But the reality is probably
your objects are pointing to seven different pages.
So, you're scanning the next page
and you're pointing to other seven different pages
and you're scanning the next page and all the pages
and what is going to happen
is it's going to accumulate
scenes, bits, scenes, flags
in those pages.
And whenever you reach that page,
maybe you scan in one go,
you scan 70 objects or free objects
or whatever number of objects
but you are going to accumulate that.
So, this way,
the GoGarbit Collector has the advantage
of scanning a very localized
memory objects at one time.
So, it's going to go in a page and say,
now I have to scan 13 objects.
And those setting objects
are going to be my L1 cache.
So, I'm going to do all very quickly
because it's all fresh and I don't have to go to memory
and all back and forth of the time.
So, that's the main innovation.
So, let's see how the banking work,
the page-shaking work.
Imagine that you have this scene bitmap
and this scan bitmap here.
So, I have to scan the page.
So, I started looking for the first one.
It's pending, now it's not pending
because it's has been already scanned.
The second one is pending, now,
because having been seen yet
is the third one pending, yes,
because having seen but not scanned.
So, what I'm going to do here,
this is another bitmap is one bit that's saying,
oh, the object in this position
needs to be scanned.
What it's going to do is going to expand that object
towards, is going to do a bitmap of words.
Everything is a one there.
That is saying, all these words,
all these lots that cool is stored
a pointer are something that we can,
that can be a pointer.
Okay, add and live pointer.
So, I'm scanning that.
So, what I do is getting this pointer's map.
The pointer's map is saying,
for this object, these are the words
or these are the positions that are stored on address.
So, it's going to compare that bitmap and say,
oh, this is the, these are the positions in the memory
that has memory address that I have to add to the queue
and all that stuff.
Then, I go to the next one,
expand the words, compare to the pointer map
and I have another two pointers.
So, those four pointers points to all the pages.
I mark that in the pages and put that in the queue.
So, that is how the page checking word.
But there's something else that is pretty cool.
The hardware boost.
So, the go, the go graphics collect, the go green tick
that it's collector, is using ABH5012 instructions
that are seen instructions, single instruction, multiple data
that are set of instructions that allows you
to parallelize certain operations at CPU level
where it's pretty cool.
To get some numbers, they go green tick
that's collector, it's saying that it can save
in the mark face of the go graphics collector
between a 10% to 40%,
but with the ABH, the ABH instructions,
it's giving a 10% extra.
The ABH instructions is only in very modern CPU,
so don't expect your two years laptop or something
like that to be able to run these things.
I don't know exactly the set of instructions,
but you need to have a specific set of instructions
supported in your CPU for getting this work.
Well, what it's going to do in this case
is you're going to have this bin map of seeing a scan
and instead of going, oh, let me compare this one,
let me compare this one, it's going to go in one go.
So in one go is oh, these are the pending ones
because I'm going to parallelize everything
and I'm going to get the scanning there.
And then I'm going to say oh, I'm going to expand them
and just expand everything of ones.
It's one go for the CPU.
And then you compare that with the pointers map
and go there and boom, one go.
So it's a 10% extra performance
in the mark face of the garbage collector,
so it's a pretty good boost.
There's a catch anyway.
There's a catch.
The goal garbage collector is the green ticker
which collector is a great improvement in general,
but there can be situations where the performance boost
is not there or can even be a regression on performance.
This will be kind of the case.
Imagine that your data is shaping memory
in a way that every time that you scan something,
it points to our new page
and that points to another page
and then go back to the first page and point to another page.
And in app not going, in app not accumulating
theme objects in the same pages
is just scanning one page at a time
or maybe two objects where page every single time
that is going to end up not covering the extra cost,
the extra content that we are doing for the grantee.
In general, the expectation is a 10 to 40% improvement
on the garbage on the mark face,
but it's not going to be something
per cent.
100% sure that is going to happen.
Some references, I really like the talk from Michael Kittner
Nicksek.
And at Gopher Kong, it's very good.
Check it out. He's a gold developer.
So he's a gold compiler
who will run time developers.
So he does a great job giving the talk.
The gold debt block,
it's really good, actually.
That's very deep.
The Gold source code is always an option
to check it out.
It's not the simplest code in the world, this one.
So it's hard to read.
One small thing, my company owner, it's giving away
a $200 per month for free
for open source developers.
So if you are open source, then you have an open source project.
Feel free to leave some cards there
that you can feel free to pick them
and share that with other open source developers.
Up to $200 per month on free credits on the AI agent.
Well, my social networks and it's everything you can do.
Whatever there.
And that's it.
Sorry?
Is the new garbage collector compatible?
No, no, it's not a compacting average collector.
There's no movement in the memory
once the objects get there.
But the memory allocator
helps a lot on having the memory very compact anyway.
So yeah.
We have time for questions.
We have five minutes.
Oh.
I think it's two minutes.
I saw a little company.
I see one very important question.
I'm quickly going to hand you the microphone for the online questions.
Yeah.
Thank you.
I might miss it in the talk, but as I understand,
I've been also reading the source code of this like optimization.
It works only for small objects.
Oh, yeah.
It's very important because technically the main like bottleneck.
It's allocation and the allocation of small objects.
And for big objects, we still use all like strategy.
And as far as I know, there is no plans to actually extend the strategy for big objects.
Because it's not efficient.
Yeah.
Yeah, that's a very good point.
Thank you.
Actually, yes, I think the bigger object is 500,
112 bytes or something like that.
It's only for that kind of objects.
Because at the end of the day, you have a page that is 8 kilobytes.
So if you have to scan big objects,
you end up going to the pages for all these accounting of the pages.
And all that stuff is not going to be served.
Yeah, but not only that if the locality is going to be only,
the max of locality that you're going to have with that is 20 objects.
So it's not the benefit.
It's not going to be that clear.
It's more focused on the small objects.
Yeah, but it's a very good point.
Thank you.
And because it was a good question that's the last one for today.
If you have any more garbage collecting questions,
you can always invite him or I'll go to room.
He'll be here all day.
Do you have a hallway track somewhere, will we?
No, but I'm going to be around.
So I'm very, anyone.
Look for him.
Yeah.
Remember this guy.
Yeah.
Thank you.