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

From mgronlun at openjdk.org  Sat Apr 19 11:32:44 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 19 Apr 2025 11:32:44 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v4]
In-Reply-To: <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <bqk02feSnWOjq6uXOZtg4DpffZmK8A1eiE9yZaDN7aM=.e70706e0-fa5d-4fa4-a55e-1e1aba8eaa71@github.com>
 <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>
Message-ID: <v5zXvdJYcQS9F9IPDM_FG9Ncvq8Qv5UCmecZfedHkVg=.fc213b91-3026-492c-83a1-ec8b469573e7@github.com>

On Fri, 18 Apr 2025 15:31:17 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> 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/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?

I have no idea why GIt seem to think this is a rename of runtime/suspendedThreadTask.cpp? But it should be 2025, not 2024.

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

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

From mgronlun at openjdk.org  Sat Apr 19 11:37:42 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 19 Apr 2025 11:37:42 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v4]
In-Reply-To: <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <bqk02feSnWOjq6uXOZtg4DpffZmK8A1eiE9yZaDN7aM=.e70706e0-fa5d-4fa4-a55e-1e1aba8eaa71@github.com>
 <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>
Message-ID: <fRKNzH1iPzOIhuj-Vo-kpy-E_BMdN5Y8KIjw6WexYBs=.d30d7ea3-4c87-46e4-a7af-81701e79d4ae@github.com>

On Fri, 18 Apr 2025 13:52:01 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> 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 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.
> 
> :)

Yeah...

?\_(?)_/?

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

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

From mgronlun at openjdk.org  Sat Apr 19 11:43:02 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 19 Apr 2025 11:43:02 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v6]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <KL35rzorAJotAvU7AqQJnqOo_Ur7iYOOkCP7br3AGJY=.94a033c2-49ab-4f17-ab0e-efb368e7d1ad@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 incrementally with one additional commit since the last revision:

  review comments

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/e48905fc..0da2c2d9

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

  Stats: 4 lines in 3 files changed: 0 ins; 0 del; 4 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 mgronlun at openjdk.org  Sat Apr 19 11:43:03 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sat, 19 Apr 2025 11:43:03 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v4]
In-Reply-To: <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <bqk02feSnWOjq6uXOZtg4DpffZmK8A1eiE9yZaDN7aM=.e70706e0-fa5d-4fa4-a55e-1e1aba8eaa71@github.com>
 <YoTYkDLp5TU0kTKlFlqWTqoDBcfBNwMr--9HgDJlav4=.54c6d4e8-aa49-4a63-a26c-fc2eb1176e8b@github.com>
Message-ID: <XUiELNgq9mK2bNz92Cgia0F2cup_aDhH2JuF1GBUZuA=.8600f1f3-4749-4251-a725-0ad709c64dd6@github.com>

On Fri, 18 Apr 2025 15:25:59 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> 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/recorder/stacktrace/jfrStackTrace.cpp line 114:
> 
>> 112:   _written = true;
>> 113: }
>> 114: 
> 
> `JfrStackFrame::equals()` is already defined in jfrStackFrame.cpp

Fixed now as part of the upstream merge.

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

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

From mgronlun at openjdk.org  Mon Apr 21 20:01:42 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 21 Apr 2025 20:01:42 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v7]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <_2BpB9TYtN4V1Fao3Ew5JWnEHNjm8CmIDPlahaz-jlg=.43807461-1e69-47eb-b24b-dba26d1de37e@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 incrementally with two additional commits since the last revision:

 - Update default.jfc
 - Update profile.jfc

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/0da2c2d9..d6854a84

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

  Stats: 3 lines in 2 files changed: 2 ins; 0 del; 1 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 mgronlun at openjdk.org  Mon Apr 21 20:11:27 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 21 Apr 2025 20:11:27 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v8]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <Dscrue5aD4tdamru7BsdBoYYng2EypX0mSbvnKi6zOc=.f8a3fc83-9963-43f4-bb62-afbcd95329d9@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 incrementally with one additional commit since the last revision:

  Refine SamplingLatency event description

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/d6854a84..447ce857

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 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 mgronlun at openjdk.org  Tue Apr 22 13:42:41 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 22 Apr 2025 13:42:41 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v4]
In-Reply-To: <hxwYEzDsZx6JekTFX-Ted0ozBfrN8LjBzngpI70UPt0=.84aded73-8cc7-4e0d-b55c-22ff859676ec@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
 <hxwYEzDsZx6JekTFX-Ted0ozBfrN8LjBzngpI70UPt0=.84aded73-8cc7-4e0d-b55c-22ff859676ec@github.com>
