From syan at openjdk.org  Tue Apr  1 06:28:23 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 1 Apr 2025 06:28:23 GMT
Subject: RFR: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing [v2]
In-Reply-To: <cBnZ5uW_qYq1wz-MpG-KtQpSCSDEnQ_6ZyIWLaMN1U8=.ce518d10-5303-43bc-bfe3-eed650e9e5c4@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
 <hnMpW-m99y7EC1j2eHFxpSEOYvdtYYhdVoYeqjEQfUk=.0548c78c-7508-4d1a-990e-f02d8d447bdc@github.com>
 <cBnZ5uW_qYq1wz-MpG-KtQpSCSDEnQ_6ZyIWLaMN1U8=.ce518d10-5303-43bc-bfe3-eed650e9e5c4@github.com>
Message-ID: <aibyVYyRri6XdUfGEMBHCKu09uWDVrn_1IH-6-l_lKw=.ede1695f-547d-45af-a1be-aa9d32dac623@github.com>

On Mon, 24 Mar 2025 11:40:29 GMT, Thomas Schatzl <tschatzl at openjdk.org> wrote:

>> SendaoYan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use "* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true" instead of enable UseCodeCacheFlushing in options
>
> Marked as reviewed by tschatzl (Reviewer).

Thanks for the reviews @tschatzl

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

PR Comment: https://git.openjdk.org/jdk/pull/23721#issuecomment-2768294532

From syan at openjdk.org  Tue Apr  1 06:28:23 2025
From: syan at openjdk.org (SendaoYan)
Date: Tue, 1 Apr 2025 06:28:23 GMT
Subject: Integrated: 8350386: Test TestCodeCacheFull.java fails with option
 -XX:-UseCodeCacheFlushing
In-Reply-To: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
References: <laAqUCgaqW5DnbmI7FhlXEfD6vBqd0BpcPPwBqpmRQA=.3f801860-3de4-48af-b033-6a066888e404@github.com>
Message-ID: <3RE2ipbOjuioN0MUVm8K89AjS-reTBhbBgTt6E8w0G4=.2c136915-aa02-4bbc-899d-ba3198089653@github.com>

