Support for fine-grained selection of the GC collection type.

[maleadt]

This makes it possible to force an incremental collection, ignoring full collection heuristics.

Motivation: from the GPU allocator, we routinely call into the Julia GC to free GPU buffer objects. If GPU memory pressure is high, we do this quite regularly (e.g. twice a second). An incremental collection is often enough to free up sufficient GPU memory, and this initially takes about 40~50ms (for a Flux model I'm profiling), but after a while the collection time drops off a cliff to about 500ms for all calls to gc(false). This is due to the GC heuristics forcing a full collection since the incremental ones "fail" to collect enough memory (GPU buffer objects are tiny, and do not reflect actual GPU memory freed).

This PR adds the (non-breaking) ability to force an incremental collection, ignoring all heuristics.

TODO:

• tests
• Julia API

[yuyichao]

LGTM.

[KristofferC]

Out of curiosity, what is the reason for not using an actual @enum?

[maleadt]

gcutils.jl is included very early in the system image, before Enums.jl and having @enum.

[StefanKarpinski]

Are we intending this to be an official API for choosing the collection type? If so I think we should probably discuss the API a bit more... having a type that wraps an integer like this is not how I would prefer to have people interact with this. This would be fairly simple:

gc()      # auto
gc(true)  # full
gc(false) # incremental

[StefanKarpinski]

Marking with triage to discuss the API.

[maleadt]

@StefanKarpinski Was anything discussed during triage? I don't have strong feelings about the interface, so I'd be happy to put up a PR with your proposed API.

[KristofferC]

There hasn't been a triage since that comment.