Message-ID: <mXCy2ShwDL2B28W3qnDRLWPCfRgZ_BjrfnnmWCz3cNk=.4849d4d2-b4fc-4660-880a-c8fe8aa43626@github.com>

On Fri, 18 Apr 2025 12:08:53 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
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidentally added printStackTrace()

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/24726#pullrequestreview-2784160522

From liach at openjdk.org  Tue Apr 22 15:46:47 2025
From: liach at openjdk.org (Chen Liang)
Date: Tue, 22 Apr 2025 15:46:47 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v4]
In-Reply-To: <hxwYEzDsZx6JekTFX-Ted0ozBfrN8LjBzngpI70UPt0=.84aded73-8cc7-4e0d-b55c-22ff859676ec@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
 <hxwYEzDsZx6JekTFX-Ted0ozBfrN8LjBzngpI70UPt0=.84aded73-8cc7-4e0d-b55c-22ff859676ec@github.com>
Message-ID: <qsTZss4fgs1_uzwEfrxTcWTJgOlLS7CYiyxKmx-VQFQ=.57d80698-05b3-49c3-89ec-cb85dc6f5f0a@github.com>

On Fri, 18 Apr 2025 12:08:53 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
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidentally added printStackTrace()

ClassFile API usages look good.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/24726#pullrequestreview-2784562744

From mgronlun at openjdk.org  Tue Apr 22 19:57:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 22 Apr 2025 19:57:00 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v9]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <zoH0DGMkCR3IEplYux7otJDWGF6cktZ_e6-j1DUHL7Y=.171e2646-4f3c-4a53-8db0-9275635c21de@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 12 commits:

 - Merge branch 'master' into 8352251
 - Refine SamplingLatency event description
 - Update default.jfc
 - Update profile.jfc
 - review comments
 - Merge branch '8352251' of github.com:mgronlun/jdk into 8352251
 - Merge branch 'master' into 8352251
 - Merge branch 'master' into 8352251
 - align params
 - adjustments
 - ... and 2 more: https://git.openjdk.org/jdk/compare/d61765f6...5f2351c8

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

Changes: https://git.openjdk.org/jdk/pull/24296/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=08
  Stats: 3212 lines in 77 files changed: 1906 ins; 960 del; 346 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 shade at openjdk.org  Wed Apr 23 08:46:53 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 23 Apr 2025 08:46:53 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v9]
In-Reply-To: <zoH0DGMkCR3IEplYux7otJDWGF6cktZ_e6-j1DUHL7Y=.171e2646-4f3c-4a53-8db0-9275635c21de@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zoH0DGMkCR3IEplYux7otJDWGF6cktZ_e6-j1DUHL7Y=.171e2646-4f3c-4a53-8db0-9275635c21de@github.com>
Message-ID: <wLkbd3RlpFmnvE5vNFrUCdO5e9p4AMbhx1T8NQ843vw=.fd3b4258-ae35-4a46-ab94-f9158b7626a3@github.com>

On Tue, 22 Apr 2025 19:57:00 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 12 commits:
> 
>  - Merge branch 'master' into 8352251
>  - Refine SamplingLatency event description
>  - Update default.jfc
>  - Update profile.jfc
>  - review comments
>  - Merge branch '8352251' of github.com:mgronlun/jdk into 8352251
>  - Merge branch 'master' into 8352251
>  - Merge branch 'master' into 8352251
>  - align params
>  - adjustments
>  - ... and 2 more: https://git.openjdk.org/jdk/compare/d61765f6...5f2351c8

