Bug 24331 – @nogc and GC.disable() are often confused

Adam Wilson writes: @nogc works just fine. We recently spent a good chunk of time in Discord educating a newbie on what it actually does. What @nogc is specified to do: Prevent GC allocations from occurring. Fantastic. What people actually do with @nogc: Use it to selectively disable the GC without using GC.disable(). The reason for this stems from a side-effect of how the current GC operates. Because allocations are the trigger for collections, by preventing allocations, collections are also prevented. And what people really want to do is disable collections because they don't like the collection pauses. They don't actually care about the allocations per se because that is generally as fast as a malloc and they are going to have to allocate at some point anyways. So @nogc works exactly as specified, but because of an unspecified implementation side-effect, that is not guaranteed to hold true in the future, the @nogc crowd writes their code as if @nogc does something else entirely. And we end up here in this thread.

Sounds like better documentation is needed for both @nogc and GC.disable().

(In reply to Walter Bright from comment #1) > Sounds like better documentation is needed for both @nogc and GC.disable(). Well, currently, the spec states: How Garbage Collection Works ----------------------------- The GC works by: - Stopping all other threads than the thread currently trying to allocate GC memory. - ‘Hijacking’ the current thread for GC work. - Scanning all ‘root’ memory ranges for pointers into GC allocated memory. - Recursively scanning all allocated memory pointed to by roots looking for more pointers into GC allocated memory. - Freeing all GC allocated memory that has no active pointers to it and do not need destructors to run. - Queueing all unreachable memory that needs destructors to run. - Resuming all other threads. - Running destructors for all queued memory. - Freeing any remaining unreachable memory. - Returning the current thread to whatever work it was doing. https://dlang.org/spec/garbage.html So what people are relying on is currently indeed specified behavior. This can of course be changed, but I do not think we can fault users for relying on this documented behavior of the GC.

@WalterBright created dlang/dlang.org pull request #3756 "fix Issue 24331 - @nogc and GC.disable() are often confused" fixing this issue: - fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dlang.org/pull/3756

@WalterBright created dlang/dmd pull request #16023 "fix Issue 24331 - @nogc and GC.disable() are often confused" fixing this issue: - fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dmd/pull/16023

dlang/dlang.org pull request #3756 "fix Issue 24331 - @nogc and GC.disable() are often confused" was merged into master: - 5c56620fa0fbfc2db75e681751abbd5f85758cb1 by Walter Bright: fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dlang.org/pull/3756

dlang/dmd pull request #16023 "fix Issue 24331 - @nogc and GC.disable() are often confused" was merged into master: - e04af29b775a42417d43081fdc905021766b6bb4 by Walter Bright: fix Issue 24331 - @nogc and GC.disable() are often confused https://github.com/dlang/dmd/pull/16023