(0.44) Avoid heap walk and GC for MemberName fix-up on class redefinition #19213
Conversation
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
In class redefinition the affected MemberName objects were previously identified by iterating over all objects in the heap. The heap walk also necessitated a GC cycle to eliminate dead objects, which could otherwise cause the fix-up to crash. This heap walk and GC cycle were causing a significant performance regression in redefinition for builds using OpenJDK MethodHandles (i.e. Java 17+) vs. ones using J9 MethodHandles. The regression was especially drastic in fast HCR mode, where no other heap walk is necessary and therefore the time taken for redefinition should be largely independent of the number of objects in the heap. Now instead each J9Class has a list of JNI weak global references to all of the MemberName objects that are resolved (i.e. have vmtarget set) to a member of that class (as determined by the clazz field). Redefinition uses these lists to identify the affected MemberNames without inspecting any other objects, and in particular without walking the heap. Because the heap walk is no longer needed, neither is the GC cycle, and both are eliminated. The use of weak references ensures that these lists don't prevent MemberName objects from being reclaimed, and in particular that they don't prevent class unloading. When a MemberName is reclaimed, its corresponding weak reference is cleared, and both that reference and its linked list node become unnecessary. To avoid leaking this memory, such entries are removed just prior to the addition of a MemberName, but only if it can be expected that there are any. To this end, the VM now provides an implementation of a native method MethodHandleNatives.markClassForMemberNamePruning(), which is expected to (exist and) be called when a MemberName that is on a per-class list becomes unreachable (really, phantom reachable), such as from a cleaning action or finalizer. Without this adjustment to the Java sources, the mechanism implemented in this commit will still work, but the MemberName list will leak memory if many MemberNames for the same class are created and then reclaimed. (cherry picked from commit e06a34c)
pshipton
approved these changes
Mar 25, 2024
jdmpapin
changed the title
This was referenced Mar 25, 2024
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.
This is a cherry-pick of e06a34c (#19187).