Zero does not use JFR, `jfr` build feature flag is not enabled. So we only need to make sure it compiles. It currently does not, because `last_Java_fp` returns `ZeroFrame*`, and not generic `intptr_t*`. Here:  [jfr-cooperative-zero-1.txt](https://github.com/user-attachments/files/19863729/jfr-cooperative-zero-1.txt)

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

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

From egahlin at openjdk.org  Wed Apr 23 11:51:48 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 23 Apr 2025 11:51:48 GMT
Subject: RFR: 8354949: JFR: Split up the EventInstrumentation class [v4]
In-Reply-To: <hxwYEzDsZx6JekTFX-Ted0ozBfrN8LjBzngpI70UPt0=.84aded73-8cc7-4e0d-b55c-22ff859676ec@github.com>
References: <pnYSLkkfZQE5vOiIu9oe_mATQB1lJn1GLlSQJLI69OA=.b23f611c-8417-4925-8038-0ece7c394fbb@github.com>
 <hxwYEzDsZx6JekTFX-Ted0ozBfrN8LjBzngpI70UPt0=.84aded73-8cc7-4e0d-b55c-22ff859676ec@github.com>
Message-ID: <Acolzft6il39kVF9Gf7D_CFMotqKkyN2kV5orDmebeI=.e98fbd93-163c-4b1a-80f2-bb0d5d606cbd@github.com>

On Fri, 18 Apr 2025 12:08:53 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
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove accidentally added printStackTrace()

Thanks for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/24726#issuecomment-2824019789

From egahlin at openjdk.org  Wed Apr 23 11:51:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 23 Apr 2025 11:51:49 GMT
Subject: Integrated: 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: <e_RVoLfStRglZ22yqa9J35weHm4hzIEw1ZTzOjbpCV0=.344651dc-ff6d-4a0d-9925-e6b4d530caf4@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

This pull request has now been integrated.

Changeset: ef0cd182
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef0cd1823d7d57e42e66255a0e80bfa495a7102d
Stats:     980 lines in 5 files changed: 451 ins; 359 del; 170 mod

8354949: JFR: Split up the EventInstrumentation class

Reviewed-by: mgronlun, liach

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

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

From mgronlun at openjdk.org  Wed Apr 23 19:30:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 23 Apr 2025 19:30:52 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v9]
In-Reply-To: <wLkbd3RlpFmnvE5vNFrUCdO5e9p4AMbhx1T8NQ843vw=.fd3b4258-ae35-4a46-ab94-f9158b7626a3@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zoH0DGMkCR3IEplYux7otJDWGF6cktZ_e6-j1DUHL7Y=.171e2646-4f3c-4a53-8db0-9275635c21de@github.com>
 <wLkbd3RlpFmnvE5vNFrUCdO5e9p4AMbhx1T8NQ843vw=.fd3b4258-ae35-4a46-ab94-f9158b7626a3@github.com>
Message-ID: <R42iD3G5lf6WnQgiyw_5R2cviFp2Uk7j7MdysGND0Ig=.b3ee0f49-1a39-42ce-98b0-b01f0abcd257@github.com>

On Wed, 23 Apr 2025 08:44:17 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> Zero does not use JFR, `jfr` build feature flag is not enabled. So we only need to make sure it compiles. It currently does not, because `last_Java_fp` returns `ZeroFrame*`, and not generic `intptr_t*`. Here: [jfr-cooperative-zero-1.txt](https://github.com/user-attachments/files/19863729/jfr-cooperative-zero-1.txt)

Thanks alot @shipilev . It was precisely this "ZeroFrame*" that tripped me up.

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

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

From mgronlun at openjdk.org  Wed Apr 23 19:47:01 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 23 Apr 2025 19:47:01 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v10]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <WY0vNAat0VUBLOEm67M0nuVOrhQo-33MKMXl--Nng3w=.d76bf566-0ef5-4083-b6d6-01825050f20c@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 incrementally with one additional commit since the last revision:

  zero

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/5f2351c8..283862c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=08-09

  Stats: 5 lines in 2 files changed: 0 ins; 0 del; 5 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 mgronlun at openjdk.org  Wed Apr 23 23:08:41 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 23 Apr 2025 23:08:41 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v11]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <fcBMMx0HE3buMXJBazJnfp5Eo_dWYldOlADaXT4dkY4=.cabedacd-189d-4b61-bcb1-b6373af41cbc@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 incrementally with one additional commit since the last revision:

  No invariants for sender_for_interpreter_frame

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/283862c5..92bbfbac

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=09-10

  Stats: 5 lines in 1 file changed: 3 ins; 2 del; 0 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 shade at openjdk.org  Thu Apr 24 09:09:57 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 24 Apr 2025 09:09:57 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v11]
