You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The API that poolget provides, while simple, is unfortunately harmful to swap-to-disk and related use cases, as it does not indicate when the returned data is no longer in use. In a sense, this is by design - Dagger does not know whether values returned by poolget escape via user code, and how long their lifetime might be, so it cannot reasonably assert that the data is no longer being accessed at some point in time.
However, we should not be forced to live without such guarantees, as it makes any improvements to the storage system questionably beneficial. Thankfully, with the advent of improved escape analysis in Julia's compiler, it should be possible for Dagger to sometimes determine the lifetime of a piece of data, and so communicate this information to MemPool. The form of this will result in at least one new public "unpin", function, which will pair with either poolget or a new "pin" function, to assert the end of the returned value's lifetime. At the point when memory is fully unpinned, MemPool will be free to take aggressive steps to delete the data and free up memory, instead of just hoping that the GC will do a good job. Of course, not all accesses may have known lifetime, so we'll need to allow such calls to disable pinning and revert back to GC-managed deallocation.
This mechanism can be beneficial for any kind of data which can be explicitly deleted, such as GPU arrays, or another user-defined type with an available memory free function.
The text was updated successfully, but these errors were encountered:
The API that
poolget
provides, while simple, is unfortunately harmful to swap-to-disk and related use cases, as it does not indicate when the returned data is no longer in use. In a sense, this is by design - Dagger does not know whether values returned bypoolget
escape via user code, and how long their lifetime might be, so it cannot reasonably assert that the data is no longer being accessed at some point in time.However, we should not be forced to live without such guarantees, as it makes any improvements to the storage system questionably beneficial. Thankfully, with the advent of improved escape analysis in Julia's compiler, it should be possible for Dagger to sometimes determine the lifetime of a piece of data, and so communicate this information to MemPool. The form of this will result in at least one new public "unpin", function, which will pair with either
poolget
or a new "pin" function, to assert the end of the returned value's lifetime. At the point when memory is fully unpinned, MemPool will be free to take aggressive steps to delete the data and free up memory, instead of just hoping that the GC will do a good job. Of course, not all accesses may have known lifetime, so we'll need to allow such calls to disable pinning and revert back to GC-managed deallocation.This mechanism can be beneficial for any kind of data which can be explicitly deleted, such as GPU arrays, or another user-defined type with an available memory free function.
The text was updated successfully, but these errors were encountered: