The GC (agian)

Stanislav Blinov stanislav.blinov at gmail.com
Sat Nov 20 14:46:53 UTC 2021


On Saturday, 20 November 2021 at 13:48:44 UTC, JG wrote:
> Hi,
>
> Having been hanging around these forums for a few years now 
> (and writing software in D during that time) I have noticed 
> that there are quite often disagreements about the GC.
>
> I was thinking about this and wondered if some of these 
> problems could be possibly
> eliminated by making the GC more configurable. For instance one 
> might envisage
> that one can with some nice API be able do things like:
> (a) specify exactly when the GC should do a stop the world mark 
> and sweep (not when it feels like it when it needs to allocate 
> memory and perhaps through an API more pleasant than the 
> current, enable and disable mechanism);
> (b) specify that the next allocations should be done into a 
> preallocated block (which it could be asked to drop later, 
> without marking and sweeping).
>
> I guess my real question is more is there someway that the GC 
> be modified so that on the one hand it works exactly like it 
> does now (if no options are set) and on the other hand can be 
> configured so that it is close enough to manual memory 
> allocation that say someone building a game wouldn't find it 
> gets in there way.
>
> The main point would be to allow someone to fully use D (with 
> some extra house-keeping they have to do) but avoid 
> unpredictable GC pauses.
>
> I understand that this wouldn't satisfy everyone, but perhaps 
> it would be more feasible than some of the more drastic 
> proposals that get thrown around from time to time.
>
> If this is something that makes sense and would be useful I 
> would be willing to try and build it.
>
> [In case it is of interest to anyone, personally I like having 
> a GC, although there are a few instances where it would be nice 
> to have a bit more flexibility.]

(a) could be a welcome addition, or rather, augmentation of 
existing implementation, i.e. guaranteeing that GC.collect() 
actually does full collection, and also making more strict 
specification for disable/enable

(b) has some problems: what is "next" allocation? There are quite 
a few things beside `new` that may allocate. Also, on what 
thread? Asking to drop the block is also not really feasible, as 
the only way GC could do so safely would be to ensure there are 
no more pointers into that block stored anywhere, which requires 
scanning. If you don't need @safe, however, it's trivial to plop 
your own arena on a GC-allocated block through e.g. 
`std.experimental.allocator`, or even your own. And you already 
can reserve memory for the GC heap beforehand with the 
`GC.reserve()`.

If you're making a game or anything that requires consistent high 
framerate, the problem is mostly not in predicting the pauses, 
you can deal with that (though still, current documented 
requirements on `disable` do leave some questions). It's the 
pause itself, which with the current implementation is 
obnoxiously long. If you have natural lulls in framerate, you may 
be able to afford it. If not, you pretty much wouldn't be using 
GC anyway, either at all or in select threads, but that means 
you're missing out on a few language features.


More information about the Digitalmars-d mailing list