In-Reply-To: <fcBMMx0HE3buMXJBazJnfp5Eo_dWYldOlADaXT4dkY4=.cabedacd-189d-4b61-bcb1-b6373af41cbc@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <fcBMMx0HE3buMXJBazJnfp5Eo_dWYldOlADaXT4dkY4=.cabedacd-189d-4b61-bcb1-b6373af41cbc@github.com>
Message-ID: <zjlr9X9Uwx4lHJGYQWrfwqk-TWJfLuGXz9Mkg-fJTqc=.967b7917-004c-4887-b621-375345222709@github.com>

On Wed, 23 Apr 2025 23:08:41 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 one additional commit since the last revision:
> 
>   No invariants for sender_for_interpreter_frame

(Sorry for dripping review comments, I have only limited time a day to look at this)

Looks like windows-aarch64 GHA build fails with:


d:\a\jdk\jdk\src\hotspot\cpu\aarch64\interp_masm_aarch64.cpp(475): error C2039: 'last_sender_Java_fp_offset': is not a member of 'JavaThread'
d:\a\jdk\jdk\src\hotspot\share\runtime/threads.hpp(34): note: see declaration of 'JavaThread'


I suspect the fix is as simple as adding the hunk that you already have in `javaThread_windows_x86.hpp` to `javaThread_windows_aarch64.hpp` as well.

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

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

From mgronlun at openjdk.org  Thu Apr 24 09:41:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 24 Apr 2025 09:41:48 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v11]
In-Reply-To: <zjlr9X9Uwx4lHJGYQWrfwqk-TWJfLuGXz9Mkg-fJTqc=.967b7917-004c-4887-b621-375345222709@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <fcBMMx0HE3buMXJBazJnfp5Eo_dWYldOlADaXT4dkY4=.cabedacd-189d-4b61-bcb1-b6373af41cbc@github.com>
 <zjlr9X9Uwx4lHJGYQWrfwqk-TWJfLuGXz9Mkg-fJTqc=.967b7917-004c-4887-b621-375345222709@github.com>
Message-ID: <73m8xvoryHl8XFfvDT9xo-nKoXW9wRmXNGg9utVRZE0=.1752453d-4da5-4740-9c98-3257707e9152@github.com>

On Thu, 24 Apr 2025 09:06:49 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> (Sorry for dripping review comments, I have only limited time a day to look at this)
> 
> Looks like windows-aarch64 GHA build fails with:
> 
> ```
> d:\a\jdk\jdk\src\hotspot\cpu\aarch64\interp_masm_aarch64.cpp(475): error C2039: 'last_sender_Java_fp_offset': is not a member of 'JavaThread'
> d:\a\jdk\jdk\src\hotspot\share\runtime/threads.hpp(34): note: see declaration of 'JavaThread'
> ```
> 
> I suspect the fix is as simple as adding the hunk that you already have in `javaThread_windows_x86.hpp` to `javaThread_windows_aarch64.hpp` as well.

Thats ok.

If we fix the builds, it may hide the need to make the platform changes required, and will fail spectacularly if they are not addressed correctly. I have sent an email to porters-dev.

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

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

From mgronlun at openjdk.org  Thu Apr 24 09:53:38 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 24 Apr 2025 09:53:38 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v12]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@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 incrementally with one additional commit since the last revision:

  Attempt to build Windows-AARCH64

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/92bbfbac..771a397a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=10-11

  Stats: 4 lines in 1 file changed: 4 ins; 0 del; 0 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 mdoerr at openjdk.org  Fri Apr 25 17:00:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 25 Apr 2025 17:00:53 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v12]
In-Reply-To: <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@github.com>
Message-ID: <LNEF5UQfB-_K5eC8Agy6TF_tNs9uvXNGmY7PU07hc30=.1096a63b-90ae-4b01-a0f6-e9a0e352eeae@github.com>

On Thu, 24 Apr 2025 09:53:38 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 one additional commit since the last revision:
> 
>   Attempt to build Windows-AARCH64

Hi, I've taken a quick look and wonder what needs to be done for PPC64 which has some fundamental differences.

We never need to pass an FP because it can always be retrieved like this via Back Chain (required by "Power Architecture 64-Bit ELF V2 ABI Specification"): FP = *SP
So, I guess we could use something like

diff --git a/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp b/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp
index 8b539bc8101..7d07c302b36 100644
--- a/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp
+++ b/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp
@@ -73,6 +73,10 @@
 
   address last_Java_pc(void)          { return _last_Java_pc; }
 
