October 2024 - hotspot-jfr-dev

RFR: 8310996: Add JFR event for connect operations
by Tim Prinzing 17 Feb '25

17 Feb '25

Adds a JFR event for socket connect operations. Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. ------------- Commit messages: - fix default settings - fix merge - Merge branch 'master' into JDK-8310996 - added tests and support for sockets. - 8310996: Add JFR event for connect operations Changes: https://git.openjdk.org/jdk/pull/21528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310996 Stats: 247 lines in 12 files changed: 236 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528 PR: https://git.openjdk.org/jdk/pull/21528

6 42

RFR: 8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless
by Leonid Mesnik 06 Dec '24

06 Dec '24

Test jdk/jfr/startupargs/TestStartDuration.java checks duration, the time might be too small for stress options like Xcomp. So it makes sense to mark it as flaglesss. ------------- Commit messages: - 8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless Changes: https://git.openjdk.org/jdk/pull/21237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340969 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21237/head:pull/21237 PR: https://git.openjdk.org/jdk/pull/21237

3 3

RFR: 8342285: Mark jdk/jfr/api/event/TestIsEnabledMultiple.java as intermittent
by SendaoYan 21 Nov '24

21 Nov '24

Hi all, The test `jdk/jfr/api/event/TestIsEnabledMultiple.java` has been observed intermittent failure several times. I think we should mark this test as intermittent failure. Trivial fix, no risk. ------------- Commit messages: - 8342285: Mark jdk/jfr/api/event/TestIsEnabledMultiple.java as intermittent Changes: https://git.openjdk.org/jdk/pull/21666/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21666&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342285 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21666.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21666/head:pull/21666 PR: https://git.openjdk.org/jdk/pull/21666

1 3

RFR: 8279016: JFR Leak Profiler is broken with Shenandoah
by Aleksey Shipilev 06 Nov '24

06 Nov '24

