December 2023 - hotspot-jfr-dev

RFR: 8310994: Add JFR event for selection operations
by Tim Prinzing 25 Jun '24

25 Jun '24

Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. Emit the event from SelectorImpl::lockAndDoSelect Test at jdk.jfr.event.io.TestSelectionEvents ------------- Commit messages: - remove trailing whitespace - event logic outside of the lock, selector in try block - remove unused import - fix TestConfigure failure - add event defaults - Merge branch 'master' into JDK-8310994 - minor test cleanup - Merge branch 'master' into JDK-8310994 - 8310994: Add JFR event for selection operations Changes: https://git.openjdk.org/jdk/pull/16710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310994 Stats: 265 lines in 9 files changed: 264 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710 PR: https://git.openjdk.org/jdk/pull/16710

6 40

RFR: 8276125: RunThese24H.java SIGSEGV in JfrThreadGroup::thread_group_id
by Markus Grönlund 04 Jun '24

04 Jun '24

Greetings, please help review this changeset. Details are listed in the the JIRA issue. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8276125 Changes: https://git.openjdk.java.net/jdk/pull/6702/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6702&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276125 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6702.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6702/head:pull/6702 PR: https://git.openjdk.java.net/jdk/pull/6702

5 6

RFR: 8294978: Convert 5 test/jdk/jdk/jfr tests from ASM library to Classfile API
by Chen Liang 03 May '24

03 May '24

Converted these tests to Classfile API and some of the constants to Constant API. InstrumentationCallback.callback wasn't changed to a record since I cannot figure out how to ship a nested record class with InstrumentationCallback in a jar. ------------- Commit messages: - Convert jdk.jfr tests to ASM Changes: https://git.openjdk.org/jdk/pull/13072/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294978 Stats: 283 lines in 5 files changed: 75 ins; 108 del; 100 mod Patch: https://git.openjdk.org/jdk/pull/13072.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13072/head:pull/13072 PR: https://git.openjdk.org/jdk/pull/13072

3 19

RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump
by Taizo Kurashige 27 Feb '24

27 Feb '24

Hi, I fixed the typos for JFR.start and JFR.dump. Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. Could someone please review it? ------------- Commit messages: - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump Changes: https://git.openjdk.org/jdk/pull/16413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313710 Stats: 114 lines in 3 files changed: 0 ins; 0 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/16413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16413/head:pull/16413 PR: https://git.openjdk.org/jdk/pull/16413

3 21

Priority redistribution in Old Object Sample event
by Galder Zamarreno 24 Jan '24

24 Jan '24

Hi, I've been porting over JFR Old Object Sample event to GraalVM and I had the following doubt about the code in HotSpot: I'm trying to understand the code in [1]: ``` // push span onto previous if (previous != NULL) { _priority_queue->remove(previous); previous->add_span(sample->span()); _priority_queue->push(previous); } ``` This code is related to old object sampling. When the queue is full, samples that have been GC'd are removed from the queue. To do so it takes its previous (from the list view) and adds the span of the removed dead object onto it. Basically, I'm wondering why this is done this way. My initial gut feeling when I first saw the code is that it does it so that the priority queue does not get too imbalanced (it uses a heap underneath) when removing objects, but that only makes sense to me if the previous is not the previous object sampled based on time, but the previous object sampled based on the order of the priority queue, so that's not what seems to happen. I'm wondering now if the fact that the list view is ordered by insertion time is relevant here. Is it maybe trying to give more importance (by increasing its span) to surviving objects that are near in time to those that have been garbage collected? Something that's probably related to this is how the span is initially calculated. This is done in [2], which you can find below: ``` _total_allocated += allocated; const size_t span = _total_allocated - _priority_queue->total(); ``` Again when I first looked at it, I thought: well that's just equivalent to: ``` const size_t span = allocated; ``` But clearly things are more nuanced than that. The only documentation I've found so far is in Marcus' blog post [3]: > If sampled objects are garbage collected, they are removed and the priority redistributed to the neighbours. The priority is called span, and is currently the size of the allocation, giving more weight to larger (therefore more severe) leaks. Unfortunately what is a neighbour is not explained, nor why the priority gets redistributed. Thanks Galder [1] https://github.com/openjdk/jdk17u-dev/blob/master/src/hotspot/share/jfr/lea… [2] https://github.com/openjdk/jdk17u-dev/blob/ef86ea2842b1a204834291d9d6665bfc… [3] https://hirt.se/blog/?p=1055