+  intptr_t* last_Java_fp() const      { return *(intptr_t**)_last_Java_sp; }
+
+  intptr_t* last_sender_Java_fp() const { return **(intptr_t***)_last_Java_sp; }
+
   void set_last_Java_sp(intptr_t* sp) { OrderAccess::release(); _last_Java_sp = sp; }
 
 #endif // CPU_PPC_JAVAFRAMEANCHOR_PPC_HPP


This frame constructor does not exist on PPC64:
https://github.com/openjdk/jdk/blob/771a397a12a3bcb25af1f508061fd928d8f13c2e/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp#L174
We have one with different argument order and could emulate it like this:
```C++
inline frame::frame(intptr_t* sp, intptr_t* unextended_sp, intptr_t* sender_sp, address pc, CodeBlob* cb) :
  frame(sp, pc, unextended_sp, sender_sp, cb) {}

Strange if we really need another one which only turns the argument order.

The following constants do not exist:
```C++
    // Used by JFR. Unfortunately, we can't use offset_of because it's not constexpr.
    ijava_state_slots                      = ijava_state_size >> LogBytesPerWord,
    // Members of ijava_state:
    interpreter_frame_method_offset        = -ijava_state_slots + 0,
    interpreter_frame_bcp_offset           = -ijava_state_slots + 5,
    interpreter_frame_sender_sp_offset     = -ijava_state_slots + 9,
    // Stuff which shouldn't be used on this platform:
    interpreter_frame_initial_sp_offset    = -ijava_state_slots,
    link_offset                            = 0,
    sender_sp_offset                       = 0,
    // Member of common_abi: lr
    return_addr_offset                     = 2,

I hate adding them. Could we move the usages into platform code?

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

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

From mgronlun at openjdk.org  Sun Apr 27 16:37:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 27 Apr 2025 16:37:48 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v12]
In-Reply-To: <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@github.com>
Message-ID: <X-ucRsX0a1pPJJkwzgDXP8ZrT__-cXyoZ8Vc-Zgepc4=.9914b2ed-1180-4885-864f-9112a565ed95@github.com>

On Thu, 24 Apr 2025 09:53:38 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 one additional commit since the last revision:
> 
>   Attempt to build Windows-AARCH64

> Hi, I've taken a quick look and wonder what needs to be done for PPC64 which has some fundamental differences.
> 
> We never need to pass an FP because it can always be retrieved like this via Back Chain (required by "Power Architecture 64-Bit ELF V2 ABI Specification"): FP = *SP So, I guess we could use something like
> 
> ```diff
> diff --git a/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp b/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp
> index 8b539bc8101..7d07c302b36 100644
> --- a/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp
> +++ b/src/hotspot/cpu/ppc/javaFrameAnchor_ppc.hpp
> @@ -73,6 +73,10 @@
>  
>    address last_Java_pc(void)          { return _last_Java_pc; }
>  
> +  intptr_t* last_Java_fp() const      { return *(intptr_t**)_last_Java_sp; }
> +
> +  intptr_t* last_sender_Java_fp() const { return **(intptr_t***)_last_Java_sp; }
> +
>    void set_last_Java_sp(intptr_t* sp) { OrderAccess::release(); _last_Java_sp = sp; }
>  
>  #endif // CPU_PPC_JAVAFRAMEANCHOR_PPC_HPP
> ```
> 
> This frame constructor does not exist on PPC64:
> 
> https://github.com/openjdk/jdk/blob/771a397a12a3bcb25af1f508061fd928d8f13c2e/src/hotspot/share/jfr/periodic/sampling/jfrThreadSampling.cpp#L174
> 
> We have one with different argument order and could emulate it like this:
> 
> ```c++
> inline frame::frame(intptr_t* sp, intptr_t* unextended_sp, intptr_t* sender_sp, address pc, CodeBlob* cb) :
>   frame(sp, pc, unextended_sp, sender_sp, cb) {}
> ```
> 
> Strange if we really need another one which only turns the argument order.
> 
> The following constants do not exist:
> 
> ```c++
>     // Used by JFR. Unfortunately, we can't use offset_of because it's not constexpr.
>     ijava_state_slots                      = ijava_state_size >> LogBytesPerWord,
>     // Members of ijava_state:
>     interpreter_frame_method_offset        = -ijava_state_slots + 0,
>     interpreter_frame_bcp_offset           = -ijava_state_slots + 5,
>     interpreter_frame_sender_sp_offset     = -ijava_state_slots + 9,
>     // Stuff which shouldn't be used on this platform:
>     interpreter_frame_initial_sp_offset    = -ijava_state_slots,
>     link_offset                            = 0,
>     sender_sp_offset                       = 0,
>     // Member of common_abi: lr
>     return_addr_offset                     = 2,
> ```
> 
> I hate adding them. Could we move the usages into platform code?

