On 22/01/2022 10:24 PM, Ola Fosheim Grøstad wrote:
> Yes, this is better, although you would need to change the language semantics so that non-shared means local to a fiber/actor as the fiber/actor can move from one thread to another.

This isn't what I had in mind.

By telling the GC about fibers, it should be able to take advantage of this information and limit the time it takes to do stop the world scanning.

If it knows memory is live, it doesn't need to scan for it.

If it knows that memory isn't referenced in that fiber anymore, then it only needs to confirm that it isn't anywhere else.

That's not the direction I'm thinking. Its not about freeing memory. Its about deferment.

The best way to make your code faster is to simply do less work.

So to make global memory scanning faster, we either have to decrease the number of roots (likely to end with segfaults) or to decrease the memory ranges to scan for.

And since we have a context to associate with memory that is allocated and with it roots, we have a pretty good idea of if that memory is still alive or not during the execution of said context.

Think about the context of a web server/service. You have some global heap memory, router, plugins, adminy type stuff, that sort of thing. Most of that sort of memory is either reused or sticks around till the end of the process.

But then there is request specific memory that gets allocated then thrown away. If you can defer needing to add those memory ranges into the global heap, that'll speed up scanning drastically as that is where most of your free-able memory will originate from.

To top it off, when you have a concurrent GC design like forking or snapshotting, you can scan for those dead fibers memory ranges and it won't require stopping the world.

On 22/01/2022 11:59 PM, Ola Fosheim Grøstad wrote:
>> But then there is request specific memory that gets allocated then thrown away. If you can defer needing to add those memory ranges into the global heap, that'll speed up scanning drastically as that is where most of your free-able memory will originate from.
> 
> But you need to scan those memory ranges if they can contain pointers that can reach GC-memory?

Yeah those are roots. They still have to be added into the global heap to be scanned.

The goal is to decrease the number of memory ranges that need to be scanned for in a full scan.

Cost = Roots * Ranges

Get Ranges down (until it actually does need to be scanned for), lowers the cost, that's the goal by what I am suggesting!

>> To top it off, when you have a concurrent GC design like forking or snapshotting, you can scan for those dead fibers memory ranges and it won't require stopping the world.
> 
> You want to require taking a snapshot-copy of the pointer-containing heap? That will make the collector much less useful, I think.

We already have forking, and that is super useful for getting user threads to not stop. We are only missing snapshotting for Windows now.

On Saturday, 22 January 2022 at 10:05:07 UTC, rikki cattermole wrote:
>
> This isn't what I had in mind.
>
> By telling the GC about fibers, it should be able to take advantage of this information and limit the time it takes to do stop the world scanning.
>
> If it knows memory is live, it doesn't need to scan for it.
>
> If it knows that memory isn't referenced in that fiber anymore, then it only needs to confirm that it isn't anywhere else.

Does C# have thread pinned GC memory? I haven't seen anything that you need to "move" the memory to other threads in that language but I don't really know what is going on under the hood there.

D is very similar to C# and tries to copy its primitives and is one of the reasons D is nice to use. Manually moving memory around will have an effect on how the language looks and ease of use. Another thing is that thread pinned memory doesn't work well with thread pools as any thread in a pool might tamper with the memory.

In general, tracing GC doesn't scale well with large amount of memory. I would rather go with something similar to ORC in Nim in order to reduce the tracing.

On 23/01/2022 1:39 AM, Ola Fosheim Grøstad wrote:
> A forking collector is just not suitable for system level programming, it is very much a solution for a high level programming language running on hardware with lots of headroom.
> 
> If you are going high level, you might as well introduce write barriers for pointer mutation.

Agreed. There is no one size fits all solution.

Having more GC's including ones that require write barriers as an option are great things to have!