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