Hi Martin,

On the other platforms, the walker code only uses _last_sender_Java_fp() if it is set. And it is only set by the sensitive Interpreter safe point polls just before frame pop. We would like something that is a value to be tested, which can be set using the mechanism you suggest, but only for those sensitive poll sites.

I am moving support routines that rely on platform-specific constants into platform code. Stay tuned.

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

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

From mgronlun at openjdk.org  Sun Apr 27 16:45:37 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 27 Apr 2025 16:45:37 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v13]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <IfaaKux-BDN-uX16pKdlb8LWRdWM3zWzGsnt5gGeeZI=.59e99908-af29-4302-acd5-9715f32f746f@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 incrementally with one additional commit since the last revision:

  push back pd constants into pd code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/771a397a..ed57ed9f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=11-12

  Stats: 201 lines in 5 files changed: 152 ins; 34 del; 15 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 mgronlun at openjdk.org  Sun Apr 27 16:45:37 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 27 Apr 2025 16:45:37 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v12]
In-Reply-To: <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@github.com>
Message-ID: <ZADmo4dbbWip8hOrXw790KVNDNBRj2dPQfhySOVpGls=.d45652f1-fc14-481a-9d23-90f58404c6c1@github.com>

On Thu, 24 Apr 2025 09:53:38 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 one additional commit since the last revision:
> 
>   Attempt to build Windows-AARCH64

Hope this will makes things easier for you, Martin.

[push back pd constants into pd code](https://github.com/openjdk/jdk/pull/24296/commits/ed57ed9f327729939d6d57108b01ad3972aa0488)

Thanks
Markus

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

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

From mgronlun at openjdk.org  Sun Apr 27 21:58:32 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Sun, 27 Apr 2025 21:58:32 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v14]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@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 incrementally with one additional commit since the last revision:

  include guards

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/ed57ed9f..c65bc8b6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=12-13

  Stats: 57 lines in 4 files changed: 10 ins; 47 del; 0 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 mdoerr at openjdk.org  Mon Apr 28 15:56:48 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 28 Apr 2025 15:56:48 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v12]
In-Reply-To: <ZADmo4dbbWip8hOrXw790KVNDNBRj2dPQfhySOVpGls=.d45652f1-fc14-481a-9d23-90f58404c6c1@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <kFPJzj3-zdBKnFDyLD61LYmLJvRPIspwtg19aR7gALo=.fd2c33a4-d4c4-4fd6-979d-b7ca0ff124ac@github.com>
 <ZADmo4dbbWip8hOrXw790KVNDNBRj2dPQfhySOVpGls=.d45652f1-fc14-481a-9d23-90f58404c6c1@github.com>
Message-ID: <Ytk1CuqlNGJqEETUvdHM_zDbb2VmB_VTrW82fiRrn_w=.ac25353f-2a40-4a72-87f9-03df2944fb30@github.com>

On Sun, 27 Apr 2025 16:42:08 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Hope this will make things easier for you, Martin.
> 
> [push back pd constants into pd code](https://github.com/openjdk/jdk/pull/24296/commits/ed57ed9f327729939d6d57108b01ad3972aa0488)
> 
> Thanks Markus

Thanks a lot! This looks like a much nicer and more generic frame interface. I need to dig through the details, yet.
Would `frame_link` be better name than just `link`? Also some comments would be nice because I find it hard to understand e.g. the difference between fp, sender_sp and link.

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

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

From mgronlun at openjdk.org  Mon Apr 28 21:18:50 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 28 Apr 2025 21:18:50 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v14]
In-Reply-To: <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
Message-ID: <JlN0J0lG_BjO0fT311xy_Y03Sjjv1hEUh83tO-Z28Ds=.3724f6cb-7841-42ea-b87b-b1b829082ca0@github.com>

