Support for fine-grained selection of the GC collection type. #33448
Conversation
This makes it possible to force an incremental collection, ignoring heuristics.
4c83012
to
c3d4a32
Compare
| @@ -49,15 +49,29 @@ Module with garbage collection utilities. | |||
| """ | |||
| module GC | |||
|
|
|||
| # @enum-like structure | |||
| struct CollectionType | |||
There was a problem hiding this comment.
Out of curiosity, what is the reason for not using an actual @enum?
There was a problem hiding this comment.
gcutils.jl is included very early in the system image, before Enums.jl and having @enum.
|
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 |
|
Marking with triage to discuss the API. |
|
@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. |
|
There hasn't been a triage since that comment. |
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: