On 6/29/2017 10:19 PM, Random D user wrote:
I just got curious, after reading the GC analysis blog post. What kind
of features people generally would want for the GC (in the distant murky
future of 1999)?
Here's some of my nice to haves:
1. Thread local GCs. D is by default thread local, so it kind of would
make sense and goodbye stop everything GC.
Yes, yes and yes. The moment we fix the spec and code that casts shared
to TLS at will.
2. Composable custom memory block GC. The ability to mallocate 128MB
memory block and create a new GC instance to manage that block. It would
only need to scan that 128MB block and not worry about rest of memory
and resources (with complex destruction orders) in 16GB heap. This way
you probably could guarantee good collection times for some subsystems
in your program and use your favorite allocator for others.
Not sure what benefit this has compared to just limiting GC heap to 128Mb.
3. Callbacks to GC operations. I have timeline profiler implemented for
my project. It would be quite cool to have GC collection starts and
stops record a timestamp for the timeline.
(Can this be done already? Hopefully without recompiling the GC. I tried
to look but I couldn't find any hooks in the docs.)
Hooks for statistics sounds nice. You can do poll style check
periodically right now.
4. Incremental GC with collection time limit. Is this even viable for D?
Concurrent is more likely then incremental without barriers.
--
Dmitry Olshansky