On Sun, 27 Apr 2025 21:58: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 incrementally with one additional commit since the last revision:
> 
>   include guards

Naming is hard here. The functions are determined by their inputs (fp or sp). But we can try to come up with more descriptive names.

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

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

From mdoerr at openjdk.org  Mon Apr 28 21:25:46 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 28 Apr 2025 21:25:46 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v14]
In-Reply-To: <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
Message-ID: <OPkPMC-4FEOAlOt1LDEC7_SP2DxBYwBvpl-W_tqYw8g=.ebdf29cf-1327-44aa-8d23-3613e12e9d39@github.com>

On Sun, 27 Apr 2025 21:58: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 incrementally with one additional commit since the last revision:
> 
>   include guards

Ok for now. I have a version which has passed jtreg:test/jdk/jdk/jfr tests. Not sure if this is what we want, but feel free to pick it up if you want to repair PPC64:
[PPC64_JFR.patch](https://github.com/user-attachments/files/19949028/PPC64_JFR.patch)

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

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

From mgronlun at openjdk.org  Tue Apr 29 08:20:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Apr 2025 08:20:52 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v14]
In-Reply-To: <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
Message-ID: <C2I-sV2qP8_mnlrgDjpio7KRUsDUmUBHGATufXk9250=.afbe0284-e126-4066-8cf1-84a85cc0aa4d@github.com>

On Sun, 27 Apr 2025 21:58: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 incrementally with one additional commit since the last revision:
> 
>   include guards

"frame_link" as a name looks better when inspecting the declaration, but in all usages it is redundant:

frame::link() vs frame::frame_link()

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

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

From mgronlun at openjdk.org  Tue Apr 29 09:20:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Apr 2025 09:20:47 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v14]
In-Reply-To: <OPkPMC-4FEOAlOt1LDEC7_SP2DxBYwBvpl-W_tqYw8g=.ebdf29cf-1327-44aa-8d23-3613e12e9d39@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
 <OPkPMC-4FEOAlOt1LDEC7_SP2DxBYwBvpl-W_tqYw8g=.ebdf29cf-1327-44aa-8d23-3613e12e9d39@github.com>
Message-ID: <NagMYeVwxCh1uObIFLz6aYLDsdxbPsH1BM61kdQLcS8=.c35ca519-9e87-4b87-86ed-a7fbe6e7b64f@github.com>

On Mon, 28 Apr 2025 21:23:04 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Ok for now. I have a version which has passed jtreg:test/jdk/jdk/jfr tests. Not sure if this is what we want, but feel free to pick it up if you want to repair PPC64: [PPC64_JFR.patch](https://github.com/user-attachments/files/19949028/PPC64_JFR.patch)

Thanks Martin.

I think it needs some additional work: please take a look at InterpreterMacroAssembler::remove_activation() and InterpreterMacroAssembler::call_VM_with_sender_Java_fp()

Can we let _last_sender_Java_fp be a state field that can be tested? You can see how it is tested in:

jfrSampleRequest.cpp

static bool build_from_ljf()

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

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

From mgronlun at openjdk.org  Tue Apr 29 16:47:17 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 29 Apr 2025 16:47:17 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
Message-ID: <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@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 incrementally with one additional commit since the last revision:

  Configuration and test for jdk.SafepointLatency event

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/24296/files
  - new: https://git.openjdk.org/jdk/pull/24296/files/c65bc8b6..b0f9c5e5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=13-14

  Stats: 82 lines in 4 files changed: 79 ins; 0 del; 3 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 mdoerr at openjdk.org  Wed Apr 30 13:53:49 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 30 Apr 2025 13:53:49 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v14]
In-Reply-To: <NagMYeVwxCh1uObIFLz6aYLDsdxbPsH1BM61kdQLcS8=.c35ca519-9e87-4b87-86ed-a7fbe6e7b64f@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <zl62IrP13ZQoT5Ja-ZHxKOm3SNootLbtEf6xcDNadQw=.0c7eed33-6711-48ef-9579-37e554d89d3e@github.com>
 <OPkPMC-4FEOAlOt1LDEC7_SP2DxBYwBvpl-W_tqYw8g=.ebdf29cf-1327-44aa-8d23-3613e12e9d39@github.com>
 <NagMYeVwxCh1uObIFLz6aYLDsdxbPsH1BM61kdQLcS8=.c35ca519-9e87-4b87-86ed-a7fbe6e7b64f@github.com>
