From fandreuzzi at openjdk.org  Sat Nov  1 11:48:04 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Sat, 1 Nov 2025 11:48:04 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
Message-ID: <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>

On Thu, 30 Oct 2025 06:01:48 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> It would be good if you could provide some ballpark figures on the number of events in a worst-case scenario, so we can determine what GC level is appropriate.

I wrote a simple pathological test with multiple threads interning random strings, [this](https://github.com/user-attachments/files/23282465/out-parallel.txt) is the worst I've seen: 100 deduplication rounds within `3.698s` and `3.729s`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3476289368

From ysuenaga at openjdk.org  Sun Nov  2 06:33:01 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Sun, 2 Nov 2025 06:33:01 GMT
Subject: RFR: 8370260: Test
 jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java timed out
In-Reply-To: <MH7MaWHIu7BABrAP6js51yF2ex5vgnDEhZI2YfbLj6A=.1f50e522-3c38-469d-8cf1-c0ea3ddb8f6e@github.com>
References: <MH7MaWHIu7BABrAP6js51yF2ex5vgnDEhZI2YfbLj6A=.1f50e522-3c38-469d-8cf1-c0ea3ddb8f6e@github.com>
Message-ID: <txQWh8s0Drt-effsTFzhSNQ_agyhwACgPuIIHIPZktQ=.f884c264-3d8e-406e-86e4-8678207dddf5@github.com>

On Mon, 27 Oct 2025 00:51:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The test failure was reported at jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java due to minidump timeout.
> `TestEmergencyDumpAtOOM` does not need minidump, so we can add `-XX:-CreateCoredumpOnCrash` to the test process.
> 
> This change works on Windows 11 Pro 25H2 and Fedora 42.

PING: Can I get a Reviewer? This is a test bug. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27993#issuecomment-3477496897

From egahlin at openjdk.org  Mon Nov  3 10:22:06 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 3 Nov 2025 10:22:06 GMT
Subject: RFR: 8370260: Test
 jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java timed out
In-Reply-To: <MH7MaWHIu7BABrAP6js51yF2ex5vgnDEhZI2YfbLj6A=.1f50e522-3c38-469d-8cf1-c0ea3ddb8f6e@github.com>
References: <MH7MaWHIu7BABrAP6js51yF2ex5vgnDEhZI2YfbLj6A=.1f50e522-3c38-469d-8cf1-c0ea3ddb8f6e@github.com>
Message-ID: <QUGAmp5DTJTW4nCUHV4mv7146ZM055BrLW25u1vgAt8=.ebdc8cc4-be74-4430-8c06-f11bd3e110ad@github.com>

On Mon, 27 Oct 2025 00:51:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The test failure was reported at jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java due to minidump timeout.
> `TestEmergencyDumpAtOOM` does not need minidump, so we can add `-XX:-CreateCoredumpOnCrash` to the test process.
> 
> This change works on Windows 11 Pro 25H2 and Fedora 42.

Marked as reviewed by egahlin (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27993#pullrequestreview-3410338404

From ysuenaga at openjdk.org  Mon Nov  3 14:29:29 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Mon, 3 Nov 2025 14:29:29 GMT
Subject: Integrated: 8370260: Test
 jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java timed out
In-Reply-To: <MH7MaWHIu7BABrAP6js51yF2ex5vgnDEhZI2YfbLj6A=.1f50e522-3c38-469d-8cf1-c0ea3ddb8f6e@github.com>
References: <MH7MaWHIu7BABrAP6js51yF2ex5vgnDEhZI2YfbLj6A=.1f50e522-3c38-469d-8cf1-c0ea3ddb8f6e@github.com>
Message-ID: <lDJnxI6T1DTrsI5liveayHmfh43s4crFGTAGPp2Txtg=.9a264cbc-ea06-4372-9bae-800bc325cebc@github.com>

On Mon, 27 Oct 2025 00:51:06 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> The test failure was reported at jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java due to minidump timeout.
> `TestEmergencyDumpAtOOM` does not need minidump, so we can add `-XX:-CreateCoredumpOnCrash` to the test process.
> 
> This change works on Windows 11 Pro 25H2 and Fedora 42.

This pull request has now been integrated.

Changeset: 20ff33cb
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/20ff33cbdf393818b63bb8989e1def0b2d470c4b
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8370260: Test jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java timed out

Reviewed-by: syan, egahlin

-------------

PR: https://git.openjdk.org/jdk/pull/27993

From egahlin at openjdk.org  Mon Nov  3 17:02:33 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 3 Nov 2025 17:02:33 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
Message-ID: <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>

On Sat, 1 Nov 2025 11:45:27 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> > It would be good if you could provide some ballpark figures on the number of events in a worst-case scenario, so we can determine what GC level is appropriate.
> 
> I wrote a simple pathological test with multiple threads interning random strings, [this](https://github.com/user-attachments/files/23282465/out-parallel.txt) is the worst I've seen: 100 deduplication rounds within `3.698s` and `3.729s`.

Thanks for investigating this. It doesn't sound that bad, the event could probably be enabled by default. The elapsed fields, are they the total since the JVM started or from the last round?

We typically try to avoid using "Bytes" in field names, since that information is already available in the content type. Perhaps something else could be used, newSize?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3481567424

From sgehwolf at openjdk.org  Tue Nov  4 07:09:47 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 4 Nov 2025 07:09:47 GMT
Subject: RFR: 8365606: Container code should not be using jlong/julong [v2]
In-Reply-To: <BghgrFW1h0BM6Ss32Yzjwgb17plt8WN7FM8jNxAczgY=.e09d0ca9-9056-4b59-ace8-228e9fe650b3@github.com>
References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com>
 <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>
 <oCHtTEO1QOxzB_wco1VSn_gv2NkUSbl8nsOUlnyK6-Q=.1ca20a9c-3717-45df-8991-cb7e1074c6b1@github.com>
 <DkPhrXwWHHptnQ50THfxKiJatf5-c7WOa67JW1IbXt8=.57054308-bfb9-4161-b476-cb2fd700d0e4@github.com>
 <InCQThI0WDqMUyk9_be7xVI4b_01G-fqVF1kmL87fFQ=.da75341f-01b4-4330-bcf3-2f2ead79fe29@github.com>
 <9uVKpiWCXvxcxhyg6V1seeSxyLm14lHEdOL_I07uVQs=.de1b0ed8-d006-49d5-a982-27556759415e@github.com>
 <BghgrFW1h0BM6Ss32Yzjwgb17plt8WN7FM8jNxAczgY=.e09d0ca9-9056-4b59-ace8-228e9fe650b3@github.com>
Message-ID: <REF4gCsr9gTLAgAm06ipMmCQH_v9wYBldXnEhUOBkhM=.a915f9d9-7a9b-4889-861b-c219eb86448d@github.com>

On Mon, 27 Oct 2025 09:17:02 GMT, Andrew Haley <aph at openjdk.org> wrote:

> > it wasn't because we wanted to figure out the color of the bike shed but rather how to write safer code that makes it less likely to accidentally introduce bugs because of type conflation.
> 
> This. A function that returns its value as a side effect on a reference parameter is (at best) a code smell.

Thanks for the comments. So what's the consensus then? As far as API surface is concerned I've modelled it after [JDK-8357086](https://bugs.openjdk.org/browse/JDK-8357086). It [introduces](https://github.com/openjdk/jdk/commit/d5d94db12a6d82a6fe9da18b5f8ce3733a6ee7e7) the side-effect/code smell issue. Do we want to re-open this discussion or proceed with this here. It's not clear to me.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3469549344

From egahlin at openjdk.org  Tue Nov  4 16:37:51 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 4 Nov 2025 16:37:51 GMT
Subject: RFR: 8370884: JFR: Overflow in aggregators
Message-ID: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>

Could I have a review of a change that fixes overflow issues for the jfr query aggregators?

Testing: jdk/jdk/jfr

Thanks
Erik

-------------

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/28135/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28135&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370884
  Stats: 58 lines in 1 file changed: 46 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/28135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28135/head:pull/28135

PR: https://git.openjdk.org/jdk/pull/28135

From fandreuzzi at openjdk.org  Tue Nov  4 21:27:22 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 4 Nov 2025 21:27:22 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v4]
In-Reply-To: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
Message-ID: <WgcXEQ5O4NHHKuvkOfRQrhlrTq9FfPbwiZXPZtwXlsk=.02793013-0aab-48a4-b031-feeb5751ba80@github.com>

> In this PR I introduce a new JFR event: `jdk.StringDeduplicationStatistics`
> 
> The new event is emitted every time a deduplication cycle happens.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision:

 - enable
 - bytes to size

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/c3c9a8db..e8644c68

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=02-03

  Stats: 5 lines in 3 files changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28015.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28015/head:pull/28015

PR: https://git.openjdk.org/jdk/pull/28015

From fandreuzzi at openjdk.org  Tue Nov  4 21:34:45 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Tue, 4 Nov 2025 21:34:45 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
 <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
Message-ID: <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>

On Mon, 3 Nov 2025 16:59:55 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> We typically try to avoid using "Bytes" in field names, since that information is already available in the content type. Perhaps something else could be used, newSize?

Sure: 586f413571c7c0354e9663888c81113065d991bf

> It doesn't sound that bad, the event could probably be enabled by default. 

I re-enabled the event in `default.jfc`: e8644c683a4290f0ae112b7c63a8a1fc1c85b27e

> The elapsed fields, are they the total since the JVM started or from the last round?

All fields in `EventStringDeduplicationStatistics` contain the diff since the last round:

jdk.StringDeduplicationStatistics {
  startTime = 21:31:19.604 (2025-11-04)
  duration = 0.000020 ms
  inspected = 8424
  known = 2898
  shared = 1247
  newStrings = 4279
  newSize = 255.0 kB
  replaced = 0
  deleted = 0
  deduplicated = 3331
  deduplicatedSize = 102.4 kB
  skippedDead = 6
  skippedIncomplete = 0
  skippedShared = 0
  activeElapsed = 1.85 ms
  processElapsed = 1.85 ms
  idleElapsed = 191 ms
  resizeTableElapsed = 0 s
  cleanupTableElapsed = 0 s
}


jdk.StringDeduplicationStatistics {
  startTime = 21:31:19.604 (2025-11-04)
  duration = 0.000030 ms
  inspected = 1
  known = 0
  shared = 0
  newStrings = 1
  newSize = 24 bytes
  replaced = 0
  deleted = 0
  deduplicated = 0
  deduplicatedSize = 0 bytes
  skippedDead = 0
  skippedIncomplete = 0
  skippedShared = 0
  activeElapsed = 0.00124 ms
  processElapsed = 0.00100 ms
  idleElapsed = 0.000780 ms
  resizeTableElapsed = 0 s
  cleanupTableElapsed = 0 s
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3488086974

From fandreuzzi at openjdk.org  Wed Nov  5 09:09:05 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Wed, 5 Nov 2025 09:09:05 GMT
Subject: RFR: 8370884: JFR: Overflow in aggregators
In-Reply-To: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>
References: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>
Message-ID: <aWBQhs0Elng4DH42rJzJopWwwATxfcsxKtaFcY03VtA=.26148dff-e7e8-4748-a5b5-f64c440dc8d1@github.com>

On Tue, 4 Nov 2025 16:23:53 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that fixes overflow issues for the jfr query aggregators?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/query/Function.java line 383:

> 381:                     seconds = Math.addExact(s, nanosToAdd / NANOS_PER_SECOND);
> 382:                     nanos = nanos + nanosToAdd % NANOS_PER_SECOND;
> 383:                     hasValue = true;;

Suggestion:

                    hasValue = true;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28135#discussion_r2493592341

From egahlin at openjdk.org  Wed Nov  5 13:59:07 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 5 Nov 2025 13:59:07 GMT
Subject: RFR: 8370884: JFR: Overflow in aggregators [v2]
In-Reply-To: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>
References: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>
Message-ID: <VtS_WAreDVfuARDYsuxduLlDSUXIONUWg9PGJ7Yo23M=.c2b9d20a-7179-4db0-90b0-fb2da8c1f123@github.com>

> Could I have a review of a change that fixes overflow issues for the jfr query aggregators?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:

  Minor fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28135/files
  - new: https://git.openjdk.org/jdk/pull/28135/files/c7f8dd73..2bdd6968

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28135&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28135&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28135.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28135/head:pull/28135

PR: https://git.openjdk.org/jdk/pull/28135

From egahlin at openjdk.org  Wed Nov  5 14:18:17 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 5 Nov 2025 14:18:17 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
 <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
 <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU
 6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>
Message-ID: <XuUowo5n1fE1BP8RzyifQbT9wzt5aK73ssUGeGpVkOw=.d2f3da1a-b61a-435a-b7e1-9c29004e4ad6@github.com>

On Tue, 4 Nov 2025 21:32:19 GMT, Francesco Andreuzzi <fandreuzzi at openjdk.org> wrote:

> > The elapsed fields, are they the total since the JVM started or from the last round?
> 
> All fields in `EventStringDeduplicationStatistics` contain the diff since the last round:
> 

Since the event has a duration, I wonder if the event should be called StringDeduplication, similar to Compilation or GarbageCollection? As I understand it, the event represents a round of deduplication. All other events called statistics are instantaneous events.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3491455070

From mgronlun at openjdk.org  Wed Nov  5 18:29:25 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 5 Nov 2025 18:29:25 GMT
Subject: RFR: 8370884: JFR: Overflow in aggregators [v2]
In-Reply-To: <VtS_WAreDVfuARDYsuxduLlDSUXIONUWg9PGJ7Yo23M=.c2b9d20a-7179-4db0-90b0-fb2da8c1f123@github.com>
References: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>
 <VtS_WAreDVfuARDYsuxduLlDSUXIONUWg9PGJ7Yo23M=.c2b9d20a-7179-4db0-90b0-fb2da8c1f123@github.com>
Message-ID: <NK3WW9tI8PRllhA4CGS7Rjvg7bJ0wd1rrAHDlZ3c9yg=.b2bcd78a-891d-4458-a65b-5130792ede73@github.com>

On Wed, 5 Nov 2025 13:59:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of a change that fixes overflow issues for the jfr query aggregators?
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor fixes

Marked as reviewed by mgronlun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28135#pullrequestreview-3423711065

From fandreuzzi at openjdk.org  Thu Nov  6 01:25:00 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 6 Nov 2025 01:25:00 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v5]
In-Reply-To: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
Message-ID: <FQ78Ajjh6pkAcuPL7lRGx84lWSiSDhfzoIMdQdMI3Ao=.cc85b432-40ae-4fad-9d06-e854ac4664e9@github.com>

> In this PR I introduce a new JFR event: `jdk.StringDeduplicationStatistics`
> 
> The new event is emitted every time a deduplication cycle happens.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  no start

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/e8644c68..3793befd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28015.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28015/head:pull/28015

PR: https://git.openjdk.org/jdk/pull/28015

From fandreuzzi at openjdk.org  Thu Nov  6 01:59:41 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 6 Nov 2025 01:59:41 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication [v6]
In-Reply-To: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
Message-ID: <qBi2IqPdCJVfm__ynPaUGcn83hLkC33v2yTeGTMPFMg=.0537cbb1-3762-4d8d-8ea2-32dc171ca060@github.com>

> In this PR I introduce a new JFR event: `jdk.StringDeduplication`
> 
> The new event is emitted every time a deduplication cycle happens.
> 
> Passes tier1 and tier2 (fastdebug).

Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision:

  rename. start/end time

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28015/files
  - new: https://git.openjdk.org/jdk/pull/28015/files/3793befd..090c02bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=04-05

  Stats: 12 lines in 6 files changed: 5 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/28015.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28015/head:pull/28015

PR: https://git.openjdk.org/jdk/pull/28015

From fandreuzzi at openjdk.org  Thu Nov  6 01:59:42 2025
From: fandreuzzi at openjdk.org (Francesco Andreuzzi)
Date: Thu, 6 Nov 2025 01:59:42 GMT
Subject: RFR: 8037914: Add JFR event for string deduplication
In-Reply-To: <XuUowo5n1fE1BP8RzyifQbT9wzt5aK73ssUGeGpVkOw=.d2f3da1a-b61a-435a-b7e1-9c29004e4ad6@github.com>
References: <iqJq5mxDsFzspqRXq4Rq5mviA91kk2CYqJrv7Ayf01E=.76e937f2-5f06-4e8b-861e-0009291d7cf4@github.com>
 <Lh7yi-weOQ6z8v1FXnonl-Afq-wETGR6MGK2r4tD0CE=.94177be3-2799-417b-8c2e-894787994fe5@github.com>
 <LfPeHkLYdHgLvvT0016QumPDF8hs203PGE8vkQjLp4o=.4033dffc-0f7f-4aa0-95e2-840d0a17a964@github.com>
 <o0Yscf86-NYz3Su-u6JwIkV9N9LjE-dHcoCcmF1lidk=.f5037b09-2760-45e8-8212-c375599d8e12@github.com>
 <lxLAih5JOb_cjb-iflzI_SL-kIS_X6Bv4fg1WkERGsk=.f75eb730-a629-4800-a6bf-6a82a61a7efc@github.com>
 <ABZVyxh8y0e3JMopfIqQAz4TBjdzdYN0tIbrdYJ7OhE=.20543f63-96df-47d0-931d-8d7d7744f0b7@github.com>
 <jTmtXNzYMxfFUKeHtKXieMsuzWvwgWWP_OBbSTAv2mU=.7b5be0bd-fee5-4637-b4de-620b3751f358@github.com>
 <B3cbEvuQFLIJWfnrCs4OMf5Iqm3zBxQ6TXrpMN6x-VM=.7e7af4a8-1859-4233-9ff3-6fef34c45948@github.com>
 <1OO6CrVzIrUtVeqvYA5rwGSuKsrybfUJUSN0B3AS8FM=.3edb6e0a-621c-455f-8191-7eb76d669243@github.com>
 <ks4_YRewinRZkGRCr2DnpkwhLnAUvEFHD1XuJbns4IM=.83b98a45-b5f3-4cab-8ef7-5d4fc1c3b931@github.com>
 <UJvduGhll3wT4T-dpkf2T_TS7VfHNEzU0hU
 6Q0IVeRg=.0fdcf8fd-8930-4da1-8b58-f1c21bf262d2@github.com>
 <XuUowo5n1fE1BP8RzyifQbT9wzt5aK73ssUGeGpVkOw=.d2f3da1a-b61a-435a-b7e1-9c29004e4ad6@github.com>
Message-ID: <9Ne0a7oeIyXjdA_VFbfbX52u7WRgTonCp_jI906V6DQ=.8e10796c-6160-4e08-9595-1b35491dcda0@github.com>

On Wed, 5 Nov 2025 14:15:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> > > The elapsed fields, are they the total since the JVM started or from the last round?
> > 
> > 
> > All fields in `EventStringDeduplicationStatistics` contain the diff since the last round:
> 
> Since the event has a duration, I wonder if the event should be called StringDeduplication, similar to Compilation or GarbageCollection? As I understand it, the event represents a round of deduplications. All other events called statistics are instantaneous events.

Yeah this makes sense, thanks. See 090c02bce5ba79cff378bd48de0fc0849f532250

-------------

PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3494458707

From egahlin at openjdk.org  Thu Nov  6 13:43:22 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 6 Nov 2025 13:43:22 GMT
Subject: Integrated: 8370884: JFR: Overflow in aggregators
In-Reply-To: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>
References: <b3qiQanZaao4QAKRchBqvJ5mxrfTPBxv4nsWLaENrWo=.d6262e48-52fc-496e-b285-6fcf3884e9cb@github.com>
Message-ID: <MjT5E0WVkSQIwjJNChZh57gXQF6vufa8dS7N0RNyyYM=.72494da4-41ff-459d-8033-db5c42f8a7d5@github.com>

On Tue, 4 Nov 2025 16:23:53 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that fixes overflow issues for the jfr query aggregators?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: df414e0d
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/df414e0d19c1ed68f151d84dbb481a9dd6c65539
Stats:     58 lines in 1 file changed: 46 ins; 0 del; 12 mod

8370884: JFR: Overflow in aggregators

Reviewed-by: mgronlun

-------------

PR: https://git.openjdk.org/jdk/pull/28135

From egahlin at openjdk.org  Fri Nov  7 09:10:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 7 Nov 2025 09:10:41 GMT
Subject: RFR: 8365972: JFR: ThreadDump and ClassLoaderStatistics events may
 cause back to back rotations
Message-ID: <HvnohQmVdFoPeEbUcFsxge_DeEv_0xSGhEm7Z-6mqeM=.9833bbf4-0091-46c6-981a-940c1e545e9d@github.com>

Could I have a review of a PR that changes how`jdk.ThreadDump` and `jdk.ClassLoaderStatistics` events are emitted?

This change is a short-term solution for users who currently suffer from excessive event data, both in terms of count and size, being emitted at the beginning of a chunk. This high volume of events uses up so much chunk space that it immediately triggers a rotation. That rotation can quickly lead to another, causing back-to-back rotations. As a result, the default maximum size of 250 MB may only cover less than 30 seconds of data. This can happen with the thread dump event if there are many threads (1000) with a large number frames (250). It can also occur with applications that have hundreds of thousands of class loaders.

The fix is to emit those two events when a new recording starts and then only at the end of every chunk. That way, each chunk contains the event at least once, and users can always see the delta from the beginning to the end of a recording. Emitting events at the end of chunk doesn't cause back-to-back rotations, since they are emitted after the max chunk threshold has been triggered.

(The long-term plan is to change all events with the period `everyChunk` in default.jfc to work this way, but it is too intrusive to backport, and we need more time to figure out how it should work. One idea is to redefine  `<period>everyChunk</period>`to work in this new way. Another idea is to introduce a new representation called `rotation` for this new behavior, and keep `everyChunk` as is. A third idea is to introduce `beginRecording` and allow multiple values in a setting so you would have `<period>beginRecording,endChunk</period>`)

-------------

Commit messages:
 - Add test
 - Initial

Changes: https://git.openjdk.org/jdk/pull/28153/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28153&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365972
  Stats: 145 lines in 4 files changed: 140 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28153.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28153/head:pull/28153

PR: https://git.openjdk.org/jdk/pull/28153

From mgronlun at openjdk.org  Fri Nov  7 09:49:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 7 Nov 2025 09:49:03 GMT
Subject: RFR: 8365972: JFR: ThreadDump and ClassLoaderStatistics events may
 cause back to back rotations
In-Reply-To: <HvnohQmVdFoPeEbUcFsxge_DeEv_0xSGhEm7Z-6mqeM=.9833bbf4-0091-46c6-981a-940c1e545e9d@github.com>
References: <HvnohQmVdFoPeEbUcFsxge_DeEv_0xSGhEm7Z-6mqeM=.9833bbf4-0091-46c6-981a-940c1e545e9d@github.com>
Message-ID: <VEvrtEJpQK9W7N9FWg2H20_NwiOuE380P2FBNsrwwlw=.51fc4fa0-4c3f-49d9-a34e-dae6fccdf5b8@github.com>

On Wed, 5 Nov 2025 16:35:57 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that changes how`jdk.ThreadDump` and `jdk.ClassLoaderStatistics` events are emitted?
> 
> This change is a short-term solution for users who currently suffer from excessive event data, both in terms of count and size, being emitted at the beginning of a chunk. This high volume of events uses up so much chunk space that it immediately triggers a rotation. That rotation can quickly lead to another, causing back-to-back rotations. As a result, the default maximum size of 250 MB may only cover less than 30 seconds of data. This can happen with the thread dump event if there are many threads (1000) with a large number frames (250). It can also occur with applications that have hundreds of thousands of class loaders.
> 
> The fix is to emit those two events when a new recording starts and then only at the end of every chunk. That way, each chunk contains the event at least once, and users can always see the delta from the beginning to the end of a recording. Emitting events at the end of chunk doesn't cause back-to-back rotations, since they are emitted after the max chunk threshold has been triggered.
> 
> (The long-term plan is to change all events with the period `everyChunk` in default.jfc to work this way, but it is too intrusive to backport, and we need more time to figure out how it should work. One idea is to redefine  `<period>everyChunk</period>`to work in this new way. Another idea is to introduce a new representation called `rotation` for this new behavior, and keep `everyChunk` as is. A third idea is to introduce `beginRecording` and allow multiple values in a setting so you would have `<period>beginRecording,endChunk</period>`)

Marked as reviewed by mgronlun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28153#pullrequestreview-3432635321

From mbaesken at openjdk.org  Fri Nov  7 13:31:38 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 7 Nov 2025 13:31:38 GMT
Subject: RFR: 8371473: Problem list TestEmergencyDumpAtOOM.java on ppc64
 platforms related to JDK-8371014
Message-ID: <7y9Im02ui6uGUTDorUzOCwY4trO6TVAOed9VftrhxhU=.dd34b10c-5389-4c81-a538-1106405b68ee@github.com>

TestEmergencyDumpAtOOM.java fails on ppc64 platforms because of issues with the emergency writing of a jfr file in crash cases.

-------------

Commit messages:
 - JDK-8371473

Changes: https://git.openjdk.org/jdk/pull/28193/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8371473
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/28193.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28193/head:pull/28193

PR: https://git.openjdk.org/jdk/pull/28193

From mdoerr at openjdk.org  Fri Nov  7 13:31:39 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 7 Nov 2025 13:31:39 GMT
Subject: RFR: 8371473: Problem list TestEmergencyDumpAtOOM.java on ppc64
 platforms related to JDK-8371014
In-Reply-To: <7y9Im02ui6uGUTDorUzOCwY4trO6TVAOed9VftrhxhU=.dd34b10c-5389-4c81-a538-1106405b68ee@github.com>
References: <7y9Im02ui6uGUTDorUzOCwY4trO6TVAOed9VftrhxhU=.dd34b10c-5389-4c81-a538-1106405b68ee@github.com>
Message-ID: <5XwAGRIxub7YGkqVdQSgvL1MYJrMBJUkZX1MrVLPKSE=.01ca67af-01bc-49a3-9071-c0d751ece3a1@github.com>

On Fri, 7 Nov 2025 13:20:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> TestEmergencyDumpAtOOM.java fails on ppc64 platforms because of issues with the emergency writing of a jfr file in crash cases.

LGTM. Thanks!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28193#pullrequestreview-3433891731

From phubner at openjdk.org  Fri Nov  7 13:44:04 2025
From: phubner at openjdk.org (Paul =?UTF-8?B?SMO8Ym5lcg==?=)
Date: Fri, 7 Nov 2025 13:44:04 GMT
Subject: RFR: 8371473: Problem list TestEmergencyDumpAtOOM.java on ppc64
 platforms related to JDK-8371014
In-Reply-To: <7y9Im02ui6uGUTDorUzOCwY4trO6TVAOed9VftrhxhU=.dd34b10c-5389-4c81-a538-1106405b68ee@github.com>
References: <7y9Im02ui6uGUTDorUzOCwY4trO6TVAOed9VftrhxhU=.dd34b10c-5389-4c81-a538-1106405b68ee@github.com>
Message-ID: <3TYPtkTGhIPkVqVHpcMb1bdL7RbsLQoUUZGdtCKjJUQ=.25ce32cd-c1d6-4a60-bc05-7479e29d0e81@github.com>

On Fri, 7 Nov 2025 13:20:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> TestEmergencyDumpAtOOM.java fails on ppc64 platforms because of issues with the emergency writing of a jfr file in crash cases.

Marked as reviewed by phubner (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28193#pullrequestreview-3434009407