Shrink varTableStamp - #9091
Merged
headius merged 1 commit intoDec 2, 2025
Merged
Conversation
Copy link
Copy Markdown
Member
Sorry, something went wrong.
headius
added a commit
to headius/jruby
that referenced
this pull request
Dec 2, 2025
With compressed OOPS on HotSpot, we have 4 bytes of slack currently that can be used to store the full long hash. This may change with jruby#9095 and jruby#9091 land, which will greatly reduce the flag overhead of all objects.
This stamp is used to guard atomic access to the varTable field when it needs to be grown to accommodate more values. The logic expects that anyone performing such an update will increment the stamp while updating the the table reference, backing off if the stamp has changed before finally assigning the new table (allowing concurrent writers to all attempt growth without a hard lock, with the first-past-the-post thread winning). We probably don't need 32 bit for this, since that would accommodate an absurd 2-4 billion concurrent mutators. Byte range may be too small, but still handles at least 64 concurrent mutators with non successfully growing the table large enough for any of the others to proceed. This relates to object header size reductions detailed in recent issues like jruby#9090.
headius
force-pushed
the
var_table_stamp_shrink
branch
from
17032a1 to
84d0d67
Compare
December 2, 2025 15:45
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
1 participant
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.
This PR will experiment with and eventually proceed with changes to reduce the size of the varTableStamp we currently use to guard concurrent, atomic growth of the varTable field.
Initial experiments simply shrink the stamp to a byte, which still accommodates up to 64 concurrent mutators. It may be possible to reduce it to a single bit by forcing other mutators to block for a (very) short time while the var table is being updated, but we'll want to have some tests that show this does not lead to any deadlocks (unlikely, since this code does not trigger further locking) or false positive locks as well as benchmarks to show that we are not adversely impacting concurrent updates (both contended and non-contended).