On Fri, 21 Feb 2025 03:31:11 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> 
> Test jdk/jfr/event/compiler/TestCodeCacheFull.java fails with option `-XX:-UseCodeCacheFlushing`, because this test is incompatible with `-XX:-UseCodeCacheFlushing` when `-XX:+SegmentedCodeCache` is enable, the detail analyze has been recorded by [JDK-8350386](https://bugs.openjdk.org/browse/JDK-8350386). This PR add `* @requires vm.opt.UseCodeCacheFlushing == null | vm.opt.UseCodeCacheFlushing == true` to make sure `UseCodeCacheFlushing` is not set or set as true.
> 
> Change has been verified locally, test-fix only, no risk.

This pull request has now been integrated.

Changeset: ad48846e
Author:    SendaoYan <syan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ad48846edd894073d89839a2771271553b4e27cd
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8350386: Test TestCodeCacheFull.java fails with option -XX:-UseCodeCacheFlushing

Reviewed-by: tschatzl

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

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

From mgronlun at openjdk.org  Tue Apr  1 09:21:24 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 1 Apr 2025 09:21:24 GMT
Subject: Integrated: 8353226: JFR: emit old object samples must be transitive
 closure complete for segment
In-Reply-To: <s-xrITYe1SlIE7vkI94ZXXuY34fyXmeki2s6doOFIQc=.8671e792-3341-451c-8a6f-fde067291255@github.com>
References: <s-xrITYe1SlIE7vkI94ZXXuY34fyXmeki2s6doOFIQc=.8671e792-3341-451c-8a6f-fde067291255@github.com>
Message-ID: <Sutx5rd0FE9kZUyXm-87_Ty7IzQPSxIu-06yqCLxTlc=.d11dc522-b149-4ba8-9139-144c9f4f8f5b@github.com>

On Sun, 30 Mar 2025 12:08:23 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> EventEmitter::write_events() only serializes blobified stack traces as part of old object checkpoint serialization. Still, it categorically writes a stack trace id as part of the event, even for non-blobified stack traces. As a result, the segment is incomplete. Stack traces must be serialized directly from the leak profiler repository to ensure closure. 
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: f25f7016
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f25f701652900d02858c905f4cd0bb43208c13d5
Stats:     63 lines in 5 files changed: 59 ins; 2 del; 2 mod

8353226: JFR: emit old object samples must be transitive closure complete for segment

Reviewed-by: egahlin

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

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

From egahlin at openjdk.org  Tue Apr  1 16:40:38 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 1 Apr 2025 16:40:38 GMT
Subject: RFR: 8353227: JFR: Prepare tests for strong parser validation [v2]
In-Reply-To: <OEPXthOID27y9KZqgd9zFeF6LGo03TeunZwPf5Roc6A=.3b8f69d7-4941-4554-b30a-b2df7978476e@github.com>
References: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>
 <OEPXthOID27y9KZqgd9zFeF6LGo03TeunZwPf5Roc6A=.3b8f69d7-4941-4554-b30a-b2df7978476e@github.com>
Message-ID: <LjZxof4oyz_fNqEcyKfmO_cZScXklsGJVWK5IzmvGI4=.3d59d14d-858c-4984-88b4-7f2229bb216a@github.com>

On Mon, 31 Mar 2025 14:22:36 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Tests:
>> 
>> - jdk/jfr/jvm/TestDumpOnCrash.java
>> - jdk/jfr/event/runtime/TestShutdownEvent.java
>> 
>> Cannot run with -esa in combination with [JDK-8351698](https://bugs.openjdk.org/browse/JDK-8351698), because parser invariants are not guaranteed for emergency dumps, which are provided on a best-effort basis only.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   include also stream TestJVMCrash.java

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24317#pullrequestreview-2733317311

From mgronlun at openjdk.org  Tue Apr  1 16:40:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 1 Apr 2025 16:40:38 GMT
Subject: Integrated: 8353227: JFR: Prepare tests for strong parser validation
In-Reply-To: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>
References: <1zSx97jayNH2vCa2KAfPPckBZwQ-EaInBQXl7gMVbJM=.cfdb8caa-ccd8-48da-bce7-0fd383af7b53@github.com>
Message-ID: <WgwkX9yX3-q5x-uuvsasuyo-ZaMTY6mSSO6qDXkuHrI=.1c4af8ee-1bc9-4102-ba23-6eb769cc1cfe@github.com>

On Sun, 30 Mar 2025 14:19:31 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Tests:
> 
> - jdk/jfr/jvm/TestDumpOnCrash.java
> - jdk/jfr/event/runtime/TestShutdownEvent.java
> 
> Cannot run with -esa in combination with [JDK-8351698](https://bugs.openjdk.org/browse/JDK-8351698), because parser invariants are not guaranteed for emergency dumps, which are provided on a best-effort basis only.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 19eabaff
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/19eabaff5559b48b1f4da740c0f7c99c64901ea8
Stats:     57 lines in 3 files changed: 57 ins; 0 del; 0 mod

8353227: JFR: Prepare tests for strong parser validation

Reviewed-by: egahlin

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

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

From mgronlun at openjdk.org  Tue Apr  1 20:06:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 1 Apr 2025 20:06:52 GMT
Subject: RFR: 8353431: JFR: Sets to use hashmap instead of binary search as
 backend
Message-ID: <oXfBHqSKwuTiB_GhcpG9xp8F6D9prpTpU8EEGmSaE6Q=.c65a7048-3925-40dc-aef3-d2baf88a54ad@github.com>

Greetings,

This enhancement is a simple set abstraction using a ResizeableResourceHashtable as a backend.

It provides two specializations, JfrCHeapTraceIdSet and JfrResourceAreaTraceIdSet, both tailored for keys of type traceid.

Sorted GrowableArrays used as sets have been replaced. 

Testing: jdk_jfr, stress testing

Thanks
Markus

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

Commit messages:
 - include guard
 - remote iteration
 - reduced table size
 - 8353431

Changes: https://git.openjdk.org/jdk/pull/24366/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24366&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353431
  Stats: 334 lines in 12 files changed: 224 ins; 69 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/24366.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24366/head:pull/24366

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

From egahlin at openjdk.org  Wed Apr  2 11:48:50 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 2 Apr 2025 11:48:50 GMT
Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool
In-Reply-To: <qqyuRJPVBXk5BpVdzvU-mqDnh0sbsSN2XjFwOIC8PkI=.08703bd2-fd6e-48fe-bd47-dcb47867d34b@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
 <Xt2ThwDjnuvu-MAdTEZfRLFhW23XmrpcFBXbRnavz5U=.aa06bc60-b3d1-4e1d-af6b-0b6d81760890@github.com>
 <QcC4SRcjstUTLW7G9NK-eBH8coDLPNJs6nriDxnuuGE=.e301807a-8b92-4e97-a9ae-84ea7907127a@github.com>
 <7KKSaBY0O-xQR0XKyJPiOLpduAfTbUKa5ZLrhNnR3Eg=.8e5318ef-141d-4fc1-8ba8-db212a65301c@github.com>
 <qqyuRJPVBXk5BpVdzvU-mqDnh0sbsSN2XjFwOIC8PkI=.08703bd2-fd6e-48fe-bd47-dcb47867d34b@github.com>
Message-ID: <qHnQLQcU2u2isY4FtTASAWua_UjCbMiVT7EcuzQYLLE=.fd27e966-7842-4218-9c3d-0ec11ac96433@github.com>

On Mon, 31 Mar 2025 11:04:56 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > What is the primary friction you see in --json? The verbose stack traces, too much precision, or the need to specify a command-line flag?
> 
> JSON is too verbose for human consumption. I think this is mostly due to stack traces, but there are also other parts that are relatively noisy. So I cannot easily show the pair of events in a bug report / chat message to show a particular piece of JFR-captured info, without first truncating the output.

The stack trace can be removed with `--stack-depth 0`, but I agree, it's still noisy.

When `jfr` and `jfr print` were conceived, the idea was that the `--json` option could always be used when full precision was needed for verification purposes. Although it may be a bit more cumbersome to read, at least the information would not be lost.

If the use case is to copy detailed human-readable output into a bug report, perhaps there should be a switch that prints numbers and timestamps in full precision. Six digits might not be sufficient for timestamps, and then there are durations as well. I created a prototype that prints durations and timestamps with nanosecond precision, as well as the full value of bytes, bits, and percentages.

https://github.com/openjdk/jdk/pull/24372

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

PR Comment: https://git.openjdk.org/jdk/pull/24029#issuecomment-2772306157

From egahlin at openjdk.org  Wed Apr  2 11:54:04 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 2 Apr 2025 11:54:04 GMT
Subject: RFR: 8353484: JFR: Simplify EventConfiguration
Message-ID: <WFT6N9ZqIOUd2pcdvc9MrNvRUN1Fbd7M-vFwvvY0z-o=.c68bb36a-83e1-4e05-8548-6e19af93db56@github.com>

Could I have a review of the change that removes code that is unnecessary now that the Security Manager is no longer used.



Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24371/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24371&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353484
  Stats: 72 lines in 4 files changed: 2 ins; 46 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/24371.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24371/head:pull/24371

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

From shade at openjdk.org  Wed Apr  2 15:21:54 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 2 Apr 2025 15:21:54 GMT
Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool
In-Reply-To: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
Message-ID: <fc65Pu97E5ztfs923T2j1Gjw7QTfobe19vwOKNVKhsU=.801e363a-47f3-4827-b191-9998b7120f9e@github.com>

On Thu, 13 Mar 2025 10:24:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, JFR tool formats the times with millisecond precision:
> 
> 
> jdk.ThreadSleep {
>   startTime = 10:48:56.668 (2025-03-13)
>   duration = 100 ms
>   time = 100 ms
>   eventThread = "main" (javaThreadId = 3)
>   stackTrace = [...]
> }
> 
> 
> In modern world, a lot can happen within a millisecond. So it would be better to default to microsecond precision. Both timesources supported by JFR (RDTSC and os::elapsed_counter()) have enough enough precision to satisfy microsecond output, so microseconds are meaningful.
> 
> After the patch:
> 
> 
> jdk.ThreadSleep {
>   startTime = 11:23:32.314580 (2025-03-13)
>   duration = 100 ms
>   time = 100 ms
>   eventThread = "main" (javaThreadId = 3)
>   stackTrace = [...]
> }
> 
> 
> I think durations should also be more precise -- for example to compute the endTime precisely from (startTime+duration), but that is a more controversial/style question, so I would like to handle it separately.

> If the use case is to copy detailed human-readable output into a bug report, perhaps there should be a switch that prints numbers and timestamps in full precision. Six digits might not be sufficient for timestamps, and then there are durations as well. I created a prototype that prints durations and timestamps with nanosecond precision, as well as the full value of bytes, bits, and percentages.
> 
> #24372

This works for me! Feel free to take over this RFE, or I can close this one as duplicate of another RFE for `--exact`. Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/24029#issuecomment-2772929997

From mgronlun at openjdk.org  Thu Apr  3 11:01:58 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 3 Apr 2025 11:01:58 GMT
Subject: RFR: 8353484: JFR: Simplify EventConfiguration
In-Reply-To: <WFT6N9ZqIOUd2pcdvc9MrNvRUN1Fbd7M-vFwvvY0z-o=.c68bb36a-83e1-4e05-8548-6e19af93db56@github.com>
References: <WFT6N9ZqIOUd2pcdvc9MrNvRUN1Fbd7M-vFwvvY0z-o=.c68bb36a-83e1-4e05-8548-6e19af93db56@github.com>
Message-ID: <2Jh8scgB_sd3ttQ5HH7iYYkpjOtMWpx3Q9JpxkbB9mI=.36e37421-c468-4880-82ba-16ed640de251@github.com>

On Tue, 1 Apr 2025 23:48:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that removes code that is unnecessary now that the Security Manager is no longer used.
> 
> 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24371#pullrequestreview-2739428677

From egahlin at openjdk.org  Thu Apr  3 11:11:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 3 Apr 2025 11:11:10 GMT
Subject: Integrated: 8353484: JFR: Simplify EventConfiguration
In-Reply-To: <WFT6N9ZqIOUd2pcdvc9MrNvRUN1Fbd7M-vFwvvY0z-o=.c68bb36a-83e1-4e05-8548-6e19af93db56@github.com>
References: <WFT6N9ZqIOUd2pcdvc9MrNvRUN1Fbd7M-vFwvvY0z-o=.c68bb36a-83e1-4e05-8548-6e19af93db56@github.com>
Message-ID: <8vRYPKS2jKJ4fPUEoGmXM88eVF7EJZDiiBtjoLNAKFU=.ef2ef775-c0b9-4ad9-8e11-1ad48fe97b89@github.com>

On Tue, 1 Apr 2025 23:48:16 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a change that removes code that is unnecessary now that the Security Manager is no longer used.
> 
> 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: b263292a
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b263292a75de14b39852c3d2fc73deb3fefabb9a
Stats:     72 lines in 4 files changed: 2 ins; 46 del; 24 mod

8353484: JFR: Simplify EventConfiguration

Reviewed-by: mgronlun

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

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

From shade at openjdk.org  Mon Apr  7 08:47:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Apr 2025 08:47:58 GMT
Subject: RFR: 8351925: JFR: Microsecond time format precision for JFR tool
In-Reply-To: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
Message-ID: <BCbLAufCk8eDZaa4xWeCWSpo9eEKfMYemg199fxwbqI=.907bf7bf-224a-4d47-83fd-0d8d03d0ad87@github.com>

On Thu, 13 Mar 2025 10:24:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, JFR tool formats the times with millisecond precision:
> 
> 
> jdk.ThreadSleep {
>   startTime = 10:48:56.668 (2025-03-13)
>   duration = 100 ms
>   time = 100 ms
>   eventThread = "main" (javaThreadId = 3)
>   stackTrace = [...]
> }
> 
> 
> In modern world, a lot can happen within a millisecond. So it would be better to default to microsecond precision. Both timesources supported by JFR (RDTSC and os::elapsed_counter()) have enough enough precision to satisfy microsecond output, so microseconds are meaningful.
> 
> After the patch:
> 
> 
> jdk.ThreadSleep {
>   startTime = 11:23:32.314580 (2025-03-13)
>   duration = 100 ms
>   time = 100 ms
>   eventThread = "main" (javaThreadId = 3)
>   stackTrace = [...]
> }
> 
> 
> I think durations should also be more precise -- for example to compute the endTime precisely from (startTime+duration), but that is a more controversial/style question, so I would like to handle it separately.

Closed in favor of [JDK-8353614](https://bugs.openjdk.org/browse/JDK-8353614).

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

PR Comment: https://git.openjdk.org/jdk/pull/24029#issuecomment-2782487771

From shade at openjdk.org  Mon Apr  7 08:47:58 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Apr 2025 08:47:58 GMT
Subject: Withdrawn: 8351925: JFR: Microsecond time format precision for JFR
 tool
In-Reply-To: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
References: <vHXRD6FWWgVX_wcRGSC_IZtac1YytGQ6eYaXNvrCjLQ=.6128e074-efd5-4ec6-99fb-5c9e8790fec6@github.com>
Message-ID: <8OG3M-387Io7vIA5IQIK51mXQdD9puAXo82WEFJ0vhI=.f70570ef-be07-4186-b801-c8676bd4b101@github.com>

On Thu, 13 Mar 2025 10:24:08 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Currently, JFR tool formats the times with millisecond precision:
> 
> 
> jdk.ThreadSleep {
>   startTime = 10:48:56.668 (2025-03-13)
>   duration = 100 ms
>   time = 100 ms
>   eventThread = "main" (javaThreadId = 3)
>   stackTrace = [...]
> }
> 
> 
> In modern world, a lot can happen within a millisecond. So it would be better to default to microsecond precision. Both timesources supported by JFR (RDTSC and os::elapsed_counter()) have enough enough precision to satisfy microsecond output, so microseconds are meaningful.
> 
> After the patch:
> 
> 
> jdk.ThreadSleep {
>   startTime = 11:23:32.314580 (2025-03-13)
>   duration = 100 ms
>   time = 100 ms
>   eventThread = "main" (javaThreadId = 3)
>   stackTrace = [...]
> }
> 
> 
> I think durations should also be more precise -- for example to compute the endTime precisely from (startTime+duration), but that is a more controversial/style question, so I would like to handle it separately.

This pull request has been closed without being integrated.

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

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

From mgronlun at openjdk.org  Mon Apr  7 09:02:05 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 7 Apr 2025 09:02:05 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v3]
In-Reply-To: <LJwcoksfWjpZ74bA0juZMkhC4gZxToXp8ppAob6YpuE=.e38e120a-9d59-4f01-aa7e-5cb104c436d0@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <LJwcoksfWjpZ74bA0juZMkhC4gZxToXp8ppAob6YpuE=.e38e120a-9d59-4f01-aa7e-5cb104c436d0@github.com>
Message-ID: <I3YalSxffflRVdcYg53JMXOcGvqCBeWjm4xsmmOpf8c=.76c2484f-3217-471c-aef4-980f2f9a7b67@github.com>

On Fri, 28 Mar 2025 21:24:15 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - align params
>  - adjustments

Friendly reminder/heads-up to platform and port maintainers:

Please review the necessary platform changes in advance so that your port will be ready once this integration is complete. Alternatively, you can send me your change sets for them to be incorporated into this PR.

Thanks
Markus

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

PR Comment: https://git.openjdk.org/jdk/pull/24296#issuecomment-2782524969

From shade at openjdk.org  Mon Apr  7 10:12:49 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 7 Apr 2025 10:12:49 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v3]
In-Reply-To: <B6rSckDzEk7ZqJxFp-RwScurGZN-XbCy0inEHXomHMI=.028a6f99-3905-4888-9821-d9f848db2686@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <B6rSckDzEk7ZqJxFp-RwScurGZN-XbCy0inEHXomHMI=.028a6f99-3905-4888-9821-d9f848db2686@github.com>
Message-ID: <QtlCefxkP4wXgRxZfVaylWJDEuPz718g5h3V2Vj-uB4=.064b34fd-1730-4b09-bf33-287d8754996e@github.com>

On Fri, 28 Mar 2025 20:09:37 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - align params
>>  - adjustments
>
> src/hotspot/cpu/x86/interp_masm_x86.cpp line 1045:
> 
>> 1043:   Label slow_path;
>> 1044:   Label fast_path;
>> 1045:   safepoint_poll(slow_path, rthread, current_fp, true /* at_return */, false /* in_nmethod */);
> 
> A little heads-up: I am going to propose a little cleanup soon to drop `rthread` from x86 safepoint_pool (we can trust it is `r15_thread` always). That would probably yield a minor merge conflict here.

FYI, it would be here: https://github.com/openjdk/jdk/pull/24323

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2030922573

From mgronlun at openjdk.org  Mon Apr  7 10:53:32 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 7 Apr 2025 10:53:32 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v4]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <bqk02feSnWOjq6uXOZtg4DpffZmK8A1eiE9yZaDN7aM=.e70706e0-fa5d-4fa4-a55e-1e1aba8eaa71@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:

 - Merge branch 'master' into 8352251
 - align params
 - adjustments
 - refactoring
 - 8352251

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=03
  Stats: 3203 lines in 77 files changed: 1897 ins; 949 del; 357 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

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

From egahlin at openjdk.org  Tue Apr  8 18:20:16 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 8 Apr 2025 18:20:16 GMT
Subject: RFR: 8353431: JFR: Sets to use hashmap instead of binary search as
 backend
In-Reply-To: <oXfBHqSKwuTiB_GhcpG9xp8F6D9prpTpU8EEGmSaE6Q=.c65a7048-3925-40dc-aef3-d2baf88a54ad@github.com>
References: <oXfBHqSKwuTiB_GhcpG9xp8F6D9prpTpU8EEGmSaE6Q=.c65a7048-3925-40dc-aef3-d2baf88a54ad@github.com>
Message-ID: <hi-KkUULvx-Z1mEAhMQlaLIlOqFnejRZwwAZAzWpd00=.c06fdb8b-aefc-4203-8f63-112333298ac4@github.com>

On Tue, 1 Apr 2025 20:01:10 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This enhancement is a simple set abstraction using a ResizeableResourceHashtable as a backend.
> 
> It provides two specializations, JfrCHeapTraceIdSet and JfrResourceAreaTraceIdSet, both tailored for keys of type traceid.
> 
> Sorted GrowableArrays used as sets have been replaced. 
> 
> Testing: jdk_jfr, stress testing
> 
> Thanks
> Markus

Nice cleanup!

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

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24366#pullrequestreview-2751008960

From mgronlun at openjdk.org  Tue Apr  8 18:44:24 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 8 Apr 2025 18:44:24 GMT
Subject: Integrated: 8353431: JFR: Sets to use hashmap instead of binary search
 as backend
In-Reply-To: <oXfBHqSKwuTiB_GhcpG9xp8F6D9prpTpU8EEGmSaE6Q=.c65a7048-3925-40dc-aef3-d2baf88a54ad@github.com>
References: <oXfBHqSKwuTiB_GhcpG9xp8F6D9prpTpU8EEGmSaE6Q=.c65a7048-3925-40dc-aef3-d2baf88a54ad@github.com>
Message-ID: <8wKN3j1TcP5SnAo86CvidO_FRKhRKMuiygGr9xyI6DU=.d2818a07-e381-4d57-a2d3-2c06aa86c28f@github.com>

On Tue, 1 Apr 2025 20:01:10 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This enhancement is a simple set abstraction using a ResizeableResourceHashtable as a backend.
> 
> It provides two specializations, JfrCHeapTraceIdSet and JfrResourceAreaTraceIdSet, both tailored for keys of type traceid.
> 
> Sorted GrowableArrays used as sets have been replaced. 
> 
> Testing: jdk_jfr, stress testing
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 257f817c
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/257f817c7fca1e8cdb0fec0e18ab9c07b19b1d13
Stats:     334 lines in 12 files changed: 224 ins; 69 del; 41 mod

8353431: JFR: Sets to use hashmap instead of binary search as backend

Reviewed-by: egahlin

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

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

From egahlin at openjdk.org  Tue Apr  8 20:00:31 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 8 Apr 2025 20:00:31 GMT
Subject: RFR: 8353856: Deprecate FlighRecorderPermission class for removal
Message-ID: <rRgqbd-EmOgiuo1hxopiUKLsagJjROA2thNpoICdjRI=.4fc9b738-0343-4f6c-b633-5b6e26a9edb4@github.com>

Hi,

Can I have a review of a PR that deprecates the FlightRecorderPermission class for removal? The code that used to access package-internal methods of jdk.jfr is moved to the EventSettings class.

Testing: tier1 + jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24524/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24524&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353856
  Stats: 240 lines in 3 files changed: 116 ins; 120 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/24524.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24524/head:pull/24524

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

From mgronlun at openjdk.org  Wed Apr  9 10:22:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 9 Apr 2025 10:22:34 GMT
Subject: RFR: 8353856: Deprecate FlighRecorderPermission class for removal
In-Reply-To: <rRgqbd-EmOgiuo1hxopiUKLsagJjROA2thNpoICdjRI=.4fc9b738-0343-4f6c-b633-5b6e26a9edb4@github.com>
References: <rRgqbd-EmOgiuo1hxopiUKLsagJjROA2thNpoICdjRI=.4fc9b738-0343-4f6c-b633-5b6e26a9edb4@github.com>
Message-ID: <nXgr6mnG4q9-Jn_Nc06m_FnFqRDl1MAQL39bcEC9Ick=.b47ed6f5-45dc-4a4f-a3fe-de98a12c7c86@github.com>

On Tue, 8 Apr 2025 19:49:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Can I have a review of a PR that deprecates the FlightRecorderPermission class for removal? The code that used to access package-internal methods of jdk.jfr is moved to the EventSettings class.
> 
> Testing: tier1 + jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24524#pullrequestreview-2752969460

From egahlin at openjdk.org  Thu Apr 10 07:45:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 10 Apr 2025 07:45:37 GMT
Subject: Integrated: 8353856: Deprecate FlighRecorderPermission class for
 removal
In-Reply-To: <rRgqbd-EmOgiuo1hxopiUKLsagJjROA2thNpoICdjRI=.4fc9b738-0343-4f6c-b633-5b6e26a9edb4@github.com>
References: <rRgqbd-EmOgiuo1hxopiUKLsagJjROA2thNpoICdjRI=.4fc9b738-0343-4f6c-b633-5b6e26a9edb4@github.com>
Message-ID: <f1bOjNKWfiVimdR-YCvTsqycOZ_8ggwRt1lZ1mJ_BiU=.4c8f7dc1-c371-40c9-b4a4-f8ecbd3fcd6e@github.com>

On Tue, 8 Apr 2025 19:49:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Hi,
> 
> Can I have a review of a PR that deprecates the FlightRecorderPermission class for removal? The code that used to access package-internal methods of jdk.jfr is moved to the EventSettings class.
> 
> Testing: tier1 + jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: c447a102
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c447a10225576bc59e1ba9477417367d2ac28511
Stats:     240 lines in 3 files changed: 116 ins; 120 del; 4 mod

8353856: Deprecate FlighRecorderPermission class for removal

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Thu Apr 10 12:54:03 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 10 Apr 2025 12:54:03 GMT
Subject: RFR: 8353614: JFR: jfr print --exact
Message-ID: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>

Could I have a review of an enhancement that adds a command-line switch to `jfr print`, allowing timestamps, time spans, percentages, and byte values to be printed with full precision?

Testing: tier1 + jdk/jdk/jfr

Thank
Erik

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

Commit messages:
 - Fix help
 - Improve help
 - Fix formatting
 - Test update, bug fixes and man page
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24372/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24372&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8353614
  Stats: 185 lines in 4 files changed: 151 ins; 14 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/24372.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24372/head:pull/24372

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

From mgronlun at openjdk.org  Thu Apr 10 12:54:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 10 Apr 2025 12:54:03 GMT
Subject: RFR: 8353614: JFR: jfr print --exact
In-Reply-To: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>
References: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>
Message-ID: <hY_T01v2pHZeGcxZjiCfGi6Q1s7aO5fXB-uVa2g0mxw=.b7b8f649-0116-4d45-b5f7-9bf8f35f4803@github.com>

On Wed, 2 Apr 2025 02:20:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of an enhancement that adds a command-line switch to `jfr print`, allowing timestamps, time spans, percentages, and byte values to be printed with full precision?
> 
> Testing: tier1 + jdk/jdk/jfr
> 
> Thank
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/tool/Print.java line 76:

> 74:         stream.println("  --json                  Print recording in JSON format");
> 75:         stream.println();
> 76:         stream.println("  --exact                 Pretty print numbers and timestamps in full precision.");

"with full precision."

src/jdk.jfr/share/man/jfr.md line 124:

> 122: 
> 123: <a id="print-option-exact">`--exact`</a>
> 124: : Pretty print numbers and timestamps in full precision.

"with full precision."

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24372#discussion_r2037069372
PR Review Comment: https://git.openjdk.org/jdk/pull/24372#discussion_r2037069969

From egahlin at openjdk.org  Thu Apr 10 12:59:12 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 10 Apr 2025 12:59:12 GMT
Subject: RFR: 8353614: JFR: jfr print --exact [v2]
In-Reply-To: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>
References: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>
Message-ID: <JW-rGgHxZ4ON7lRNns8kdtAsLBm5oathNzK2v3bz07I=.853e6413-ed01-484e-ad03-c6bcd2caf135@github.com>

> Could I have a review of an enhancement that adds a command-line switch to `jfr print`, allowing timestamps, time spans, percentages, and byte values to be printed with full precision?
> 
> Testing: tier1 + jdk/jdk/jfr
> 
> Thank
> Erik

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

  Update syntax

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24372/files
  - new: https://git.openjdk.org/jdk/pull/24372/files/358d3273..728409f0

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

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

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

From mgronlun at openjdk.org  Thu Apr 10 13:31:31 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 10 Apr 2025 13:31:31 GMT
Subject: RFR: 8353614: JFR: jfr print --exact [v2]
In-Reply-To: <JW-rGgHxZ4ON7lRNns8kdtAsLBm5oathNzK2v3bz07I=.853e6413-ed01-484e-ad03-c6bcd2caf135@github.com>
References: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>
 <JW-rGgHxZ4ON7lRNns8kdtAsLBm5oathNzK2v3bz07I=.853e6413-ed01-484e-ad03-c6bcd2caf135@github.com>
Message-ID: <ipXwPIElC4S-nE28v1Yd-YrIkztlYDkrJtu9JK-sDQ0=.d876335e-e106-4adb-a341-831d3ef2160d@github.com>

On Thu, 10 Apr 2025 12:59:12 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of an enhancement that adds a command-line switch to `jfr print`, allowing timestamps, time spans, percentages, and byte values to be printed with full precision?
>> 
>> Testing: tier1 + jdk/jdk/jfr
>> 
>> Thank
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update syntax

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24372#pullrequestreview-2756803000

From jsikstro at openjdk.org  Thu Apr 10 15:48:55 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 10 Apr 2025 15:48:55 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation
Message-ID: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>

Hello,

This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441).

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

