Repository navigation
Free native allocations when ByteBuffer creation fails - #3
Merged
riccardobl merged 1 commit intoOct 5, 2026
Merged
riccardobl merged 1 commit into
riccardobl merged 1 commit into
Conversation
riccardobl
marked this pull request as ready for review
October 5, 2026 20:05
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Problem
malloc,calloc, andmallocAlignedallocate native memory before creating the JavaByteBuffer. If the JVM cannot allocate that wrapper, the method throws without returning an address or releasing the native allocation.Change
Release newly allocated memory when wrapper creation throws or returns null. Leave the raw native API and existing realloc behavior unchanged; realloc exception safety is handled separately.
Regression evidence
On the original master (6439892), each API leaked 4096 bytes when wrapper creation failed in an isolated JVM with a 16 MiB heap. The new forked regression verifies that the native allocated-byte counter returns to its original value for all three APIs. It fails against the original code and passes with this fix.
Validation
Limits
The complete Gradle/CMake build and repository-wide suite were not run in this cloud environment. The installed Java runtime lacks
--release 8platform data. Windows, macOS, Android, iOS, and ARM runtime behavior was not tested. The bounded heap-pressure test uses a separate JVM and leaves the main test runner's heap untouched.