The GC (agian)

Imperatorn johan_forsberg_86 at hotmail.com
Sun Nov 21 09:29:10 UTC 2021


On Saturday, 20 November 2021 at 17:00:05 UTC, H. S. Teoh wrote:
> On Sat, Nov 20, 2021 at 01:48:44PM +0000, JG via Digitalmars-d 
> wrote:
>> [...]
>
> What's wrong with the current mechanism?  In applications where 
> I need better control over collections, I've used GC.disable 
> and GC.collect quite effectively.
>
>
>> [...]
>
> My impression was that this was one of the goals of 
> std.experimental.allocator.
>
>
>> [...]
>
> Just slap @nogc on main() (or whatever function is the entry 
> point into
> your critical section where you don't want any GC activity) and 
> you can
> already do this today.
>
>
>> [...]
>
> In one of my projects I call GC.disable at the start, and have 
> a manual iteration counter that invokes GC.collect at strategic 
> points.  It works pretty well.  In this particular context the 
> reason I wanted to do this was to control the frequency of GC 
> collections, because I found that collections ran too often.  
> So I ran collections on my own schedule instead of the default. 
>  The same strategy could also be used to run collections only 
> at specific points in your code, so that pauses are predictable.
>
>
> [...]
>> [...]
>
> Me too.  And so far I've found that calling GC.disable and 
> running GC.collect on my own schedule has worked well enough 
> for me. (Note that GC.disable merely disables automatic 
> collection; allocations will still go through the GC and 
> collections will still run when you manually invoke GC.collect.)
>
>
> T

I get the feeling that maybe what's missing is just confidence in 
the system. Are there good documentation about this for example? 
Some walk through? Videos with evidence that the GC is not 
touching @nogc etc?

I have never experienced any problems with the GC, but we ofc 
have to listen to the voice of those that are worried for 
whatever reason.

Personally I would love to see some videos on GC best 
practices/patterns ☀️


More information about the Digitalmars-d mailing list