Commit messages:
 - 8354310: JFR: Inconsistent metadata in ZPageAllocation

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

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

From egahlin at openjdk.org  Thu Apr 10 15:52:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 10 Apr 2025 15:52:37 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation
In-Reply-To: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
References: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
Message-ID: <XnDlOcTlKue99kYBebTgqw3bBFKkfLJzh0mtUN-kcrY=.08cc11ae-91a8-4c07-a206-e241146b86d7@github.com>

On Thu, 10 Apr 2025 15:43:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441).

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24578#pullrequestreview-2757353162

From eosterlund at openjdk.org  Thu Apr 10 16:09:31 2025
From: eosterlund at openjdk.org (Erik =?UTF-8?B?w5ZzdGVybHVuZA==?=)
Date: Thu, 10 Apr 2025 16:09:31 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation
In-Reply-To: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
References: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
Message-ID: <vAxQOqZEi4q6OBRPPBivxV0KP5b6_ywQHqxMvHrfDhY=.16012ba1-08f5-44b6-823b-a0fd5c5e71df@github.com>

On Thu, 10 Apr 2025 15:43:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441).

Marked as reviewed by eosterlund (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24578#pullrequestreview-2757411727

From stefank at openjdk.org  Thu Apr 10 16:23:27 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 10 Apr 2025 16:23:27 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation
In-Reply-To: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
References: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
Message-ID: <SPghrJ_8X9SqHwiaEK612BK2ejhGtGItEzcZcfL1Qfc=.3c25bb62-ec59-4eb0-93c2-1aba85af6c82@github.com>

On Thu, 10 Apr 2025 15:43:15 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

> Hello,
> 
> This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441).

