Expand documentation on Buffer and Memory Resource lifetimes #2038
Conversation
This notes that buffers need to be freed before the MR itself is freed.
|
Auto-sync is disabled for draft pull requests in this repository. Workflows must be run manually. Contributors can view more details about this message here. |
|
/ok to test |
| > Note that a Python exception that's raised in a scope that allocates | ||
| > buffers can keep references to the buffers that will keep them alive. | ||
| > Use ``traceback.clear_frames`` to ensure those buffers are freed | ||
| > before destroying the memory resource. |
There was a problem hiding this comment.
From this description alone, I don't think I would be able to understand how to avoid this problem.
If you want to link to an issue or include an example of the bad code inline, that is fine.
|
I might close this PR. rapidsai/cudf#20028 fixed the issue. AFAICT, rmm's Python API isn't susceptible to the same issue since its >>> tmp_mr = rmm.mr.CudaMemoryResource()
>>> rmm.mr.set_current_device_resource(tmp_mr)
>>> buf = rmm.DeviceBuffer(size=1024) # alloacted with tmp_mr
>>> del tmp_mr |
|
Correct, the Python API should protect against this. The C++ API will as well once we fully get onto the newer CCCL versions that support what we need for resources. |
|
Thanks, I'll close this then. |
Description
This notes that buffers need to be freed before the MR itself is freed, motivated by some debugging in rapidsai/cudf@958face.
Checklist