Repository navigation
Conversation
getBuffer(false) used to return a raw view without a reference to its
owner, so it could outlive the native memory. Each view now keeps a
native reference until the Java GC collects it, using fbjni's
DestructorThread as an identity-based phantom reference registry.
Add withByteBuffer { } for scoped access without that extra reference,
like Swift's withUnsafeBytes. getBuffer(true) now only copies non-owning
buffers, like Swift's toData(copyIfNeeded:).
|
The latest updates on your projects. Learn more about Vercel for GitHub.
|
This branch was successfully deployed
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.
getBuffer(false)returned a raw directByteBufferwith no reference to its owner, so it could outlive the native memory. Withclose()that is easy to hit.getBuffer(false)view now keeps a native reference to the data until the Java GC collects the view. It uses fbjni'sDestructorThread.Destructor, a phantom reference, so views are tracked by identity. This also coversByteBuffer-backed buffers, sowrap(..., onDelete)can't run while a view is still in use.withByteBuffer { }for scoped access without that extra reference, like Swift'swithUnsafeBytes.getBuffer(true)now only copies non-owning buffers, like Swift'stoData(copyIfNeeded:). Owning buffers, e.g.HardwareBuffer-backed ones, return a view.A new shared case retains a view (Kotlin
getBuffer(false), SwifttoData(copyIfNeeded: false), C++ theArrayBuffer) and checks that the wrapped buffer isn't deleted until the view is released.Tested on an API 36 emulator: the
array-bufferssuite passes with this PR. With the view registration removed, the new case fails for Kotlin (deleted while the view still holds the buffer: expected 1 to equal +0).🤖 Generated with Claude Code