Repository navigation
fix: build Redline native memory layouts once - #230
Merged
andreaTP merged 1 commit intoOct 8, 2026
Merged
Conversation
andreaTP
approved these changes
Oct 8, 2026
andreaTP
left a comment
andreaTP
left a comment
Contributor
There was a problem hiding this comment.
Thanks LGTM, while reviewing I found some other issues to be solved.
I'll follow up with another PR.
andreaTP
added a commit
that referenced
this pull request
Oct 9, 2026
Follow-up to the review of #230. Both native memories, Panama and JFFI, get the same fixes: - an initial size over RUNTIME_MAX_PAGES is rejected instead of being mapped past the reservation, into a neighbouring mapping - grow() is synchronized and the memory view is volatile, so concurrent grows can't hand out the same page and host readers see the current size - running guest code sees growth by another instance sharing the memory, through a page count the memory owns, and growth by a host import - host atomics are hardware atomics, so they no longer lose updates against the guest's - wait/notify get the #107 lost-wakeup fix and throw WasmInterruptedException when interrupted - a trap recorded by the runner's Java handler (memory.init, data.drop, table operations, memory.grow, wait/notify) stops the guest at once - a length-0 memory.init on a dropped segment still checks its offsets The .native format moves to version 3, since compiled code reads a new context slot.
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
2 participants
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.
NativeMemorywas building a new little-endian layout withwithOrderon every read and write. Each new layout has no cached var handle, so every access had to look one up again through the JDK's var handle cache, and since the layout is never a constant the JIT can't turn the access into a plain memory read. Same kind of issue as #226 but forNativeMemory.This builds the int, long and short layouts once as static constants and uses them for every access instead of building a new layout for each call. Floats and doubles already go through the int and long paths and bytes use
JAVA_BYTE, so that covers the whole class. Byte order, alignment and bounds checks don't change, and the existing runner tests cover these paths.NativeMemoryis how Java reads and writes a Redline guest's memory, so any host moving data across the boundary hits this on every call. I found it in a while developing my Minecraft client mod for Wasm components. On Redline, a minimap mod copying a few hundred records in and out of guest memory every tick went from 72 µs to 24.3 µs per tick.