src/hotspot/share/jfr/metadata/metadata.xml line 1162:

> 1160:     <Field type="ulong" contentType="bytes" name="harvested" label="Harvested" />
> 1161:     <Field type="ulong" contentType="bytes" name="committed" label="Committed" />
> 1162:     <Field type="uint" name="harvestedRanges" label="Harvested Ranges" description="Number of ranges memory is harvested from" />

Maybe "Number of harvested memory ranges"?

src/hotspot/share/jfr/metadata/metadata.xml line 1165:

> 1163:     <Field type="boolean" name="multiPartition" label="Multi-Partition Allocation" />
> 1164:     <Field type="boolean" name="successful" label="Successful Allocation" />
> 1165:     <Field type="boolean" name="nonBlocking" label="Non-Blocking" />

I wonder if "Allocation" is redundant here. If not then maybe it should also say Non-Blocking Allocation.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24578#discussion_r2037796280
PR Review Comment: https://git.openjdk.org/jdk/pull/24578#discussion_r2037797534

From jsikstro at openjdk.org  Thu Apr 10 19:04:45 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 10 Apr 2025 19:04:45 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation [v2]
In-Reply-To: <SPghrJ_8X9SqHwiaEK612BK2ejhGtGItEzcZcfL1Qfc=.3c25bb62-ec59-4eb0-93c2-1aba85af6c82@github.com>
References: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
 <SPghrJ_8X9SqHwiaEK612BK2ejhGtGItEzcZcfL1Qfc=.3c25bb62-ec59-4eb0-93c2-1aba85af6c82@github.com>
Message-ID: <pqpPZlyI3PlFmHX5_G_86Di5GauyNdT4RJqev2rOI00=.e053a7e9-1e48-4e8d-b48d-138b6ce5ea5b@github.com>

On Thu, 10 Apr 2025 16:20:28 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   stefank feedback
>
> src/hotspot/share/jfr/metadata/metadata.xml line 1165:
> 
>> 1163:     <Field type="boolean" name="multiPartition" label="Multi-Partition Allocation" />
>> 1164:     <Field type="boolean" name="successful" label="Successful Allocation" />
>> 1165:     <Field type="boolean" name="nonBlocking" label="Non-Blocking" />
> 
> I wonder if "Allocation" is redundant here. If not then maybe it should also say Non-Blocking Allocation.

I agree and feel like it's redundant. I'll remove "Allocation" from the labels of multiPartition and successful.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24578#discussion_r2038100347

From jsikstro at openjdk.org  Thu Apr 10 19:04:44 2025
From: jsikstro at openjdk.org (Joel =?UTF-8?B?U2lrc3Ryw7Zt?=)
Date: Thu, 10 Apr 2025 19:04:44 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation [v2]
In-Reply-To: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
References: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
Message-ID: <Gry_JtozOL2VeS6Wu1GtxooBMmtKaJfNHqj-_4d-Ti4=.b3cf9a9e-41f1-4413-8e77-32406d745ca8@github.com>

> Hello,
> 
> This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441).

Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:

  stefank feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24578/files
  - new: https://git.openjdk.org/jdk/pull/24578/files/a99cb2ef..ae724496

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

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

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

From stefank at openjdk.org  Thu Apr 10 21:08:31 2025
From: stefank at openjdk.org (Stefan Karlsson)
Date: Thu, 10 Apr 2025 21:08:31 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation [v2]
In-Reply-To: <Gry_JtozOL2VeS6Wu1GtxooBMmtKaJfNHqj-_4d-Ti4=.b3cf9a9e-41f1-4413-8e77-32406d745ca8@github.com>
References: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
 <Gry_JtozOL2VeS6Wu1GtxooBMmtKaJfNHqj-_4d-Ti4=.b3cf9a9e-41f1-4413-8e77-32406d745ca8@github.com>
