Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Summary
This PR does a bit of clean up to set the stage for further work on native memory tracking (see issue: #7631). Specifically, it replaces usages of
LibC
malloc/calloc/realloc/free with calls toUnmanagedMemory
. From now on, I suggest thatLibC
not be used directly to manage memory. This will allow for NMT code to be added toUnmanagedMemorySupport
implementations. Additionally, this PR specifically marks locations where memory allocated outside Java code must be freed (UnmanagedMemory#untrackedFree
).This refactoring serves a second important purpose. It helps mitigate the following pitfalls associated with "malloc headers" needed for NMT. In hotspot, the "malloc header" is an extra bit of memory allocated contiguously with the main memory payload. It contains metadata such as size and type used for NMT. I think a similar approach can be used in SubstrateVM using
@RawStructures
(similar to how the JFR buffers have a header and payload). A pointer to the data payload is returned from malloc and the header is transparent to the caller. Here are the pitfalls I can see:LibC#malloc()
is used to allocate memory instead ofUnmanagedMemorySupport
, we'll miss some data that should be tracked.LibC#free()
is used to free tracked memory, we'll be in trouble because onlyUnmanagedMemorySupport
is aware of the extra header data.UnmanagedMemory#free()
is called on untracked memory (off-heap memory allocated outside of Java), then we'll segfault when trying to access a header that doesn't exist.The clean up in this PR mitigates these pitfalls, but doesn't eliminate them. If the user is determined, they can use
ImageSingletons.lookup(LibCSupport.class)
to use LibC directly, and they can choose to useUnmanagedMemory#free()
instead ofUnmanagedMemory#untrackedFree()
if they ignore the Javadoc.