Refactor SFFF for InterpreterEmulator and record/replay InterpreterEmulator constants #19087
Conversation
This file contains 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
jdmpapin
requested review from
0xdaryl and
vijaysun-omr
and removed request for
dsouzai
|
@0xdaryl and/or @vijaysun-omr, please review |
|
edit: Never mind, |
Only the assertion needs to be adjusted. To avoid getPointer() and getObjectClass(), it now calls getObjectClassFromKnownObjectIndex() instead. Because that API can fail to acquire VM access, the assertion is relaxed to pass when the class is not available.
This positions InterpreterEmulator to be modified later for speculative folding. - canFoldStaticFinalField() now has a variant that doesn't need a node. - knownObjectFromFinalStatic() is deleted to consolidate logic. - Callers now use a combination of canFoldStaticFinalField() and staticFinalFieldValue(), which is not limited to known objects, and which can handle fields that require OSR assumptions to fold. There are some small behavioural changes: - In AOT, canFoldStaticFinalField() now results in TR_no for everything but String.COMPACT_STRINGS. Previously, it would give the same result as in non-AOT, and folding would be attempted only to fail. - The aggressive VarHandle folding implemented in 4aa88c0 is now applied when the declared type of the field is VarHandle rather than whenever its value happens to be an instance of VarHandle. It's also restricted to cases in which the declaring class is in the JCL or has version >=53 to ensure that the field won't be modified by putstatic. Classes that declare fields of type VarHandle should have version >=53 anyway, since version 53 corresponds to Java 9, which is the version in which VarHandle was first introduced. Finally, this VarHandle folding can now be disabled by an environment variable.
Initially the result is always false. It will be updated later to sometimes return true, but in the meantime there is already a name for the concept.
Inlining uses constant folding to help determine call targets, so it's important for the corresponding IL (if any is generated) to be consistent with what the inliner saw. InterpreterEmulator now remembers constants for each TR_CallTarget that must be folded consistently in the IL, and IL generation consults these to repeat the same constant folding as needed. This repeated folding is important whenever a value might be allowed to be folded despite the possibility of a later change. It also allows constants to be speculative by specifying the assumptions that are necessary in order for the folding to be correct, and by informing the IL generator of the locations where such assumptions have been made. However, InterpreterEmulator does not yet do speculative folding. This commit also removes a bunch of unused code, mostly related to class lookahead, from TR_J9ByteCodeIlGenerator::loadStatic().
jdmpapin
force-pushed
the
inl-const-replay
branch
from
d0fb1e7
to
e48f097
Compare
|
Rebased to fix the |
|
Jenkins test sanity all jdk21 |
0xdaryl
approved these changes
Mar 25, 2024
|
I opened PR #19222 for fixing a build break on macOS. |
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 series consists of some initial preparations for expanded static final field folding (SFFF) in
InterpreterEmulator, primarily in the two ways mentioned in the title. Brief summary of each commit:KnownObjectTable::addStableArray()safe to call on the server: needed for the following refactoringInterpreterEmulator: exposes SFFF logic that will facilitate later guarded/speculative folding in inlinerisFearPointPlacementUnrestricted(): names a concept that will be needed later for early guarded foldingInterpreterEmulatorconstants: ensures consistency between inliner and IL, which will become more important later with expanded folding, and which will also inform the placement of fear points for guarded foldingThis PR depends on eclipse/omr#7282