revert breaking change to GC.gc()

[vtjnash]

Removes the breaking part of b0ed147 from PR #34303

[StefanKarpinski]

Definitely good to do this to unbreak CI, but this means there's no longer any way to call GC with the AUTO level where it decides if it wants to do a full or incremental cleaning automatically. Can you elaborate on what code was relying on GC.gc() doing a full collection?

[Keno]

Can you elaborate on what code was relying on GC.gc() doing a full collection?

SharedArrays is relying on GC.gc to actually delete the array and run the finalizer.

[Keno]

https://github.com/JuliaLang/julia/blob/master/stdlib/SharedArrays/test/runtests.jl#L148-L150

Of course, we could also change those to GC.gc(true), but we'd likely want to audit all other uses of this function also.

[maleadt]

Of course, we could also change those to GC.gc(true), but we'd likely want to audit all other uses of this function also.

All uses of GC.gc() seem to be in tests, but then this change would be breaking. OTOH, the docstring never mentioned anything about full vs. incremental collections, so maybe it would be OK to do this change (but take care adapting the tests this time)?

[StefanKarpinski]

I guess the question is what people probably want when they explicitly call GC.gc(). I'm guessing they want a full collection 99% of the time. What are the use cases for explicitly invoking an incremental collection or a "maybe incremental, maybe full" collection? Hard to think of any.

[maleadt]

What are the use cases for explicitly invoking an incremental collection

GPU GC. From a resnet50 trace:

 ────────────────────────────────────────────────────
                                       Time          
                               ──────────────────────
       Tot / % measured:            82.2s / 84.0%    

 Section               ncalls     time   %tot     avg
 ────────────────────────────────────────────────────
 pooled alloc           65.1k    68.9s   100%  1.06ms
   1. try alloc         23.7k    5.66s  8.19%   239μs
   2. gc(false)         4.31k    15.6s  22.6%  3.62ms
     pooled free        33.1k   19.4ms  0.03%   586ns
   3. reclaim unused    3.32k    7.25s  10.5%  2.19ms
     reclaim            3.32k    7.24s  10.5%  2.18ms
     scan               3.32k   2.86ms  0.00%   863ns
   4. try alloc         3.32k    3.32s  4.81%  1.00ms
   5. gc(true)            127    36.9s  53.4%   291ms
     pooled free        24.2k   13.5ms  0.02%   557ns
 pooled free            6.78k   7.53ms  0.01%  1.11μs
 ────────────────────────────────────────────────────

So 97% of the time we need to collect GPU memory, an incremental collection is sufficient to free something up. Always doing a full collection (which here is 100x as expensive) would kill performance.

[StefanKarpinski]

So I guess the remaining question is when does one want to explicitly invoke a GC that may be incremental or full?

[JeffBezanson]

It does stand to reason that if you're explicitly asking for a GC, it should be of a specific kind.