What are your hopes for the future D GC

[Random D user via Digitalmars-d]

On Friday, 30 June 2017 at 06:14:41 UTC, Dmitry Olshansky wrote:
> On 6/29/2017 10:19 PM, Random D user wrote:
>> 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.
>

More flexibility, control and tools for doing mixed memory 
management.

I was thinking that you could have multiple of these (thread 
local or single threaded, edge cases/safety would be user 
responsibility).
Basically turning gc into similar custom allocator as "bump the 
pointer" allocators or object pools. This way few of these GCs 
could be used as poor man's incremental GC.

I think it could be useful for applications that have tight 
memory and timing budgets.
For example, in games, you typically have couple bigger 
subsytems. Some game architectures preallocate all the memory 
they need and distribute it to each subsystem using custom 
allocators.
Maybe some systems with lot of small allocations could use 
"memory block local GC" and be fast enough. For example, some 
sort of a scripting or debug console subsytem could be fine with 
32MB, but you wouldn't need care about releasing your temp 
objects. Small heap size would guarantee fast collections.
And for some sort of incremental emulation you could manually 
trigger the collections and cycle between different local GC per 
frame or timestep. Also if any of the would pause for too long, 
you could easily just see which one and fix it.