Message-ID: <kSuhJTrJduufaizjvdr8_TrX0qkpqR2EIRfkcnNjFHc=.044cd8ad-9064-4bcb-92fa-a7de662b7f83@github.com>

On Thu, 10 Apr 2025 19:04:44 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441).
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stefank feedback

Marked as reviewed by stefank (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24578#pullrequestreview-2758419968

From egahlin at openjdk.org  Fri Apr 11 12:19:31 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Apr 2025 12:19:31 GMT
Subject: RFR: 8354310: JFR: Inconsistent metadata in ZPageAllocation [v2]
In-Reply-To: <Gry_JtozOL2VeS6Wu1GtxooBMmtKaJfNHqj-_4d-Ti4=.b3cf9a9e-41f1-4413-8e77-32406d745ca8@github.com>
References: <4R95HPSuwd43tzLL6ozxzbvCa0x_f26kkznGymJdtzI=.51a3fbcb-d56c-4f29-919d-8e076525f6aa@github.com>
 <Gry_JtozOL2VeS6Wu1GtxooBMmtKaJfNHqj-_4d-Ti4=.b3cf9a9e-41f1-4413-8e77-32406d745ca8@github.com>
Message-ID: <nTRqdacUuGwLVBUBQWVHlOI8Sx6HeoX06C1knFXhzdc=.1e7386f1-eec9-4b9e-8c84-905435359ca0@github.com>

On Thu, 10 Apr 2025 19:04:44 GMT, Joel Sikstr?m <jsikstro at openjdk.org> wrote:

>> Hello,
>> 
>> This PR fixes JFR metadata for ZPageAllocation after [JDK-8350441](https://bugs.openjdk.org/browse/JDK-8350441).
>
> Joel Sikstr?m has updated the pull request incrementally with one additional commit since the last revision:
> 
>   stefank feedback

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24578#pullrequestreview-2760178703

From egahlin at openjdk.org  Fri Apr 11 15:15:32 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 11 Apr 2025 15:15:32 GMT
Subject: Integrated: 8353614: JFR: jfr print --exact
In-Reply-To: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>
References: <I4megeXov575UszXbrMXKtfbLIMY4wtoJXvYU4kIqrc=.d60a9673-d080-491d-93f3-a35c394ed4c0@github.com>
Message-ID: <A6thn14zBVcucErFMkAg0bN483R2_ZymMcJp87BDFNA=.8dc7b7e3-b943-4431-8041-323705bd37dd@github.com>

On Wed, 2 Apr 2025 02:20:06 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of an enhancement that adds a command-line switch to `jfr print`, allowing timestamps, time spans, percentages, and byte values to be printed with full precision?
> 
> Testing: tier1 + jdk/jdk/jfr
> 
> Thank
> Erik

This pull request has now been integrated.

Changeset: 1d7138fe
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d7138fe021d64686ac59cddd1bc7c787c610aa9
Stats:     185 lines in 4 files changed: 151 ins; 14 del; 20 mod

8353614: JFR: jfr print --exact

Reviewed-by: mgronlun

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

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

From shade at openjdk.org  Mon Apr 14 13:15:09 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 14 Apr 2025 13:15:09 GMT
Subject: RFR: 8354508: JFR: Strengthen metadata checks for labels
In-Reply-To: <iKGG0DKfNt3fBWB2vuFxEuQXGCctRo2BbiK4poZj7tw=.88b3dcac-59ee-4718-83ce-12974d02f593@github.com>
References: <iKGG0DKfNt3fBWB2vuFxEuQXGCctRo2BbiK4poZj7tw=.88b3dcac-59ee-4718-83ce-12974d02f593@github.com>
Message-ID: <9I3c5tzTOuHtvMezEgRMn1NFBWrnQmh29IoIliX9EiU=.a0f0e8d0-c50b-4b03-9e4a-3328f0880fa4@github.com>

On Mon, 14 Apr 2025 08:02:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that improves the checks for label metadata? When running TestEventMetadata, I found some fields with incorrect capitalization. I fixed those, as well as some typos, and updated the filename from trace.xml to metadata.xml.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Makes sense. Only stylistic nits:

Looks reasonable to me, thanks.

test/jdk/jdk/jfr/event/metadata/TestEventMetadata.java line 168:

> 166:         Asserts.assertNotEquals(label, null, "Label not allowed to be null");
> 167:         Asserts.assertTrue(label.length() > 1, "Label must be at least two characters");
> 168:         Asserts.assertTrue(label.length() < 45, "Label should not exceed 45 characters, use description to explain");

Message suggests the condition should be `<= 45`?

test/jdk/jdk/jfr/event/metadata/TestEventMetadata.java line 177:

> 175:         Asserts.assertTrue(isCapitalized(firstWord), "Label should capitalize first word");
> 176:         if (!isNumeric(lastWord)) {
> 177:             Asserts.assertTrue(isCapitalized(lastWord), "Label should capitalize last word");

This looks like a heuristic that last word is very likely a noun, and should be capitalized then? Just curious.

test/jdk/jdk/jfr/event/metadata/TestEventMetadata.java line 181:

> 179:         for (String word : words) {
> 180:             Asserts.assertFalse(word.endsWith("-") || word.startsWith("-"), "Word in label should not start or end with hyphen");
> 181:             Asserts.assertTrue(word.length() != 0, "Label should not contain superflous whitespace");

"superfluous"?

test/jdk/jdk/jfr/event/metadata/TestEventMetadata.java line 194:

> 192:         }
> 193:         for (char c : label.toCharArray()) {
> 194:             Asserts.assertTrue(isAllowedCharacter(c), "Label should only consist of letters, numbers, hyphens, parantheses or whitespace, found '" + c + "'");

"parentheses"?

test/jdk/jdk/jfr/event/metadata/TestEventMetadata.java line 212:

> 210: 
> 211:     private static boolean isShortCommonPreposition(String word) {
> 212:         String[] prepositions = { "in", "on", "at", "by", "to", "of"};

Suggestion:

        String[] prepositions = { "in", "on", "at", "by", "to", "of" };

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

PR Review: https://git.openjdk.org/jdk/pull/24616#pullrequestreview-2763542035
Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24616#pullrequestreview-2764010341
PR Review Comment: https://git.openjdk.org/jdk/pull/24616#discussion_r2041660467
PR Review Comment: https://git.openjdk.org/jdk/pull/24616#discussion_r2041676636
PR Review Comment: https://git.openjdk.org/jdk/pull/24616#discussion_r2041679340
PR Review Comment: https://git.openjdk.org/jdk/pull/24616#discussion_r2041679801
PR Review Comment: https://git.openjdk.org/jdk/pull/24616#discussion_r2041680301

From egahlin at openjdk.org  Mon Apr 14 13:14:58 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 14 Apr 2025 13:14:58 GMT
Subject: RFR: 8354508: JFR: Strengthen metadata checks for labels
Message-ID: <iKGG0DKfNt3fBWB2vuFxEuQXGCctRo2BbiK4poZj7tw=.88b3dcac-59ee-4718-83ce-12974d02f593@github.com>

Could I have a review of a PR that improves the checks for label metadata? When running TestEventMetadata, I found some fields with incorrect capitalization. I fixed those, as well as some typos, and updated the filename from trace.xml to metadata.xml.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Fixes
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24616/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24616&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354508
  Stats: 77 lines in 2 files changed: 46 ins; 5 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/24616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24616/head:pull/24616

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

From egahlin at openjdk.org  Mon Apr 14 13:15:11 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 14 Apr 2025 13:15:11 GMT
Subject: RFR: 8354508: JFR: Strengthen metadata checks for labels
In-Reply-To: <9I3c5tzTOuHtvMezEgRMn1NFBWrnQmh29IoIliX9EiU=.a0f0e8d0-c50b-4b03-9e4a-3328f0880fa4@github.com>
References: <iKGG0DKfNt3fBWB2vuFxEuQXGCctRo2BbiK4poZj7tw=.88b3dcac-59ee-4718-83ce-12974d02f593@github.com>
 <9I3c5tzTOuHtvMezEgRMn1NFBWrnQmh29IoIliX9EiU=.a0f0e8d0-c50b-4b03-9e4a-3328f0880fa4@github.com>
Message-ID: <FY3Rwd9mFrz9BwOqOOU4lkc5TRjlfh9Yn9ikU3BKbK4=.5d4a215e-0463-402c-b8e0-74d2525e85a8@github.com>

On Mon, 14 Apr 2025 08:37:32 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Could I have a review of a PR that improves the checks for label metadata? When running TestEventMetadata, I found some fields with incorrect capitalization. I fixed those, as well as some typos, and updated the filename from trace.xml to metadata.xml.
>> 
>> Testing: jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> test/jdk/jdk/jfr/event/metadata/TestEventMetadata.java line 177:
> 
>> 175:         Asserts.assertTrue(isCapitalized(firstWord), "Label should capitalize first word");
>> 176:         if (!isNumeric(lastWord)) {
>> 177:             Asserts.assertTrue(isCapitalized(lastWord), "Label should capitalize last word");
> 
> This looks like a heuristic that last word is very likely a noun, and should be capitalized then? Just curious.

The last word should always be capitalized, but Character.isUpperCase in isCapitalized() returns false for numbers. As a result, a label like "GC Phase Level 1" fails. The isNumeric check avoids that. I will add a comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24616#discussion_r2041732863

From duke at openjdk.org  Tue Apr 15 05:23:15 2025
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Tue, 15 Apr 2025 05:23:15 GMT
Subject: RFR: 8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails with
 32-bit build
Message-ID: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>

Hi All,
I would like to add this bug fix for the bug in jdk/jfr/startupargs/TestMemoryOptions.java. 
I was unable to reproduce the reported problem in java versions 11 and later. Therefore, I made a pull request for 8u before.
https://github.com/openjdk/jdk8u-dev/pull/641
However, the latest java should be fixed, as the bugs described below will potentially remain in the test.

This test contains 24 test cases and fails the "ThreadBufferSizeExceedMemorySize" case.
The cause of this bug is the memory allocation issue, which occurs only on 32-bit Server VM, not on Client VM or 64-bit JDK. The failure happens because Server VM's default heap size reduces available memory space, causing JFR to fail memory allocation.
To resolve this issue, -Xmx256M is explicitly set, matching the Client VM default heap size, ensuring sufficient memory space remains available for JFR.
I believe that this test verifies that the combination of memory options for JFR is valid or invalid and that the MaxHeapSize setting does not affect the verification.
Change has been verified locally, test-fix only, no risk.

Would someone please review this fix?

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

Commit messages:
 - 8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails with 32-bit build

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

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

From egahlin at openjdk.org  Tue Apr 15 09:50:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Apr 2025 09:50:45 GMT
Subject: Integrated: 8354508: JFR: Strengthen metadata checks for labels
In-Reply-To: <iKGG0DKfNt3fBWB2vuFxEuQXGCctRo2BbiK4poZj7tw=.88b3dcac-59ee-4718-83ce-12974d02f593@github.com>
References: <iKGG0DKfNt3fBWB2vuFxEuQXGCctRo2BbiK4poZj7tw=.88b3dcac-59ee-4718-83ce-12974d02f593@github.com>
Message-ID: <nXh-ysHX8ldDt5WvlATNzWDuA2HxmIcyLq-A31M4--c=.26c18885-0579-479b-ac30-89768df65319@github.com>

On Mon, 14 Apr 2025 08:02:34 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that improves the checks for label metadata? When running TestEventMetadata, I found some fields with incorrect capitalization. I fixed those, as well as some typos, and updated the filename from trace.xml to metadata.xml.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: d7676c39
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d7676c39b648bd55f72a50494432b02862a4e111
Stats:     77 lines in 2 files changed: 46 ins; 5 del; 26 mod

8354508: JFR: Strengthen metadata checks for labels

Reviewed-by: shade

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

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

From phh at openjdk.org  Tue Apr 15 14:51:55 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Tue, 15 Apr 2025 14:51:55 GMT
Subject: RFR: 8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails
 with 32-bit build
In-Reply-To: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
References: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
Message-ID: <aVBoLNtwDdXZ_biqDlY8cRKwbb6F1Pm4s_to4XkAyog=.bd9ce870-1a43-4873-9528-1e6e94afd60a@github.com>

On Tue, 15 Apr 2025 05:18:34 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Hi All,
> I would like to add this bug fix for the bug in jdk/jfr/startupargs/TestMemoryOptions.java. 
> I was unable to reproduce the reported problem in java versions 11 and later. Therefore, I made a pull request for 8u before.
> https://github.com/openjdk/jdk8u-dev/pull/641
> However, the latest java should be fixed, as the bugs described below will potentially remain in the test.
> 
> This test contains 24 test cases and fails the "ThreadBufferSizeExceedMemorySize" case.
> The cause of this bug is the memory allocation issue, which occurs only on 32-bit Server VM, not on Client VM or 64-bit JDK. The failure happens because Server VM's default heap size reduces available memory space, causing JFR to fail memory allocation.
> To resolve this issue, -Xmx256M is explicitly set, matching the Client VM default heap size, ensuring sufficient memory space remains available for JFR.
> I believe that this test verifies that the combination of memory options for JFR is valid or invalid and that the MaxHeapSize setting does not affect the verification.
> Change has been verified locally, test-fix only, no risk.
> 
> Would someone please review this fix?

Looks fine to me.

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

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24646#pullrequestreview-2768729273

From mark.reinhold at oracle.com  Tue Apr 15 20:34:40 2025
From: mark.reinhold at oracle.com (Mark Reinhold)
Date: Tue, 15 Apr 2025 20:34:40 +0000
Subject: New candidate JEP: 509: JFR CPU-Time Profiling (Experimental)
Message-ID: <20250415203439.A65C5811ACD@eggemoggin.niobe.net>

https://openjdk.org/jeps/509

  Summary: Enhance the JDK Flight Recorder (JFR) to capture CPU-time
  profiling information on Linux.  This is an experimental feature.

- Mark

From egahlin at openjdk.org  Tue Apr 15 22:47:16 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 15 Apr 2025 22:47:16 GMT
Subject: RFR: 8295651: JFR: 'jfr scrub' should summarize what was removed
Message-ID: <1dkgMuhG6B_rSxCqqP_H8-ocdCLF_OFz69SOCgUe0Ks=.508d0ab5-8262-433f-9790-9f10b4ee5aa1@github.com>

Could I have a review of an enhancement that summarizes the results of `jfr scrub`?

To accommodate this feature, I made some additional changes:

- Added a LongMap::values() method.
- Added a Command::printf(...) method, which is now also used by `jfr summary`.
- Improved TestScrub.java so it now creates a file that spans multiple chunks, including an empty one.

See issue for example output.

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Only collect if 'jfr scrub' is used
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24669/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24669&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8295651
  Stats: 138 lines in 9 files changed: 123 ins; 2 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/24669.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24669/head:pull/24669

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

From duke at openjdk.org  Wed Apr 16 04:10:44 2025
From: duke at openjdk.org (duke)
Date: Wed, 16 Apr 2025 04:10:44 GMT
Subject: RFR: 8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails
 with 32-bit build
In-Reply-To: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
References: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
Message-ID: <BoeAi_kj9T46akpZXZi4D1jHbBWLnEWi3zds_IrigoE=.636d3683-faba-43e8-ab96-6a5a899c8fff@github.com>

On Tue, 15 Apr 2025 05:18:34 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Hi All,
> I would like to add this bug fix for the bug in jdk/jfr/startupargs/TestMemoryOptions.java. 
> I was unable to reproduce the reported problem in java versions 11 and later. Therefore, I made a pull request for 8u before.
> https://github.com/openjdk/jdk8u-dev/pull/641
> However, the latest java should be fixed, as the bugs described below will potentially remain in the test.
> 
> This test contains 24 test cases and fails the "ThreadBufferSizeExceedMemorySize" case.
> The cause of this bug is the memory allocation issue, which occurs only on 32-bit Server VM, not on Client VM or 64-bit JDK. The failure happens because Server VM's default heap size reduces available memory space, causing JFR to fail memory allocation.
> To resolve this issue, -Xmx256M is explicitly set, matching the Client VM default heap size, ensuring sufficient memory space remains available for JFR.
> I believe that this test verifies that the combination of memory options for JFR is valid or invalid and that the MaxHeapSize setting does not affect the verification.
> Change has been verified locally, test-fix only, no risk.
> 
> Would someone please review this fix?

@tkiriyama 
Your change (at version 31676205a27b50dfe55289ad15344d88d2b06a78) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/24646#issuecomment-2808180466

From mgronlun at openjdk.org  Wed Apr 16 12:18:54 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 16 Apr 2025 12:18:54 GMT
Subject: RFR: 8295651: JFR: 'jfr scrub' should summarize what was removed
In-Reply-To: <1dkgMuhG6B_rSxCqqP_H8-ocdCLF_OFz69SOCgUe0Ks=.508d0ab5-8262-433f-9790-9f10b4ee5aa1@github.com>
References: <1dkgMuhG6B_rSxCqqP_H8-ocdCLF_OFz69SOCgUe0Ks=.508d0ab5-8262-433f-9790-9f10b4ee5aa1@github.com>
Message-ID: <SpmDxUCsHqc3vBpt0t3lQH_xzOAjN9KgzGyvwUXEJHA=.0faf213f-37a6-4854-94b5-af43989df4da@github.com>

On Tue, 15 Apr 2025 22:22:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of an enhancement that summarizes the results of `jfr scrub`?
> 
> To accommodate this feature, I made some additional changes:
> 
> - Added a LongMap::values() method.
> - Added a Command::printf(...) method, which is now also used by `jfr summary`.
> - Improved TestScrub.java so it now creates a file that spans multiple chunks, including an empty one.
> 
> To make it easier to locate the scrubbed file, I also changed so the real path instead of the of the absolute path is displayed in the summary 
> 
> See issue for example output.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Brilliant change. Thank you for doing it.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24669#pullrequestreview-2772299050

From phh at openjdk.org  Wed Apr 16 15:44:57 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 16 Apr 2025 15:44:57 GMT
Subject: RFR: 8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails
 with 32-bit build
In-Reply-To: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
References: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
Message-ID: <dS5DZAa0ubvnYjeIwyIVHQxmG-i3KC1eNlsqL3bIvGg=.215cce08-92b8-4a05-bceb-7645faa4ea9b@github.com>

On Tue, 15 Apr 2025 05:18:34 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Hi All,
> I would like to add this bug fix for the bug in jdk/jfr/startupargs/TestMemoryOptions.java. 
> I was unable to reproduce the reported problem in java versions 11 and later. Therefore, I made a pull request for 8u before.
> https://github.com/openjdk/jdk8u-dev/pull/641
> However, the latest java should be fixed, as the bugs described below will potentially remain in the test.
> 
> This test contains 24 test cases and fails the "ThreadBufferSizeExceedMemorySize" case.
> The cause of this bug is the memory allocation issue, which occurs only on 32-bit Server VM, not on Client VM or 64-bit JDK. The failure happens because Server VM's default heap size reduces available memory space, causing JFR to fail memory allocation.
> To resolve this issue, -Xmx256M is explicitly set, matching the Client VM default heap size, ensuring sufficient memory space remains available for JFR.
> I believe that this test verifies that the combination of memory options for JFR is valid or invalid and that the MaxHeapSize setting does not affect the verification.
> Change has been verified locally, test-fix only, no risk.
> 
> Would someone please review this fix?

Trivial.

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

PR Comment: https://git.openjdk.org/jdk/pull/24646#issuecomment-2809987695

From duke at openjdk.org  Wed Apr 16 15:44:57 2025
From: duke at openjdk.org (KIRIYAMA Takuya)
Date: Wed, 16 Apr 2025 15:44:57 GMT
Subject: Integrated: 8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails
 with 32-bit build
In-Reply-To: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
References: <KfxyY53NYv5kiSimD19gbYeI7QZYJ7mWZcyDuE18yhY=.21d05583-c9d7-4d8b-86ce-4e68e1ce0138@github.com>
Message-ID: <G4gbqW8sEEFSEDG0mhnAjgZtajCL7m_pmNKuhD2JCx4=.b98f1e6c-d7eb-413d-9510-1fb6c6f48e58@github.com>

On Tue, 15 Apr 2025 05:18:34 GMT, KIRIYAMA Takuya <duke at openjdk.org> wrote:

> Hi All,
> I would like to add this bug fix for the bug in jdk/jfr/startupargs/TestMemoryOptions.java. 
> I was unable to reproduce the reported problem in java versions 11 and later. Therefore, I made a pull request for 8u before.
> https://github.com/openjdk/jdk8u-dev/pull/641
> However, the latest java should be fixed, as the bugs described below will potentially remain in the test.
> 
> This test contains 24 test cases and fails the "ThreadBufferSizeExceedMemorySize" case.
> The cause of this bug is the memory allocation issue, which occurs only on 32-bit Server VM, not on Client VM or 64-bit JDK. The failure happens because Server VM's default heap size reduces available memory space, causing JFR to fail memory allocation.
> To resolve this issue, -Xmx256M is explicitly set, matching the Client VM default heap size, ensuring sufficient memory space remains available for JFR.
> I believe that this test verifies that the combination of memory options for JFR is valid or invalid and that the MaxHeapSize setting does not affect the verification.
> Change has been verified locally, test-fix only, no risk.
> 
> Would someone please review this fix?

This pull request has now been integrated.

Changeset: c3de94ce
Author:    KIRIYAMA Takuya <kiriyama.takuya at fujitsu.com>
Committer: Paul Hohensee <phh at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3de94cee12471a11c457c11dd55c547633de5cb
Stats:     2 lines in 1 file changed: 2 ins; 0 del; 0 mod

8352942: jdk/jfr/startupargs/TestMemoryOptions.java fails with 32-bit build

Reviewed-by: phh

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

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

From egahlin at openjdk.org  Wed Apr 16 20:14:54 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 16 Apr 2025 20:14:54 GMT
Subject: Integrated: 8295651: JFR: 'jfr scrub' should summarize what was
 removed
In-Reply-To: <1dkgMuhG6B_rSxCqqP_H8-ocdCLF_OFz69SOCgUe0Ks=.508d0ab5-8262-433f-9790-9f10b4ee5aa1@github.com>
References: <1dkgMuhG6B_rSxCqqP_H8-ocdCLF_OFz69SOCgUe0Ks=.508d0ab5-8262-433f-9790-9f10b4ee5aa1@github.com>
Message-ID: <k1U5et1V4I5xUItAKqw13i7UPyitL-Hq8nSWk5cSZhQ=.cbf941b6-ea04-419a-8e70-fcf84a4c419b@github.com>

On Tue, 15 Apr 2025 22:22:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of an enhancement that summarizes the results of `jfr scrub`?
> 
> To accommodate this feature, I made some additional changes:
> 
> - Added a LongMap::values() method.
> - Added a Command::printf(...) method, which is now also used by `jfr summary`.
> - Improved TestScrub.java so it now creates a file that spans multiple chunks, including an empty one.
> 
> To make it easier to locate the scrubbed file, I also changed so the real path instead of the of the absolute path is displayed in the summary 
> 
> See issue for example output.
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: a2d7f441
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a2d7f441b8616e0cd8c231f3358b1b508e76686d
Stats:     138 lines in 9 files changed: 123 ins; 2 del; 13 mod

8295651: JFR: 'jfr scrub' should summarize what was removed

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Thu Apr 17 15:52:11 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Apr 2025 15:52:11 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class
Message-ID: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>

Could I have a review of a PR that cleans up the EventInstrumentation class and moves the non-modifying parts into a separate class (ClassInspector)? 

I deleted the code that removes the instrumentation (buildUninstrumented), because it has never been used. If there should be a need for it in the future, it's not hard to add code that inserts empty method bodies.

Testing: tier1 + jdk/jdk/jfr/test

Thanks
Erik

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

Commit messages:
 - Initial

Changes: https://git.openjdk.org/jdk/pull/24726/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24726&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8354949
  Stats: 977 lines in 5 files changed: 448 ins; 359 del; 170 mod
  Patch: https://git.openjdk.org/jdk/pull/24726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24726/head:pull/24726

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

From liach at openjdk.org  Thu Apr 17 17:51:45 2025
From: liach at openjdk.org (Chen Liang)
Date: Thu, 17 Apr 2025 17:51:45 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class
In-Reply-To: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
Message-ID: <7SZU5INwe4ecThK6t3AREq_vXFRfjXrEOjFyD9Wrwvs=.34570f43-4689-416c-82e3-a77b983762ee@github.com>

On Thu, 17 Apr 2025 14:11:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that cleans up the EventInstrumentation class and moves the non-modifying parts into a separate class (ClassInspector)? 
> 
> I deleted the code that removes the instrumentation (buildUninstrumented), because it has never been used. If there should be a need for it in the future, it's not hard to add code that inserts empty method bodies.
> 
> Testing: tier1 + jdk/jdk/jfr/test
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 102:

> 100:         for (MethodModel method : classModel.methods()) {
> 101:             String d = method.methodTypeSymbol().descriptorString();
> 102:             if (method.methodName().equalsString("commit") && m.descriptor().descriptorString().equals(d)) {

I think we need a `MethodDesc.matches` to conveniently check a (name, methodTypeDesc) tuple matches a NameAndType entry or a MethodModel. This check is repeated a few times in this class.

src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 145:

> 143:         for (MethodModel m : classModel.methods()) {
> 144:             if (m.methodName().equalsString(method.name()) && m.methodTypeSymbol().equals(method.descriptor())) {
> 145:                 return Modifier.isStatic(m.flags().flagsMask());

Nit: checking the static flag before checking the name might require less method name decoding

src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 217:

> 215:         List<AnnotationValue> list = new ArrayList<>();
> 216:         for (Attribute<?> attribute: classModel.attributes()) {
> 217:             if (attribute instanceof RuntimeVisibleAnnotationsAttribute rvaa) {

`findAttribute` or `findAttributes` can be helpful if you just want one attribute.

src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 291:

> 289:                             // Add setting if method returns boolean and has one parameter
> 290:                             MethodTypeDesc mtd = m.methodTypeSymbol();
> 291:                             if ("Z".equals(mtd.returnType().descriptorString())) {

`if (CD_boolean.equals(mtd.returnType()))` might be more straightforward.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24726#discussion_r2049384841
PR Review Comment: https://git.openjdk.org/jdk/pull/24726#discussion_r2049386739
PR Review Comment: https://git.openjdk.org/jdk/pull/24726#discussion_r2049388365
PR Review Comment: https://git.openjdk.org/jdk/pull/24726#discussion_r2049391888

From egahlin at openjdk.org  Thu Apr 17 20:13:35 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Apr 2025 20:13:35 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v2]
In-Reply-To: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
Message-ID: <CWoIA3oqfMNl7C3qMhymGphJVzE6SwadDNctIuT5CMY=.c66a4d8e-9c71-427d-b550-899b9e75a7ca@github.com>

> Could I have a review of a PR that cleans up the EventInstrumentation class and moves the non-modifying parts into a separate class (ClassInspector)? 
> 
> I deleted the code that removes the instrumentation (buildUninstrumented), because it has never been used. If there should be a need for it in the future, it's not hard to add code that inserts empty method bodies.
> 
> Testing: tier1 + jdk/jdk/jfr/test
> 
> Thanks
> Erik

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

  Build settings and fields only when needed

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24726/files
  - new: https://git.openjdk.org/jdk/pull/24726/files/e692363d..8ecb2732

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

  Stats: 53 lines in 3 files changed: 11 ins; 11 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/24726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24726/head:pull/24726

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

From egahlin at openjdk.org  Thu Apr 17 20:17:59 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 17 Apr 2025 20:17:59 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v2]
In-Reply-To: <7SZU5INwe4ecThK6t3AREq_vXFRfjXrEOjFyD9Wrwvs=.34570f43-4689-416c-82e3-a77b983762ee@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
 <7SZU5INwe4ecThK6t3AREq_vXFRfjXrEOjFyD9Wrwvs=.34570f43-4689-416c-82e3-a77b983762ee@github.com>
Message-ID: <KHsTsJd8qQu6dldzhv6kruPZfbBIEcaaB820oOh2eDE=.4e550cd9-4215-4591-9d89-f88bfdafee45@github.com>

On Thu, 17 Apr 2025 17:26:34 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Build settings and fields only when needed
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 102:
> 
>> 100:         for (MethodModel method : classModel.methods()) {
>> 101:             String d = method.methodTypeSymbol().descriptorString();
>> 102:             if (method.methodName().equalsString("commit") && m.descriptor().descriptorString().equals(d)) {
> 
> I think we need a `MethodDesc.matches` to conveniently check a (name, methodTypeDesc) tuple matches a NameAndType entry or a MethodModel. This check is repeated a few times in this class.

Good idea.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24726#discussion_r2049588351

From egahlin at openjdk.org  Fri Apr 18 12:03:43 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 18 Apr 2025 12:03:43 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v3]
In-Reply-To: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
Message-ID: <iUOzZb4yA22sFIIU24M63IJxF0GFSja2s7yovObJeKk=.4f420f43-382a-4d16-bb7c-e40f1d595d1d@github.com>

> Could I have a review of a PR that cleans up the EventInstrumentation class and moves the non-modifying parts into a separate class (ClassInspector)? 
> 
> I deleted the code that removes the instrumentation (buildUninstrumented), because it has never been used. If there should be a need for it in the future, it's not hard to add code that inserts empty method bodies.
> 
> Testing: tier1 + jdk/jdk/jfr/test
> 
> 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/24726/files
  - new: https://git.openjdk.org/jdk/pull/24726/files/8ecb2732..07a56859

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

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

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

From egahlin at openjdk.org  Fri Apr 18 12:08:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 18 Apr 2025 12:08:53 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v4]
In-Reply-To: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
Message-ID: <hxwYEzDsZx6JekTFX-Ted0ozBfrN8LjBzngpI70UPt0=.84aded73-8cc7-4e0d-b55c-22ff859676ec@github.com>

> Could I have a review of a PR that cleans up the EventInstrumentation class and moves the non-modifying parts into a separate class (ClassInspector)? 
> 
> I deleted the code that removes the instrumentation (buildUninstrumented), because it has never been used. If there should be a need for it in the future, it's not hard to add code that inserts empty method bodies.
> 
> Testing: tier1 + jdk/jdk/jfr/test
> 
> Thanks
> Erik

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

  Remove accidentally added printStackTrace()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24726/files
  - new: https://git.openjdk.org/jdk/pull/24726/files/07a56859..d6de2665

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

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

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

From egahlin at openjdk.org  Fri Apr 18 12:22:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 18 Apr 2025 12:22:46 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v4]
In-Reply-To: <7SZU5INwe4ecThK6t3AREq_vXFRfjXrEOjFyD9Wrwvs=.34570f43-4689-416c-82e3-a77b983762ee@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
 <7SZU5INwe4ecThK6t3AREq_vXFRfjXrEOjFyD9Wrwvs=.34570f43-4689-416c-82e3-a77b983762ee@github.com>
Message-ID: <Pe6Vs4vDVkoDuBYi8RB8_R_aD1J3Uzrf0mbtI-C_sko=.2f59ac97-5bf0-411a-ae78-c651810be931@github.com>

On Thu, 17 Apr 2025 17:28:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove accidentally added printStackTrace()
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/ClassInspector.java line 217:
> 
>> 215:         List<AnnotationValue> list = new ArrayList<>();
>> 216:         for (Attribute<?> attribute: classModel.attributes()) {
>> 217:             if (attribute instanceof RuntimeVisibleAnnotationsAttribute rvaa) {
> 
> `findAttribute` or `findAttributes` can be helpful if you just want one attribute.

Agree, but I like to refactor that in a later PR. That part of the code needs a complete rewrite.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24726#discussion_r2050544431

From jbachorik at openjdk.org  Fri Apr 18 15:42:53 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Fri, 18 Apr 2025 15:42:53 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v4]
In-Reply-To: <bqk02feSnWOjq6uXOZtg4DpffZmK8A1eiE9yZaDN7aM=.e70706e0-fa5d-4fa4-a55e-1e1aba8eaa71@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <bqk02feSnWOjq6uXOZtg4DpffZmK8A1eiE9yZaDN7aM=.e70706e0-fa5d-4fa4-a55e-1e1aba8eaa71@github.com>
Message-ID: <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>

On Mon, 7 Apr 2025 10:53:32 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
>> 
>> Implementations in this change set are provided and have been tested on the following platforms:
>> 
>> - windows-x64
>> - windows-x64-debug
>> - linux-x64
>> - linux-x64-debug
>> - macosx-x64
>> - macosx-x64-debug
>> - linux-aarch64
>> - linux-aarch64-debug
>> - macosx-aarch64
>> - macosx-aarch64-debug
>> 
>> Testing: tier1-6, jdk_jfr, stress testing.
>> 
>> Platform porters note:
>> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
>> 
>> - src/hotspot/cpu/x86/frame_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.cpp
>> - src/hotspot/cpu/x86/interp_masm_x86.hpp
>> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
>> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
>> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
>> - src/hotspot/cpu/x86/templateTable_x86.cpp
>> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains five commits:
> 
>  - Merge branch 'master' into 8352251
>  - align params
>  - adjustments
>  - refactoring
>  - 8352251

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 73:

> 71: }
> 72: 
> 73: // A sampled interpreter frame is handled differenly compared to a sampled compiler frame.

Suggestion:

// A sampled interpreter frame is handled differently compared to a sampled compiler frame.

src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp line 82:

> 80:   assert(jt->has_last_Java_frame(), "invariant");
> 81: 
> 82:   // For a request representing an interpreter frame, request._sample_sp is actually the frame pointer, fp.

:)

src/hotspot/share/jfr/recorder/service/jfrEventThrottler.cpp line 70:

> 68: // There is currently only two throttler instance, one for the jdk.ObjectAllocationSample event
> 69: // and another for the SamplingLatency event.
> 70: // When introducing many more throttlers, consider addomg a lookup map keyed by event id.

Suggestion:

// When introducing many more throttlers, consider adding a lookup map keyed by event id.

src/hotspot/share/jfr/recorder/stacktrace/jfrStackTrace.cpp line 114:

> 112:   _written = true;
> 113: }
> 114: 

`JfrStackFrame::equals()` is already defined in jfrStackFrame.cpp

src/hotspot/share/jfr/recorder/stacktrace/jfrVframeStream.hpp line 2:

> 1: /*
> 2:  * Copyright (c) 2011, 2024, Oracle and/or its affiliates. All rights reserved.

Why are the copyright years different here?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2050656607
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2050657042
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2050765959
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2050770381
PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2050775884

From mgronlun at openjdk.org  Fri Apr 18 22:24:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 18 Apr 2025 22:24:34 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v5]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <RMB4haoB7KuHbq782bo0kT0CPe1f7UUM4ASCgrGNi94=.d2c96519-508f-4de6-a801-750d8bcab48f@github.com>

> Greetings,
> 
> This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338).
> 
> Implementations in this change set are provided and have been tested on the following platforms:
> 
> - windows-x64
> - windows-x64-debug
> - linux-x64
> - linux-x64-debug
> - macosx-x64
> - macosx-x64-debug
> - linux-aarch64
> - linux-aarch64-debug
> - macosx-aarch64
> - macosx-aarch64-debug
> 
> Testing: tier1-6, jdk_jfr, stress testing.
> 
> Platform porters note:
> Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes:
> 
> - src/hotspot/cpu/x86/frame_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.cpp
> - src/hotspot/cpu/x86/interp_masm_x86.hpp
> - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp
> - src/hotspot/cpu/x86/macroAssembler_x86.cpp
> - src/hotspot/cpu/x86/macroAssembler_x86.hpp
> - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp
> - src/hotspot/cpu/x86/templateTable_x86.cpp
> - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains seven commits:

 - Merge branch '8352251' of github.com:mgronlun/jdk into 8352251
 - Merge branch 'master' into 8352251
 - Merge branch 'master' into 8352251
 - align params
 - adjustments
 - refactoring
 - 8352251

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=04
  Stats: 3211 lines in 77 files changed: 1904 ins; 960 del; 347 mod
  Patch: https://git.openjdk.org/jdk/pull/24296.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296

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