On heap segregation, GC optimization and @nogc relaxing

[via Digitalmars-d]

On Saturday, 15 November 2014 at 20:13:47 UTC, deadalnix wrote:
> On Saturday, 15 November 2014 at 12:52:33 UTC, Ola Fosheim 
> Grøstad wrote:
>> Thanks for the link! I agree ML has some interesting work done 
>> for it, but they make some assumptions:
>>
>> 1. low portion of mutable objects
>>
>> 2. small heap fits in per-core-cache (<256KiB on Haswell).
>>
>> So the small heap is basically a region allocator that caches 
>> allocations that are likely to die, cutting down on the more 
>> costly effort to update the big heap. But I am not sure if 
>> that fits system level programming, that is more typical for 
>> functional programming…
>
> The small heap do not apply for us. We can't reproduce that 
> part of the GC in D. However, the big heap part of the strategy 
> would fit D's immutable heap very nicely.

Maybe, but immutable in ML means that two different immutable 
objects are 100% indistinguishable if they have the same value. 
Quite often you have a cluster of objects (that could be an 
isolate) that are periodically immutable. I assume what is most 
interesting is whether it is immutable between two collections, 
and not whether it is mutable throughout the lifespan?

There are two points in the powerpoint that sticks out though:

* «trade collection “quality” for level of synchronization - 
allow large amounts of floating
garbage»

* «trade collection “simplicity” for level of synchronization - 
complicated algorithm (not to
mention correctness proof)»

And also this:

«Root enumeration
* Raise a flag to signal beginning of marking
* shade globals
* ask mutators to shade roots
* wait until all mutators answered
* meanwhile - start scanning and marking»

Does this mean that you need all threads (which I presume are the 
mutators) to be in an eventloop in order to collect?


Online version of the slides:
http://s0.docspal.com/files/processed/64/6863864-yusxlrni/doligez.pdf