Add functions to manipulate the GC heap counters #55390
Conversation
`jl_malloc` and `jl_free` can be used to inform the GC about memory pressure caused by external libraries. This PR adds two functions that only do the accounting and not the memory allocation/freeing. The intended audience is users of libraries that do their own memory management, but still have establishes sizes and deallocation points. An example of this is the unified memory API in CUDA.
| { | ||
| jl_gcframe_t **pgcstack = jl_get_pgcstack(); | ||
| jl_task_t *ct = jl_current_task; | ||
| if (pgcstack != NULL && ct->world_age) { |
There was a problem hiding this comment.
Why does world_age matter here? or is that just a proxy to see if it's a valid task? We do this in other places but now that I look at it it's odd.
There was a problem hiding this comment.
Yeah this code looked weird to me as well, but I assume it's a valid task check, maybe an artifact before thread-adoption?
There was a problem hiding this comment.
The implementation seems mostly fine.
Still, adding these calls to inform the GC about manually managed memory makes me a bit nervous.
We face a similar problem at RAI where we need to make sure that a database buffer cache (the source of manually managed memory in our case) and the Julia heap cooperate. We have been moving in the direction of trying to make the GC heuristics code more aware of this external memory by, for instance, polling for RSS periodically.
I'm not familiar with memory management on GPUs, but is making the GC heuristics code more aware of GPU memory something feasible in that domain?
We need to use a different allocator But this doesn't solve how to inform the GC about memory pressure stemming from allocations in a C++ library. RSS is a poor proxy since that starts to get all kinds of wonky in the presence of swap and multi-process. |
jl_mallocandjl_freecan be used to inform the GC about memorypressure caused by external libraries. This PR adds two functions
that only do the accounting and not the memory allocation/freeing.
The intended audience is users of libraries that do their own memory
management, but still have establishes sizes and deallocation points.
An example of this is the unified memory API in CUDA.