-
Notifications
You must be signed in to change notification settings - Fork 6.1k
8356075: Support Shenandoah GC in JVMCI #25001
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from 8 commits
Commits
Show all changes
11 commits
Select commit
Hold shift + click to select a range
344955a
Graal Shenandoah support
rkennke 956bbec
Revert "8321373: Build should use LC_ALL=C.UTF-8"
rkennke 0bcdb7d
Support for Shenandoah card-table barriers in JVMCI
rkennke 2f54728
Merge branch 'master' into graal-shenandoah-support
rkennke f54cb48
Revert unrelated changes
rkennke 1543e8f
Revert unrelated changes
rkennke 25a8a6f
Remove unnecessary stuff
rkennke 6487a9f
Fix ordering of includes
rkennke c95313a
Initialize cardtable_start_address to nullptr
rkennke 4434458
Align backslashes
rkennke 41084f3
Simplify pre-barrier runtime entry
rkennke File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
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
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
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
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
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -52,6 +52,10 @@ | |
#include "runtime/sharedRuntime.hpp" | ||
#include "runtime/stubRoutines.hpp" | ||
#include "utilities/resourceHash.hpp" | ||
#if INCLUDE_SHENANDOAHGC | ||
#include "gc/shenandoah/shenandoahHeap.hpp" | ||
#include "gc/shenandoah/shenandoahHeapRegion.hpp" | ||
#endif | ||
|
||
int CompilerToVM::Data::oopDesc_klass_offset_in_bytes; | ||
int CompilerToVM::Data::arrayOopDesc_length_offset_in_bytes; | ||
|
@@ -86,6 +90,11 @@ address CompilerToVM::Data::ZPointerVectorLoadBadMask_address; | |
address CompilerToVM::Data::ZPointerVectorStoreBadMask_address; | ||
address CompilerToVM::Data::ZPointerVectorStoreGoodMask_address; | ||
|
||
#if INCLUDE_SHENANDOAHGC | ||
address CompilerToVM::Data::shenandoah_in_cset_fast_test_addr; | ||
int CompilerToVM::Data::shenandoah_region_size_bytes_shift; | ||
#endif | ||
|
||
bool CompilerToVM::Data::continuations_enabled; | ||
|
||
#ifdef AARCH64 | ||
|
@@ -227,12 +236,21 @@ void CompilerToVM::Data::initialize(JVMCI_TRAPS) { | |
assert(base != nullptr, "unexpected byte_map_base"); | ||
cardtable_start_address = base; | ||
cardtable_shift = CardTable::card_shift(); | ||
} else if (bs->is_a(BarrierSet::ShenandoahBarrierSet)) { | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. This change is causing a failure in mach5 tier 1:
I assume it's missing |
||
cardtable_shift = CardTable::card_shift(); | ||
rkennke marked this conversation as resolved.
Show resolved
Hide resolved
|
||
} else { | ||
// No card mark barriers | ||
cardtable_start_address = nullptr; | ||
cardtable_shift = 0; | ||
} | ||
|
||
#if INCLUDE_SHENANDOAHGC | ||
if (UseShenandoahGC) { | ||
shenandoah_in_cset_fast_test_addr = ShenandoahHeap::in_cset_fast_test_addr(); | ||
shenandoah_region_size_bytes_shift = ShenandoahHeapRegion::region_size_bytes_shift_jint(); | ||
} | ||
#endif | ||
|
||
#ifdef X86 | ||
L1_line_size = VM_Version::L1_line_size(); | ||
#endif | ||
|
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
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
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So, why not export
write_ref_field_pre
, instead of introducing this new method? Style/cleanliness, or something else? I am asking, because every time we add a new stub here, we would need to record it inAOTCache
tables for Leyden benefit.There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's about the argument ordering. Graal expects the Thread* to be prependend, while other JITs call it with the Thread* appended. I guess we could change other JIT calls to also prepend the thread, or change the interface to not pass the Thread* at all. I chose to follow G1 and export both variants.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh, so this matches
JVMCIRuntime::write_barrier_pre
for G1 (weird place to have it, but oh well).Does Graal need the
Thread*
argument?I think this method is only called when SATB buffer is full. So the performance of this method is likely not affected by getting the current thread down in caller. So I think it would be more straight-forward to sharpen
ShenandoahRuntime::write_ref_field_pre
by droppingThread*
and then exporting that. Maybe also under theSR::write_barrier_pre
name to be even more consistent for everything else.Maybe @JohnTortugo wants to clean up more mess in C2 related to this :)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Graal does not need the Thread* argument, but the runtime code behind write_ref_pre() currently uses it. I agree, it does not look performance critical to pass it through. However, getting rid of it seems to blow the scope of this PR. I'd rather do this as a follow-up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, I'd probably add the new entry for Graal without the Thread* argument now, and fix the others in a follow-up. Otherwise we need to deal with it on the Graal side again later once we change the entry points.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK, but that follow-up risks changing the JVMCI interface again? How about we introduce:
...and then the follow-up purges the old
write_ref_field_pre
? The implementation might need to be in.cpp
.