While testing unrelated Shenandoah patch, I caught a GC assert when Leak Profiler was running ([JDK-8337194](https://bugs.openjdk.org/browse/JDK-8337194)) Leak Profiler is notorious in using the mark words for its own needs. We have been trying to mitigate its impact on GCs by moving to separate bitsets for tracking marked objects, or by treating "marked without fwdptr" as "JFR marked" and handling it. But this is not reliable, since things like [putting indexes in mark word](https://github.com/openjdk/jdk/blob/3baff2af6a30cc6cb2e0d4391db1cf7e6… sneak in. This is okay for Leak Profiler alone, since it restores the mark words after the operation completes, but that is still not enough when GC is already running. I say we side-step this whack-a-mole by cleanly bailing from JFR op, when we know it is unsafe to do. I thought to use `VM_Operation::doit_prologue`, but I think GC start may sneak in between checking in prologue and op start. This realistically only affects Shenandoah. All other STW collectors would never see what Leak Profiler did with mark words. ZGC would not see it, since it does not care about mark words for its own operation. Additional testing: - [x] `jdk/jfr/event/oldobject/` pass by default (100x times) - [x] `jdk/jfr/event/oldobject/` pass with `-XX:+UseShenandoah` (100x) ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/20328/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20328&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8279016 Stats: 29 lines in 4 files changed: 29 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20328.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20328/head:pull/20328 PR: https://git.openjdk.org/jdk/pull/20328

7 46

Re: RFR: 8343177: JFR: Remove critical section for thread id assignment [v3]
by Markus Grönlund 04 Nov '24

04 Nov '24

> Greetings, > > With Loom, JFR had to change the assignment of unique thread IDs to threads. For JavaThreads, a dependency exists on the threadObj before the thread ID can be determined and assigned. We currently have a lazy assignment scheme that assigns on first use. Several threads, such as thread iterators and sampling threads, can issue the first use. Hence, a critical section protects assignments. > > However, a critical section at this location makes it challenging to build robust signal handlers, for example, because we cannot read the thread ID. > > We can remove this critical section with careful rearrangements, ensuring threads are only assigned a thread ID in thread state _thread_new (a thread state that at least the JFR sampler and the JFR iterators exclude). > > The problem child is JNI attaching threads, created directly into state _thread_in_vm and added to the threads list before the creation and assignment of the threadObj. We can also manage this case by being careful when we sample such a thread, alternatively allowing for a thread ID of 0 or taking account of the 'attaching via jni' property. > > Testing: jdk_jfr Tier 1- 3, Stress testing > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: rename primordial to main thread ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21756/files - new: https://git.openjdk.org/jdk/pull/21756/files/c73725b1..6053116e Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21756&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21756&range=01-02 Stats: 7 lines in 5 files changed: 0 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/21756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21756/head:pull/21756 PR: https://git.openjdk.org/jdk/pull/21756

2 3

RFR: 8343057: JFR: Sorting in 'jfr view' can violate contract
by Erik Gahlin 31 Oct '24

31 Oct '24

Could I have a review of a change that improves the comparator used with 'jfr view'? Testing: jdk/jdk/jfr + comparison of output from 'jfr view all-views' before and after the change Thanks Erik ------------- Commit messages: - Fix trailing whitespaces - Fix trailing whitespaces - Initial Changes: https://git.openjdk.org/jdk/pull/21713/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21713&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343057 Stats: 55 lines in 1 file changed: 49 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/21713.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21713/head:pull/21713 PR: https://git.openjdk.org/jdk/pull/21713

2 5

Re: RFR: 8343177: JFR: Remove critical section for thread id assignment
by David Holmes 31 Oct '24

31 Oct '24

On Tue, 29 Oct 2024 10:28:45 GMT, Markus Grönlund <mgronlun(a)openjdk.org> wrote: > Greetings, > > With Loom, JFR had to change the assignment of unique thread IDs to threads. For JavaThreads, a dependency exists on the threadObj before the thread ID can be determined and assigned. We currently have a lazy assignment scheme that assigns on first use. Several threads, such as thread iterators and sampling threads, can issue the first use. Hence, a critical section protects assignments. > > However, a critical section at this location makes it challenging to build robust signal handlers, for example, because we cannot read the thread ID. > > We can remove this critical section with careful rearrangements, ensuring threads are only assigned a thread ID in thread state _thread_new (a thread state that at least the JFR sampler and the JFR iterators exclude). > > The problem child is JNI attaching threads, created directly into state _thread_in_vm and added to the threads list before the creation and assignment of the threadObj. We can also manage this case by being careful when we sample such a thread, alternatively allowing for a thread ID of 0 or taking account of the 'attaching via jni' property. > > Testing: jdk_jfr Tier 1- 3, Stress testing > > Thanks > Markus Sorry I struggled to map the code changes to the description of the changes. I think I'm missing some background context here - what is the "traceid" of a thread? src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 106: > 104: assert(Thread::is_starting_thread(jt), "invariant"); > 105: assert(jt->threadObj() == nullptr, "invariant"); > 106: jt->jfr_thread_local()->_jvm_thread_id = 1; Is this supposed to reflect the `java.lang.Thread` thread-id? If so this is changing to 3 with the object monitor virtual thread changes. src/hotspot/share/jfr/support/jfrThreadLocal.cpp line 438: > 436: > 437: #ifdef ASSERT > 438: static bool assignment_precondition(const Thread* t, JfrThreadLocal* tl) { Suggestion: static bool can_assign(const Thread* t, JfrThreadLocal* tl) { src/hotspot/share/runtime/thread.hpp line 505: > 503: // Sets the argument thread as starting thread. Returns failure if thread > 504: // creation fails due to lack of memory, too many threads etc. > 505: static bool set_as_starting_thread(JavaThread* jt); Why change this? Overall I don't understand the "starting thread" changes. ------------- PR Review: https://git.openjdk.org/jdk/pull/21756#pullrequestreview-2403653437 PR Review Comment: https://git.openjdk.org/jdk/pull/21756#discussion_r1821908468 PR Review Comment: https://git.openjdk.org/jdk/pull/21756#discussion_r1821907262 PR Review Comment: https://git.openjdk.org/jdk/pull/21756#discussion_r1821901961

3 9

Re: RFR: 8343177: JFR: Remove critical section for thread id assignment [v2]
by Markus Grönlund 31 Oct '24

31 Oct '24

> Greetings, > > With Loom, JFR had to change the assignment of unique thread IDs to threads. For JavaThreads, a dependency exists on the threadObj before the thread ID can be determined and assigned. We currently have a lazy assignment scheme that assigns on first use. Several threads, such as thread iterators and sampling threads, can issue the first use. Hence, a critical section protects assignments. > > However, a critical section at this location makes it challenging to build robust signal handlers, for example, because we cannot read the thread ID. > > We can remove this critical section with careful rearrangements, ensuring threads are only assigned a thread ID in thread state _thread_new (a thread state that at least the JFR sampler and the JFR iterators exclude). > > The problem child is JNI attaching threads, created directly into state _thread_in_vm and added to the threads list before the creation and assignment of the threadObj. We can also manage this case by being careful when we sample such a thread, alternatively allowing for a thread ID of 0 or taking account of the 'attaching via jni' property. > > Testing: jdk_jfr Tier 1- 3, Stress testing > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: can_assign ------------- Changes: - all: https://git.openjdk.org/jdk/pull/21756/files - new: https://git.openjdk.org/jdk/pull/21756/files/4de0844b..c73725b1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=21756&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21756&range=00-01 Stats: 4 lines in 1 file changed: 1 ins; 1 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21756.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21756/head:pull/21756 PR: https://git.openjdk.org/jdk/pull/21756

2 3

RFR: 8343026: JFR: Index into fields in the topFrame
by Erik Gahlin 29 Oct '24

29 Oct '24

Could I have a review of a change that allows 'jfr view' queries to reference nested fields for a top frame. Testing: jdk/jdk/jfr and diff of 'jfr view all-views' before and after the change. This change will not impact the output of the exiting views, but it helps OpenJDK developers diagnose issues, for example, print 'lineNumber', (frame) 'type' and 'bytecodeIndex' of the top frame. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/21705/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21705&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343026 Stats: 175 lines in 4 files changed: 88 ins; 81 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/21705.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21705/head:pull/21705 PR: https://git.openjdk.org/jdk/pull/21705

3 7

RFR: 8341131: Some jdk/jfr/event/compiler tests shouldn't be executed with Xcomp
by Leonid Mesnik 08 Oct '24

08 Oct '24

Few jdk/jfr/event/compiler tests sensitive to compile flags and shouldn't be executed with Xcomp. ------------- Commit messages: - fixed requires. Changes: https://git.openjdk.org/jdk/pull/21239/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21239&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341131 Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/21239.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21239/head:pull/21239 PR: https://git.openjdk.org/jdk/pull/21239

2 2