On heap segregation, GC optimization and @nogc relaxing

deadalnix via Digitalmars-d digitalmars-d at puremagic.com
Tue Nov 18 14:09:28 PST 2014


On Tuesday, 18 November 2014 at 20:34:01 UTC, Ola Fosheim Grøstad
wrote:
> Does this mean that you need all threads (which I presume are 
> the mutators) to be in an eventloop in order to collect?
>

What you need is for each thread to provide you a list of roots.
You can start tracing while having an incomplete list of roots,
so the level of concurrency allowed is high.

As for the immutability thing, here is how it goes. When you
compile to native, you can either do write barrier all the time,
via writing point using a function call in the runtime. The
second option is to not do it and use memory protection to trap
write.

Option 1 is usually preferred by VM that can swicth
implementation of methods when collecting, so you pay a moderate
cost and only when you collect. But if you compile AOT, you
always pay that price and it is not very interesting.

Optin 2 is WAY more expensive and will trap even write to value,
not only pointers. If it expensive, it is only expensive when it
traps. That mean it is a very interesting choice for code
compiled ahead of time and manipulating immutable data. This is
very interesting in the case of ML, where the compiler sometime
choses to mutate, but only as an optimization, and very rarely on
object that reach the big heap, as if the object is long lived
enough to reach that heap, most likely the compiler can't prove
it is unique and thus mutable.

The same strategy seems like the obvious winner for D's immutable
heap as well as part of the shared heap that do not contain
mutable pointers.


More information about the Digitalmars-d mailing list