Cherry-pick DDR changes for 0.44.0 #19217
Merged
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
For negative values, the div(), mod(), and rightShift() methods would sometimes return bad values. For example, -10 is represented as 0xFFFFFFF6L in the data field of an I32 object (or in a IDATA object for 32-bit dumps). * div(5) would return 0x33333331(858993457) instead of -2 * mod(5) would return 1 instead of 0 * rightShift(0) would return -1 instead of -10 Signed-off-by: Keith W. Campbell <[email protected]>
This updates how J9BuildFlags is generated (both as Java source and as dynamically produced bytecode) so the cname-style names can be used consistently. In UMA builds where omr_ddrgen is not used, superset.dat is generated using the raw name of each build flags rather than using the "cname" that appears in j9cfg.h which is derived from j9cfg.h.ftl. The result is that the blob (which is included in system dumps) speaks of flags like "env_data64" and "opt_jvmti", for example. With this change, flags of those names are automatically recognized as providing values for "J9VM_ENV_DATA64" and "J9VM_OPT_JVMTI", respectively. References to J9BuildFlags in DDR code have been updated accordingly. Aliases for J9BuildFlags have been removed: the more general mechanism deals with those cases now. The entry for J9BuildFlags in CompatibilityConstants29.dat has been removed: it had never had any effect. The entries for J9BuildFlags in overrides-vm have been removed: they are no longer needed. System dumps containing those names are supported using the same mechanism that handles raw names appearing in superset.dat (no matter whether the dump was produced by an older Semeru build where those overrides were in effect or produced by an IBM build. Signed-off-by: Keith W. Campbell <[email protected]>
The test of whether a field is present must be deferred until a specific system dump is being accessed. Structure stubs must include all fields optional or otherwise. The structure class generated dynamically will only include those fields actually present in the JVM that produced the system dump. Accesses to missing fields will trigger a NoSuchFieldError which will be replaced by NoSuchFieldException by the related pointer class. Pointer classes must support the scenario where a field is not present in the executing JVM, but is present in a system dump being analyzed. Signed-off-by: Keith W. Campbell <[email protected]>
pshipton
approved these changes
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 includes