June 2024 - hotspot-jfr-dev

[jdk23] RFR: 8326715: ZGC: RunThese24H fails with ExitCode 139 during shutdown
by Markus Grönlund 17 Jun '24

17 Jun '24

8326715: ZGC: RunThese24H fails with ExitCode 139 during shutdown ------------- Commit messages: - Backport cdf22b13204456b589349500bef0e9d48af44e83 Changes: https://git.openjdk.org/jdk/pull/19748/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19748&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326715 Stats: 412 lines in 11 files changed: 249 ins; 100 del; 63 mod Patch: https://git.openjdk.org/jdk/pull/19748.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19748/head:pull/19748 PR: https://git.openjdk.org/jdk/pull/19748

2 2

RFR: 8326715: ZGC: RunThese24H fails with ExitCode 139 during shutdown
by Markus Grönlund 17 Jun '24

17 Jun '24

Objects with static storage duration will implicitly add their destructors to the std::atexit callbacks list. During process shutdown, the C routine __ run_exit_handlers() invokes the destructors on the std::atexit callback list. The RefCountHandle has static storage and a destructor that decrements a reference counted pointer and, if necessary, deletes the pointee's contents. In this case, this pointee includes yet another embedded RefCountHandle. When the destructor is invoked, it causes a cascade of handles to be destroyed, so many that it causes a stack overflow. The list contains about 87000 entries. These reference-counted pointees are blobs saving metadata-related information about class unloading. The DeprecationManager subsystem lacks a filtering mechanism, similar to the ObjectSampler subsystem, to decide what to save concerning class unloading blobs. One solution is to consolidate the preservation of type set blobs for both the DeprecatedManager and the ObjectSampler subsystems. Additionally, filtering will prevent the storage of redundant data. This, coupled with more frequent scavenging of the list, will effectively avert a stack overflow. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - whitespace - cleanup - 8326715 Changes: https://git.openjdk.org/jdk/pull/19510/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19510&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326715 Stats: 410 lines in 11 files changed: 251 ins; 100 del; 59 mod Patch: https://git.openjdk.org/jdk/pull/19510.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19510/head:pull/19510 PR: https://git.openjdk.org/jdk/pull/19510

2 6

Integrated: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
by Matthias Baesken 12 Jun '24

12 Jun '24

On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken <mbaesken(a)openjdk.org> wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not crash and it was not noticed before. This pull request has now been integrated. Changeset: abbf45b5 Author: Matthias Baesken <mbaesken(a)openjdk.org> URL: https://git.openjdk.org/jdk/commit/abbf45b57edf2f5bf9a3f2fa408f35a43ebe9bb9 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' Reviewed-by: jbechberger, stuefe ------------- PR: https://git.openjdk.org/jdk/pull/19628

1 0

Re: RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
by Matthias Baesken 12 Jun '24

12 Jun '24

On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken <mbaesken(a)openjdk.org> wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not crash and it was not noticed before. Hi Thomas and Johannes, thanks for the reviews ! ------------- PR Comment: https://git.openjdk.org/jdk/pull/19628#issuecomment-2162188598

1 0

Re: RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
by Thomas Stuefe 12 Jun '24

12 Jun '24

On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken <mbaesken(a)openjdk.org> wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not crash and it was not noticed before. @egahlin thank you. Patch is okay then. ------------- Marked as reviewed by stuefe (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/19628#pullrequestreview-2112007936

1 0

Re: RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
by Thomas Stuefe 11 Jun '24

11 Jun '24

On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken <mbaesken(a)openjdk.org> wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not crash and it was not noticed before. About your fix, do you know why MetadataEvent and CheckPointEvent would not count toward the number of events? In other words, why NUMBER_OF_EVENTS is 162 if we have 164 events? Maybe the number of events is wrong? @egahlin ? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19628#issuecomment-2161218498

2 1

Re: RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
by Matthias Baesken 11 Jun '24

11 Jun '24

On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken <mbaesken(a)openjdk.org> wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not crash and it was not noticed before. My maximum JfrEventId is 163 , see the generated hotspot/variant-server/gensrc/jfrfiles/jfrEventIds.hpp enum JfrEventId { JfrMetadataEvent = 0, JfrCheckpointEvent = 1, JfrDurationEvent = 2, JfrInstantEvent = 3, JfrValueEvent = 4, JfrTextEvent = 5, JfrZThreadDebugEvent = 6, ..... JfrJavaAgentEvent = 161, JfrNativeAgentEvent = 162, JfrDeprecatedInvocationEvent = 163, }; so NUMBER_OF_EVENTS + NUMBER_OF_RESERVED_EVENTS looks fine to me. 163 is the highest I could see while testing. ------------- PR Comment: https://git.openjdk.org/jdk/pull/19628#issuecomment-2160953294

2 1

Re: RFR: 8332699: ubsan: jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]'
by Thomas Stuefe 11 Jun '24