4 7

RFR: 8275338: Add JFR events for notable serialization situations
by Raffaello Giulietti 18 Jan '24

18 Jan '24

Adds serialization misdeclaration events to JFR. ------------- Commit messages: - Make use of EventNames. - Merge branch 'master' into 8275338 - 8275338: Add JFR events for notable serialization situations Changes: https://git.openjdk.org/jdk/pull/17129/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17129&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8275338 Stats: 769 lines in 10 files changed: 769 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17129.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17129/head:pull/17129 PR: https://git.openjdk.org/jdk/pull/17129

5 74

RFR: 8321698: JFR asserts in write_classloader: failed invariant
by Markus Grönlund 09 Jan '24

09 Jan '24

Greetings, I have reviewed the JFR tagging mechanism, which lacks proper transitivity in certain situations. For example, when tagging a PackageEntry or a ModuleEntry, no tag information is set for the ModuleEntry's CLD and its class_loader_klass. The assert then fires when writing the CLD of a ModuleEntry, should its CLD not have been tagged by some other means (some other direct usage). The tagging must, in general, become deeper than what is done today, i.e. it must cover the transitive closure of a Klass, which involves two branches: 1) Klass -> CLD -> class_loader_klass 2) Klass -> PkgEntry -> ModuleEntry -> CLD -> class_loader_klass A Klass under its closure can be treated as a node in a binary tree. Its closure (subtree) is covered by writing and tagging of artifacts using preorder traversal by recursing its CLD klasses. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - 8321698 Changes: https://git.openjdk.org/jdk/pull/17177/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17177&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8321698 Stats: 928 lines in 4 files changed: 395 ins; 315 del; 218 mod Patch: https://git.openjdk.org/jdk/pull/17177.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17177/head:pull/17177 PR: https://git.openjdk.org/jdk/pull/17177

2 4

RFR: 8322489 : 22-b27: Up to 7% regression in all Footprint3-*-G1/ZGC
by Markus Grönlund 08 Jan '24

08 Jan '24

Greetings, A footprint regression was accidentally introduced with [JDK-8211238](https://bugs.openjdk.org/browse/JDK-8211238). A small part of the JFR system had to be initialized early to support the functionality. We later decided that we only support this functionality iff the system is started with -XX:StartFlightRecording on the command-line. This PR will adjust to only perform early initialization under this premise. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8322489 Changes: https://git.openjdk.org/jdk/pull/17179/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17179&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322489 Stats: 47 lines in 5 files changed: 29 ins; 9 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/17179.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17179/head:pull/17179 PR: https://git.openjdk.org/jdk/pull/17179

2 4

JFR Recordings Missing Periodic Events
by Carter Kozak 14 Dec '23

14 Dec '23

Hi, I've run into a strange issue with JFR recordings on Java 21 when taking multiple JFR recordings. The first recording works as expected. If I do not immediately start the next recording, periodic JFR events are no longer produced. Events based on actions still appear (e.g. virtual thread pinning), but periodic events are missing. I cannot reproduce this issue on Java 17, but it does seem to be 100% reproducible on Java 21 (including a 21.0.1+12 fastdebug build). I've created a minimal reproducer here with github-actions executing the main method using both jdk-17 and jdk-21 to illustrate the failure. https://github.com/carterkozak/periodic-event-repro/blob/develop/src/main/j… I haven't had a chance to dig into the root cause quite yet, but figured I'd share for awareness in case folks have ideas. Best, Carter Kozak

2 4

RFR: 8322057: Memory leaks in creating jfr symbol array
by Zhengyu Gu 14 Dec '23

14 Dec '23

A small fix to avoid memory leak when temporary c string is allocated in c heap. ------------- Commit messages: - 8322057: Memory leaks in creating jfr symbol array Changes: https://git.openjdk.org/jdk/pull/17099/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17099&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322057 Stats: 8 lines in 2 files changed: 8 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17099.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17099/head:pull/17099 PR: https://git.openjdk.org/jdk/pull/17099

2 3