[0.46.0] Inline Class.getComponentType and refactor IL generation to access classDepthAndFlags field of j9Class #19606
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
Several methods in the JIT compiler use the name of the classDepthAndFlags field of J9Class in their names, but they incorrectly refer to it as classAndDepthFlags. This commit corrects the typographical errors in the naming of those methods, but keeps one instance that is used upstream in J9_PROJECT_SPECIFIC code in OMR until that can be removed.
Various places in the compiler need to generate IL to load the classDepthAndFlags field of j9class. Those locations need to take into account whether the target platform is 32-bit or 64-bit, as it affects the width of the field. Introducing methods in TR_J9VMBase to load the field and potentially test the settings of bits in it hides some of that.
Check for the opportunity to inline calls to Class.getComponentType, using the underlying j9ArrayClass. In particular, if the Class is known to be an array class, the test for the J9AccClassArray flag in the classDepthAndFlags field can be skipped. Also, mark Object.getClass() as non-null during IL Generation. That prevents a NULLCHK from being being generated for the Class reference in an expression like o.getClass().getComponentType(). The presence of the NULLCHK would inhibit this transformation.
|
@vijaysun-omr, may I ask you to consider this for the 0.46.0 release of OpenJ9? |
|
fyi @pshipton. This was delivered in the head stream last week. I won't be able to review this till later in the afternoon at the earliest |
|
Reviewed vs what was in the head stream PR last week. Merging. |
hzongaro
deleted the
inline-getComponentType-access-classDepthAndFlags-0.46.0
branch
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 change generates inline IL in Value Propagation for references to
Class.getComponentType(). That method was previously only inlined if the Class was known at compile-time. If the Class is known to be an array class at compile-time, the generated IL will load the<componentClass>from thej9ArrayClass; otherwise, it will generate a run-time test of whether the Class is an array class before returning the<componentClass>or a null reference.Calls to
Object.getClass()are also marked as non-null during IL generation as that method is known to always return a non-null reference. That exposes opportunities to optimize uses ofClassobjects that require the reference to be known to be non-null, including inlining calls toClass.getComponentType()in Value Propagation.Also, there are several places in the JIT compiler that generate IL to access the
classDepthAndFlagsfield ofj9class. This introduces methods inTR_J9VMBaseto do that, as has previously been done with some methods that generate IL to access theclassFlagsfield.Finally, this change also deals with some typos in methods that refer to
classDepthAndFlagsincorrectly asclassAndDepthFlags. One instance,J9::SymbolReferenceTable::findOrCreateClassAndDepthFlagsSymbolRef, will remain until its upstream use inJ9_PROJECT_SPECIFICcode in OMR is removed in pull request eclipse-omr/omr#7334.This pull request is a port of pull request #19558 to the v0.46.0-release branch.