11 Jun '24

On Mon, 10 Jun 2024 12:30:59 GMT, Matthias Baesken <mbaesken(a)openjdk.org> wrote: > When running hs :tier1 tests or jdk/jfr tests, with ubsan enabled (configure flag --enable-ubsan), in a lot of jfr related tests like > compiler/intrinsics/klass/CastNullCheckDroppingsTest.jtr > serviceability/jvmti/RedefineClasses/RedefineSharedClassJFR.jtr > this oob error can be seen : > > /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31:43: runtime error: index 163 out of bounds for type 'jfrNativeEventSetting [162]' > #0 0x7f6b75a8634b in JfrEventSetting::setting(JfrEventId) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.inline.hpp:31 > #1 0x7f6b75a8634b in JfrEventSetting::set_stacktrace(long, bool) /jdk/src/hotspot/share/jfr/recorder/jfrEventSetting.cpp:47 > > Looks like the array in generated code is too small. > With > `jfrNativeEventSetting bits[NUMBER_OF_EVENTS];` > and > > static const int NUMBER_OF_EVENTS = 162; > static const int NUMBER_OF_RESERVED_EVENTS = 2; > > > Access at index 163 cannot work. > But it looks like there is always enough memory after the array so we do not crash and it was not noticed before. Good catch! But I am not sure the solution is correct, or not enough. On my machine (linux x64), I see 169 explicitly named events in `JfrNativeSettings::ev`. But then, `NUMBER_OF_EVENTS = 162;` and `NUMBER_OF_RESERVED_EVENTS = 2;` . => 164. So, the last 5 events are not covered by the `bits` array even with your change. So, there is a mismatch somewhere between `metadata.getEventsAndStructs()` (used to print out individual event data) and `metadata.eventCounter.count` (used to determine NUMBER_OF_EVENTS). ---- If you have figured this out, and fixed it, could you please let the generator add a STATIC_ASSERT( sizeof(JfrNativeSettings::ev) == sizeof(JfrNativeSettings::bits) ); to the header? ------------- PR Comment: https://git.openjdk.org/jdk/pull/19628#issuecomment-2160739146

1 0

RFR: 8330205: Initial troff manpage generation for JDK 24
by David Holmes 11 Jun '24

11 Jun '24

Sets the version to 24/24-ea and the copyright year to 2025. Content changes related to the start of release (e.g. for removed options in java.1) are handled separately. This initial generation also picks up the unpublished changes from: - JDK-8330807: Update Manpage for obsoletion of ScavengeBeforeFullGC - JDK-8284500: Typo in Supported Named Extensions - BasicContraints - JDK-8324342: Doclet should default @since for a nested class to that of its enclosing class Thanks ------------- Commit messages: - 8330205: Initial troff manpage generation for JDK 24 Changes: https://git.openjdk.org/jdk/pull/19617/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19617&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330205 Stats: 66 lines in 28 files changed: 12 ins; 13 del; 41 mod Patch: https://git.openjdk.org/jdk/pull/19617.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19617/head:pull/19617 PR: https://git.openjdk.org/jdk/pull/19617

3 7

RFR: 8322568: JFR: Improve metadata for IEEE rounding mode fields
by Erik Gahlin 06 Jun '24

06 Jun '24

Could I have review of a couple of changes that align the style of the new event fields with other events, no abbreviations (env) and headline-style capitalization for the label. Testring: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/19560/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19560&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322568 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/19560.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19560/head:pull/19560 PR: https://git.openjdk.org/jdk/pull/19560

2 2