Message-ID: <AI8yB_dU6eh-m39M8qetXAJ6FfZjZMsmhwWkLB8E5sQ=.9f325915-ce3c-4d8b-90ec-5353be39a0a1@github.com>

On Tue, 29 Apr 2025 09:17:40 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Can we let _last_sender_Java_fp be a state field that can be tested?

That is possible, but I don't see any effect. All JFR tests are already passing without that. Should `process_sender_Java_fp` be ever called on platforms which always have a valid Back Chain? I don't see anything which needs to be done for PPC64.
We could return nullptr in `last_sender_Java_fp()`. The tests still pass with that.

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

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

From mgronlun at openjdk.org  Wed Apr 30 17:05:49 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 30 Apr 2025 17:05:49 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
Message-ID: <A4oDXgAN7HZe4UTCZ5HzZvERVg1B47pCkoXH9oO74Yw=.5dad6c6d-e82e-44a9-86b0-16bf9702fa16@github.com>

On Tue, 29 Apr 2025 16:47:17 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 one additional commit since the last revision:
> 
>   Configuration and test for jdk.SafepointLatency event

The issue is that the CPU context can be retrieved here after the safepoint poll has been tested. That is causing a race, because a sample would be taken for an fp that is about to pop, breaking the invariant of the sampling mechanism.

It is only for some sensitive interpreter positions that we need to inspect the correct fp (the sender's fp), to avoid this race.

On x64, we signal that by preemptively moving rbp, first to update the CPU context and then by explicitly setting the sender_java_fp field in the LJF.

With your suggestion, we would always prioritize the sender fp (because it is always available), which is unnecessary and incorrect (biased), except for where we are about to pop an interpreter frame (but we can't decide when that is the case).

For testing, you will need to run some longer stress tests to see the effect of a racy sampling attempt.

To provoke taking more samples, you can decrease the sampling interval of JFR by setting the following in default.jfc and / or profile.jfc:

`diff --git a/src/jdk.jfr/share/conf/jfr/profile.jfc b/src/jdk.jfr/share/conf/jfr/profile.jfc
index 4c9f4b4f8ec..75f8d75c580 100644
--- a/src/jdk.jfr/share/conf/jfr/profile.jfc
+++ b/src/jdk.jfr/share/conf/jfr/profile.jfc
@@ -198,12 +198,12 @@

     <event name="jdk.ExecutionSample">
       <setting name="enabled" control="method-sampling-enabled">true</setting>
-      <setting name="period" control="method-sampling-java-interval">10 ms</setting>
+      <setting name="period" control="method-sampling-java-interval">1 ms</setting>
     </event>

     <event name="jdk.NativeMethodSample">
       <setting name="enabled" control="method-sampling-enabled">true</setting>
-      <setting name="period" control="method-sampling-native-interval">20 ms</setting>
+      <setting name="period" control="method-sampling-native-interval">1 ms</setting>
     </event>

     <event name="jdk.SafepointLatency">`
     
 Try running some longer stress test or benchmark, passing:
 
 `-XX:StartFlightRecording:settings=profile.jfc`

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

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

From mdoerr at openjdk.org  Wed Apr 30 22:34:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Wed, 30 Apr 2025 22:34:47 GMT
Subject: RFR: 8352251: Implement Cooperative JFR Sampling [v15]
In-Reply-To: <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
References: <2FEvWJYZrD5yRsmTCqrgR9Lit84szuFJxqwdpjghVog=.7deabc88-039f-423e-a4bd-e36399870273@github.com>
 <uMxg6kWwBwRPIAYDxZ1QXl134We8fzRD4o9ve0HEi9U=.3730cf21-5dc7-4cf6-956f-d29ce88e1671@github.com>
Message-ID: <LO5kM4uu10S0GcoVTHB66mx1aCtpTwlnAsDWVWBLc2Q=.7f2abe09-6d90-4de9-bab9-6c144e1b3c21@github.com>

On Tue, 29 Apr 2025 16:47:17 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 one additional commit since the last revision:
> 
>   Configuration and test for jdk.SafepointLatency event

Thanks for your explanation! I'll try some longer stress tests.

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

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