Skip to content

Conversation

@keithc-ca
Copy link
Contributor

In Java 25+, jdk.internal.misc.Unsafe.INVALID_FIELD_OFFSET has type long, not int, so a NoSuchFieldError is thrown by GetStaticFieldID() called within sun.misc.Unsafe.registerNatives(). Normally that error is just ignored, but if a user supplies an -Xdump option which requires checking the call stack, that check fails because the offset of Throwable.walkback has not been captured for use by J9VMJAVALANGTHROWABLE_WALKBACK(), etc. The result is that the lock word (at offset zero after the header) is read and interpreted as a heap reference. On must platforms, the initial lock word is zero which behaves like null which iterateStackTraceImpl() handles as an unavailable walkback object. On POWER, however, the initial lock is normally non-zero (but not a valid heap reference), resulting in a crash.

This change avoids problems like this early in the lifetime of a JVM by not registering dump hooks for exception events until after all the known classes, fields and methods have been resolved (including the offset of Throwable.walkback).

The change is organized into three commits:

  1. a general cleanup of trigger.c, but no functional changes
  2. changes to trigger.c to delay installing hooks for exception-related events
  3. the removal of useless/problematic code from sun.misc.Unsafe.registerNatives()
Update to better adhere to our coding standards; no functional changes. Signed-off-by: Keith W. Campbell <keithc@ca.ibm.com>
It's not safe to handle exception-related events before JCL initialization has completed. The VM must be capable of properly handling exception dump filters (internally, the offset of Throwable.walkback is required for use by J9VMJAVALANGTHROWABLE_WALKBACK(), etc.), so those hooks are not registered until then. Signed-off-by: Keith W. Campbell <keithc@ca.ibm.com>
In Java 25+, jdk.internal.misc.Unsafe.INVALID_FIELD_OFFSET has type long, not int, so a NoSuchFieldError is thrown by GetStaticFieldID(). This occurs before the VM is capable of properly handling exception dump filters (internally, the offset of Throwable.walkback has not been captured for use by J9VMJAVALANGTHROWABLE_WALKBACK(), etc.). If the field exists, it is assigned the value -1, but, in all Java versions, the field would already have that value. This removes the code that is problematic in Java 25+ and just useless in general. Signed-off-by: Keith W. Campbell <keithc@ca.ibm.com>
@keithc-ca keithc-ca requested a review from pshipton November 4, 2025 20:10
@pshipton
Copy link
Member

pshipton commented Nov 4, 2025

jenkins test sanity plinux,amac jdk25

@pshipton
Copy link
Member

pshipton commented Nov 5, 2025

Pls check out the internal RAS failures http://vmfarm.rtp.raleigh.ibm.com/jobs_by_status.php?build_id=105877&status=FAILED

Some of these may be expected, but there are many more failures than usually occur. You can compare against the ibuild.

@keithc-ca
Copy link
Contributor Author

I expect the failures are related to https://github.com/eclipse-openj9/openj9/blob/master/runtime/rasdump/dmpsup.c#L544-L547 which seems to be negatively affected by the delay installing the exception-related hooks.

@keithc-ca
Copy link
Contributor Author

I do note that the failures in rasDumpEnableHooks() are silently ignored, except the last attempt. That's probably something that should be fixed as well.

@keithc-ca keithc-ca marked this pull request as draft November 7, 2025 14:06
@keithc-ca
Copy link
Contributor Author

I think I'll improve the cleanup part of this and deliver it separately. In draft mode until after that.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

2 participants