January 2024 - hotspot-jfr-dev

RFR: 8324220: jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java had 22 failures
by Raffaello Giulietti 24 Jan '24

24 Jan '24

Patch to fix failures after [8275338](https://bugs.openjdk.org/browse/JDK-8275338). ------------- Commit messages: - 8324220: jdk/jfr/event/io/TestSerializationMisdeclarationEvent.java had 22 failures Changes: https://git.openjdk.org/jdk/pull/17549/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17549&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324220 Stats: 13 lines in 1 file changed: 3 ins; 2 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/17549.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17549/head:pull/17549 PR: https://git.openjdk.org/jdk/pull/17549

2 2

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: 8324229: JFR: Temporarily disable assertion for missing object reference
by Erik Gahlin 20 Jan '24

20 Jan '24

Could I have a review of a change that temporarily disables an assertion. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/17504/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17504&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8324229 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/17504.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17504/head:pull/17504 PR: https://git.openjdk.org/jdk/pull/17504

2 2

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

[jdk22] RFR: 8323631: JfrTypeSet::write_klass can enqueue a CLD klass that is unloading
by Markus Grönlund 16 Jan '24

16 Jan '24

8323631: JfrTypeSet::write_klass can enqueue a CLD klass that is unloading ------------- Commit messages: - Backport e2d6023cb9667dc9911e0af421d6dd0c78f6bf58 Changes: https://git.openjdk.org/jdk22/pull/81/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=81&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323631 Stats: 58 lines in 1 file changed: 32 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jdk22/pull/81.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/81/head:pull/81 PR: https://git.openjdk.org/jdk22/pull/81

2 2

RFR: 8322675: JFR: Fail-fast mode when constants cannot be resolved
by Erik Gahlin 16 Jan '24

16 Jan '24

Could I have a review of PR that adds an assertion if a constant can't be resolved. Purpose is to find regressions before they make it into the release. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/17254/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17254&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8322675 Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/17254.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17254/head:pull/17254 PR: https://git.openjdk.org/jdk/pull/17254

2 2

RFR: 8323631: JfrTypeSet::write_klass can enqueue a CLD klass that is unloading
by Markus Grönlund 16 Jan '24

16 Jan '24

Greetings, [JDK-8316241](https://bugs.openjdk.org/browse/JDK-8316241) introduced a bug where a CLD klass that may be in the process of being unloaded can erroneously get enqueued (because it does not go through the proper registration for unloading). This is a result of the attempt to make artefact tagging deep, by transitively marking (and enqueuing) CLD klasses. However, during class unloading, it is possible that a CLD klass is itself being unloaded. There must be a check for this situation so that klasses being unloaded are not enqueued. Testing: jdk_jfr, stress testing Thanks Markus ------------- Commit messages: - 8323631 Changes: https://git.openjdk.org/jdk/pull/17434/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17434&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323631 Stats: 58 lines in 1 file changed: 32 ins; 26 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/17434.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17434/head:pull/17434 PR: https://git.openjdk.org/jdk/pull/17434

2 2

RFR: 8323425: JFR: Auto-generated filename doesn't work with time-limited recording
by Erik Gahlin 12 Jan '24

12 Jan '24

Could I have a review of a PR that fixes a bug when filename is set to a directory and the recording has a duration. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Updated - Initial Changes: https://git.openjdk.org/jdk/pull/17360/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17360&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323425 Stats: 150 lines in 4 files changed: 105 ins; 28 del; 17 mod Patch: https://git.openjdk.org/jdk/pull/17360.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17360/head:pull/17360 PR: https://git.openjdk.org/jdk/pull/17360

2 2

RFR: 8323188: JFR: Needless RESOURCE_ARRAY when sending EventOSInformation
by Denghui Dong 11 Jan '24

11 Jan '24

Hi, Please help review this fix that removes a needless resource array in TRACE_REQUEST_FUNC(OSInformation). Thanks ------------- Commit messages: - 8323188: JFR: Needless RESOURCE_ARRAY when sending EventOSInformation Changes: https://git.openjdk.org/jdk/pull/17307/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17307&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323188 Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod Patch: https://git.openjdk.org/jdk/pull/17307.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17307/head:pull/17307 PR: https://git.openjdk.org/jdk/pull/17307

2 5

[jdk22] RFR: 8323540: assert((!((((method)->is_trace_flag_set(((1 << 4) << 8))))))) failed: invariant
by Markus Grönlund 10 Jan '24

10 Jan '24

8323540: assert((!((((method)->is_trace_flag_set(((1 << 4) << 8))))))) failed: invariant ------------- Commit messages: - Backport c1282b57f50002edd08c93aed784390cca83b9b8 Changes: https://git.openjdk.org/jdk22/pull/57/files Webrev: https://webrevs.openjdk.org/?repo=jdk22&pr=57&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323540 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk22/pull/57.diff Fetch: git fetch https://git.openjdk.org/jdk22.git pull/57/head:pull/57 PR: https://git.openjdk.org/jdk22/pull/57

2 2