From liach at openjdk.org  Fri Jan  3 16:35:39 2025
From: liach at openjdk.org (Chen Liang)
Date: Fri, 3 Jan 2025 16:35:39 GMT
Subject: RFR: 8346981: Remove obsolete java.base exports of
 jdk.internal.objectweb.asm packages
In-Reply-To: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
References: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
Message-ID: <IUPoK4z3qPruSrNiIy6AmwgPi4aftXfm_4cfq8HwSWY=.ccff5955-652c-438b-92b2-ad9dbf479f59@github.com>

On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module.
> 
> Please review.
> 
> Thanks,
> Adam

Looks good; waiting for a JFR reviewer.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2529380039

From alanb at openjdk.org  Fri Jan  3 17:18:34 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 3 Jan 2025 17:18:34 GMT
Subject: RFR: 8346981: Remove obsolete java.base exports of
 jdk.internal.objectweb.asm packages
In-Reply-To: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
References: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
Message-ID: <0dGBK1WiJqZwu6ornKPZRv6GG4ZN_Qi_9ueqw0OBICM=.08113b29-4905-43f7-991e-d8b2378f11cf@github.com>

On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module.
> 
> Please review.
> 
> Thanks,
> Adam

Good cleanup, these qualified exports should probably have been removed in JDK 22 when the instrumentation moved to the class file API.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2529437512

From asotona at openjdk.org  Mon Jan  6 08:45:48 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Jan 2025 08:45:48 GMT
Subject: RFR: 8346981: Remove obsolete java.base exports of
 jdk.internal.objectweb.asm packages [v2]
In-Reply-To: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
References: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
Message-ID: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com>

> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  updated copyright year

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22912/files
  - new: https://git.openjdk.org/jdk/pull/22912/files/06ec27bf..f8fe6546

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

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

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

From alanb at openjdk.org  Mon Jan  6 08:48:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Jan 2025 08:48:38 GMT
Subject: RFR: 8346981: Remove obsolete java.base exports of
 jdk.internal.objectweb.asm packages [v2]
In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com>
References: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
 <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com>
Message-ID: <DqKgfyFcKwIGRJXSTKngvjlsL4kEN6VFxTIt44qrxgY=.621e79a1-5323-4e2b-ae1a-abae919adead@github.com>

On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2531645108

From qxing at openjdk.org  Mon Jan  6 09:50:43 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Mon, 6 Jan 2025 09:50:43 GMT
Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in
 `jfrTraceIdMacros.hpp`
Message-ID: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>

The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far.

This patch removes the extra parenthesis.

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

Commit messages:
 - Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp`.

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

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

From liach at openjdk.org  Mon Jan  6 14:10:46 2025
From: liach at openjdk.org (Chen Liang)
Date: Mon, 6 Jan 2025 14:10:46 GMT
Subject: RFR: 8346981: Remove obsolete java.base exports of
 jdk.internal.objectweb.asm packages [v2]
In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com>
References: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
 <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com>
Message-ID: <BfiAkOmQ-9UdEJtIPU34r_p_MBfr-bsYC8nArjq-8Bw=.25ce045d-c5e0-4970-b811-12651fdb327c@github.com>

On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

Marked as reviewed by liach (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22912#pullrequestreview-2532210782

From asotona at openjdk.org  Mon Jan  6 14:10:47 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Jan 2025 14:10:47 GMT
Subject: RFR: 8346981: Remove obsolete java.base exports of
 jdk.internal.objectweb.asm packages [v2]
In-Reply-To: <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com>
References: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
 <5dRe54IfgiyEWLhZvUf07Ak5BmVD0z-PsVLm25fpCBg=.f721416d-73a2-421f-a2db-1f2baec513b0@github.com>
Message-ID: <oCHERnrrTzMA4o9aB2tNVt1LvXIq7LVRpRXPYCwCmTg=.06d0669b-c56c-47b8-8820-eff36efcdfe9@github.com>

On Mon, 6 Jan 2025 08:45:48 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   updated copyright year

Thank you for the reviews.

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

PR Comment: https://git.openjdk.org/jdk/pull/22912#issuecomment-2573185292

From asotona at openjdk.org  Mon Jan  6 14:10:47 2025
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 6 Jan 2025 14:10:47 GMT
Subject: Integrated: 8346981: Remove obsolete java.base exports of
 jdk.internal.objectweb.asm packages
In-Reply-To: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
References: <vn-KL1G22LTqTZ6EaO6plm3WyVpBbV_lNGkYpNgvQXw=.b3ab32dc-0398-4af3-9aa9-fbf694e22495@github.com>
Message-ID: <a6f-qET_vlGY3R3jgQkKoRFFugAbpY_7vgkwLT4WKz0=.59d0a5f5-e10e-4637-bf27-7720cd87f2b1@github.com>

On Fri, 3 Jan 2025 12:06:05 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This PR removes obsolete java.base exports of jdk.internal.objectweb.asm packages to jdk.jfr module.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: e0695e0e
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e0695e0ef0dd1bfacbaac32edda055ba852a2421
Stats:     9 lines in 1 file changed: 0 ins; 8 del; 1 mod

8346981: Remove obsolete java.base exports of jdk.internal.objectweb.asm packages

Reviewed-by: liach, alanb

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

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

From mgronlun at openjdk.org  Tue Jan  7 11:10:35 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 7 Jan 2025 11:10:35 GMT
Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in
 `jfrTraceIdMacros.hpp`
In-Reply-To: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
References: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
Message-ID: <x_bhJrldErkH5vU1VXT7BUK-D8OqEpXxa8ilOflwjJI=.8fd447b8-07b3-4258-85f1-681bdf1a306f@github.com>

On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far.
> 
> This patch removes the extra parenthesis.

Looks good.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22925#pullrequestreview-2534047872

From mgronlun at openjdk.org  Tue Jan  7 16:23:35 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 7 Jan 2025 16:23:35 GMT
Subject: RFR: 8346099: JFR: Query for 'jfr view' can't handle wildcard with
 multiple event types
In-Reply-To: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com>
References: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com>
Message-ID: <JfE72lOtFykCsSbsOju6jZRe6kMPJOuNV1I9RkPsGA4=.f9665f0c-ab26-4063-9c7e-180da11c56fa@github.com>

On Thu, 12 Dec 2024 13:24:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that improves the query language for 'jfr view' so it can handle a wildcard with multiple event types, e.g. "SELECT * FROM E1, E2".
> 
> Every field has an index which corresponds to where it is located in resultFields array. Today, the same index can appear multiple times. See FieldBuilder::createWildcardField how this can happen when there are multiple event/filter types. The fix is to set the index after all fields have been added. 
> 
> Testing: jdk/jdk/jfr + manual check
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22711#pullrequestreview-2534838623

From mgronlun at openjdk.org  Tue Jan  7 16:23:40 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 7 Jan 2025 16:23:40 GMT
Subject: RFR: 8345337: JFR: jfr view should display all direct subfields
 for an event type
In-Reply-To: <pviCwb_kxKdR7TBphJ_IioiZiwzt7siee1la-cPUi44=.b3879217-2372-434f-9f4b-38579876133c@github.com>
References: <pviCwb_kxKdR7TBphJ_IioiZiwzt7siee1la-cPUi44=.b3879217-2372-434f-9f4b-38579876133c@github.com>
Message-ID: <69ySkh1CPfHZRzC63yjaUhrj_qfckd4lprJF4Hvpc8o=.a7cd6e22-155b-46ae-babd-86ed1a04c8ac@github.com>

On Mon, 2 Dec 2024 21:02:20 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes an issue when displaying subfields with 'jfr view'
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22498#pullrequestreview-2534836008

From mgronlun at openjdk.org  Tue Jan  7 16:24:56 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 7 Jan 2025 16:24:56 GMT
Subject: RFR: 8346047: JFR: Incorrect percentile value in 'jfr view'
In-Reply-To: <c8y5w-zD9vd1QTxevbMb0l2i48Ih67kIZeaaK1uAUQc=.9ca235af-bd7f-4494-869e-25d177f01a4a@github.com>
References: <c8y5w-zD9vd1QTxevbMb0l2i48Ih67kIZeaaK1uAUQc=.9ca235af-bd7f-4494-869e-25d177f01a4a@github.com>
Message-ID: <c-aHXKRpd8SCQDKFBTQQZRkUEXURH6ZMYnS3fcdC2RY=.afebd452-0f6c-4e3d-992b-9c388e2d2a86@github.com>

On Thu, 12 Dec 2024 03:41:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes an issue with 'jfr view' when calculating the percentile.
> 
> It would be possible to create a separate variable for the truncated doubleIndex, but I think this is easier to read than introducing a fourth index variable.
> 
> Testing: jdk/jdk/rf
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22700#pullrequestreview-2534843231

From mgronlun at openjdk.org  Tue Jan  7 16:24:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 7 Jan 2025 16:24:48 GMT
Subject: RFR: 8346052: JFR: Incorrect average value in 'jfr view'
In-Reply-To: <beF0-KIfR1j6MRKMhOAc35ewpRHAFe1HyTQtutROBmw=.e34a181b-8849-4467-8f14-593cda70d0d4@github.com>
References: <beF0-KIfR1j6MRKMhOAc35ewpRHAFe1HyTQtutROBmw=.e34a181b-8849-4467-8f14-593cda70d0d4@github.com>
Message-ID: <vgpqm4TeqIsyr069BiPzg4BFKZyDrea2cedxrSP5V-w=.e9b5ee39-9cef-43fe-ab9d-f4f730816b0e@github.com>

On Thu, 12 Dec 2024 03:38:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes an issue with 'jfr view' when calculating the average for a timespan.
> 
> Testing: jdk/jdk/rf
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22699#pullrequestreview-2534841197

From egahlin at openjdk.org  Wed Jan  8 12:47:50 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Jan 2025 12:47:50 GMT
Subject: Integrated: 8345337: JFR: jfr view should display all direct subfields
 for an event type
In-Reply-To: <pviCwb_kxKdR7TBphJ_IioiZiwzt7siee1la-cPUi44=.b3879217-2372-434f-9f4b-38579876133c@github.com>
References: <pviCwb_kxKdR7TBphJ_IioiZiwzt7siee1la-cPUi44=.b3879217-2372-434f-9f4b-38579876133c@github.com>
Message-ID: <0bWjuStOo74SM0DDdsx6U_k33WZJAGllD0QoM8Wu7N0=.04be0621-7be3-4b0c-a830-e8d3f0f883d3@github.com>

On Mon, 2 Dec 2024 21:02:20 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes an issue when displaying subfields with 'jfr view'
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 672c413c
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/672c413c61d9b155020a0fd4bd1c2bc0661a60fb
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8345337: JFR: jfr view should display all direct subfields for an event type

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Wed Jan  8 14:42:40 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Jan 2025 14:42:40 GMT
Subject: Integrated: 8346052: JFR: Incorrect average value in 'jfr view'
In-Reply-To: <beF0-KIfR1j6MRKMhOAc35ewpRHAFe1HyTQtutROBmw=.e34a181b-8849-4467-8f14-593cda70d0d4@github.com>
References: <beF0-KIfR1j6MRKMhOAc35ewpRHAFe1HyTQtutROBmw=.e34a181b-8849-4467-8f14-593cda70d0d4@github.com>
Message-ID: <AStPwaq92dov9GuJr2aAe34Fw5P2JrdYzMIOTifGcxU=.60fe7db0-c3b8-470c-8bfe-a76a847e0855@github.com>

On Thu, 12 Dec 2024 03:38:25 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes an issue with 'jfr view' when calculating the average for a timespan.
> 
> Testing: jdk/jdk/rf
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 92ad8a1d
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/92ad8a1d96c749d1f9c15e5b96244cd72a6e71be
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8346052: JFR: Incorrect average value in 'jfr view'

Reviewed-by: mgronlun

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

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

From alanb at openjdk.org  Wed Jan  8 14:45:38 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Jan 2025 14:45:38 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime
In-Reply-To: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
Message-ID: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com>

On Wed, 8 Jan 2025 14:24:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
> 
> Testing:
> - [ ] GHA
> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
> 
> Thoughts?

test/jdk/tools/launcher/SourceMode.java line 29:

> 27:  * @summary Test source mode
> 28:  * @modules jdk.compiler jdk.jlink
> 29:  * @run main/othervm SourceMode

This looks fine, might need to add `@comment` to something brief to say why the test are othervm. Also I assume you'll bump the copyright header on the tests before ingtegrating.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22969#discussion_r1907293028

From sgehwolf at openjdk.org  Wed Jan  8 14:56:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 8 Jan 2025 14:56:55 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]
In-Reply-To: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
Message-ID: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>

> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
> 
> Testing:
> - [ ] GHA
> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Copyright and @comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22969/files
  - new: https://git.openjdk.org/jdk/pull/22969/files/afc33798..6eceb0de

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

  Stats: 6 lines in 2 files changed: 4 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22969/head:pull/22969

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

From sgehwolf at openjdk.org  Wed Jan  8 14:56:56 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 8 Jan 2025 14:56:56 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]
In-Reply-To: <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <71GPtLC49kpW3mF0Hv4JE5zTPpd8-S_PEuPf-RFGbh0=.50372f60-c569-4d44-9bee-44b920666b12@github.com>
Message-ID: <N9c6cEVbUri5ipEs0bph-i6UqlU11YCBTn9g9S_DyE4=.fbfdb38b-967f-48cc-8d5f-e633ada07576@github.com>

On Wed, 8 Jan 2025 14:42:45 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright and @comment
>
> test/jdk/tools/launcher/SourceMode.java line 29:
> 
>> 27:  * @summary Test source mode
>> 28:  * @modules jdk.compiler jdk.jlink
>> 29:  * @run main/othervm SourceMode
> 
> This looks fine, might need to add `@comment` to something brief to say why the test are othervm. Also I assume you'll bump the copyright header on the tests before ingtegrating.

Thanks. `@comment` added and copyright header updated.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22969#discussion_r1907309808

From alanb at openjdk.org  Wed Jan  8 15:17:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 8 Jan 2025 15:17:47 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]
In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
Message-ID: <MlNZSKz-w0SBwjFrLCMBwnXowaRQP5Elpj8BHkZXmgM=.d9649f02-8948-4dfe-99b1-e057b7a6dae4@github.com>

On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
>> 
>> Testing:
>> - [ ] GHA
>> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright and @comment

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2537439865

From egahlin at openjdk.org  Wed Jan  8 15:55:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Jan 2025 15:55:55 GMT
Subject: Integrated: 8346047: JFR: Incorrect percentile value in 'jfr view'
In-Reply-To: <c8y5w-zD9vd1QTxevbMb0l2i48Ih67kIZeaaK1uAUQc=.9ca235af-bd7f-4494-869e-25d177f01a4a@github.com>
References: <c8y5w-zD9vd1QTxevbMb0l2i48Ih67kIZeaaK1uAUQc=.9ca235af-bd7f-4494-869e-25d177f01a4a@github.com>
Message-ID: <DShdBKqjZ1ptzD7aKTIkecl5pxaU5FRcH7TxZKapOBQ=.76b1642b-81e3-4e47-bac9-881c8b982e3a@github.com>

On Thu, 12 Dec 2024 03:41:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that fixes an issue with 'jfr view' when calculating the percentile.
> 
> It would be possible to create a separate variable for the truncated doubleIndex, but I think this is easier to read than introducing a fourth index variable.
> 
> Testing: jdk/jdk/rf
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 55bcf4c0
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/55bcf4c054c95af2a073818cd8c392de02b3ee01
Stats:     2 lines in 1 file changed: 0 ins; 0 del; 2 mod

8346047: JFR: Incorrect percentile value in 'jfr view'

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Wed Jan  8 16:07:32 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 8 Jan 2025 16:07:32 GMT
Subject: Integrated: 8346099: JFR: Query for 'jfr view' can't handle wildcard
 with multiple event types
In-Reply-To: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com>
References: <9kt8FEHCxEa-iIbj6xUYMbzG8h68OLf2X2YUuXKcVxY=.67c91a8e-155b-430d-a8d4-1c00196bce0c@github.com>
Message-ID: <ODVXB2W_6kCs6A6CKzbwUu6Z7ADO8WxUmtX4VIXbBSw=.f45d6583-71e3-48ec-812c-3797ebe30af2@github.com>

On Thu, 12 Dec 2024 13:24:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that improves the query language for 'jfr view' so it can handle a wildcard with multiple event types, e.g. "SELECT * FROM E1, E2".
> 
> Every field has an index which corresponds to where it is located in resultFields array. Today, the same index can appear multiple times. See FieldBuilder::createWildcardField how this can happen when there are multiple event/filter types. The fix is to set the index after all fields have been added. 
> 
> Testing: jdk/jdk/jfr + manual check
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 3fe08186
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3fe08186b1d6dbc17d4f14d8288ce3c7c6651004
Stats:     10 lines in 2 files changed: 8 ins; 2 del; 0 mod

8346099: JFR: Query for 'jfr view' can't handle wildcard with multiple event types

Reviewed-by: mgronlun

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

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

From fyang at openjdk.org  Thu Jan  9 00:50:41 2025
From: fyang at openjdk.org (Fei Yang)
Date: Thu, 9 Jan 2025 00:50:41 GMT
Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in
 `jfrTraceIdMacros.hpp`
In-Reply-To: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
References: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
Message-ID: <tb42zHbvye2lKCnpHdTQBLVB8Nx3GBbGKYf0Lt8syaM=.94287cb6-740b-4aa4-88f3-03659791779d@github.com>

On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far.
> 
> This patch removes the extra parenthesis.

LGTM.

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

Marked as reviewed by fyang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22925#pullrequestreview-2538566352

From qxing at openjdk.org  Thu Jan  9 01:06:54 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Thu, 9 Jan 2025 01:06:54 GMT
Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in
 `jfrTraceIdMacros.hpp`
In-Reply-To: <x_bhJrldErkH5vU1VXT7BUK-D8OqEpXxa8ilOflwjJI=.8fd447b8-07b3-4258-85f1-681bdf1a306f@github.com>
References: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
 <x_bhJrldErkH5vU1VXT7BUK-D8OqEpXxa8ilOflwjJI=.8fd447b8-07b3-4258-85f1-681bdf1a306f@github.com>
Message-ID: <0P1Ci3tn2o85Ca_giEJbHBg9rQjhtVv05dGFqNEPsIg=.0e3fae0a-39d2-4e8e-a22e-b0c4d0d3a3c0@github.com>

On Tue, 7 Jan 2025 11:08:16 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far.
>> 
>> This patch removes the extra parenthesis.
>
> Looks good.

@mgronlun @RealFYang Thanks for the review!

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

PR Comment: https://git.openjdk.org/jdk/pull/22925#issuecomment-2578987696

From duke at openjdk.org  Thu Jan  9 01:06:54 2025
From: duke at openjdk.org (duke)
Date: Thu, 9 Jan 2025 01:06:54 GMT
Subject: RFR: 8347042: Remove an extra parenthesis in macro definition in
 `jfrTraceIdMacros.hpp`
In-Reply-To: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
References: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
Message-ID: <JoAHZbN2GksDCOetsminu6maReSHi0A6zxnhjceGIIM=.4beed308-fd41-4a70-b38b-52d63ed4f6a0@github.com>

On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far.
> 
> This patch removes the extra parenthesis.

@MaxXSoft 
Your change (at version f25196d706e00e09e734dd560ad0fc0920e6e373) is now ready to be sponsored by a Committer.

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

PR Comment: https://git.openjdk.org/jdk/pull/22925#issuecomment-2578988037

From qxing at openjdk.org  Thu Jan  9 02:27:41 2025
From: qxing at openjdk.org (Qizheng Xing)
Date: Thu, 9 Jan 2025 02:27:41 GMT
Subject: Integrated: 8347042: Remove an extra parenthesis in macro definition
 in `jfrTraceIdMacros.hpp`
In-Reply-To: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
References: <JCVRwTC2NbvFkF9U8ewOQ6C_n09_rut9WGoroUBa_Rg=.24f0b72a-6e3c-4392-a1a4-21779f9f3224@github.com>
Message-ID: <_5YVueTh9_6CLv5VEtQUJzrm1GdLFj3CJIMArr49O9g=.7a7b9a6c-531c-4935-afd2-3296c89d1ad7@github.com>

On Mon, 6 Jan 2025 09:46:24 GMT, Qizheng Xing <qxing at openjdk.org> wrote:

> The macro definition `METHOD_USED_ANY_EPOCH` in `jfrTraceIdMacros.hpp` has an extra parenthesis, which was introduced in JDK-8233705. But there seems to be no code using this macro, so there are no related build failures so far.
> 
> This patch removes the extra parenthesis.

This pull request has now been integrated.

Changeset: 1ade96b8
Author:    Qizheng Xing <qxing at openjdk.org>
Committer: Fei Yang <fyang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1ade96b808e66cf1623c38e23772eaf9fc991db9
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8347042: Remove an extra parenthesis in macro definition in `jfrTraceIdMacros.hpp`

Reviewed-by: mgronlun, fyang

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

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

From dholmes at openjdk.org  Thu Jan  9 03:41:36 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 9 Jan 2025 03:41:36 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]
In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
Message-ID: <KMQueAO8vQhnz8bXb4-4RBwdhfbnGFJA8T6V_c3nkvc=.43b7b5be-d5a5-447b-9ec8-4ad2ee93a2d3@github.com>

On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
>> 
>> Testing:
>> - [ ] GHA
>> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright and @comment

Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise?

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

PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2538683215

From alanb at openjdk.org  Thu Jan  9 08:29:36 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 9 Jan 2025 08:29:36 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]
In-Reply-To: <KMQueAO8vQhnz8bXb4-4RBwdhfbnGFJA8T6V_c3nkvc=.43b7b5be-d5a5-447b-9ec8-4ad2ee93a2d3@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
 <KMQueAO8vQhnz8bXb4-4RBwdhfbnGFJA8T6V_c3nkvc=.43b7b5be-d5a5-447b-9ec8-4ad2ee93a2d3@github.com>
Message-ID: <A6Nq3Hq5hlEQcvOMGemvkFLZavsMrhzEPkiglOPwoLo=.b869f45d-8da3-4e29-80f6-639e59d2b3f6@github.com>

On Thu, 9 Jan 2025 03:38:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise?

jtreg patches java.base to add JTRegModuleHelper so not compatible that uses that using jlink "in-process" (with ToolProvider). Maybe the `@comment` could be expanded a bit to say this.

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

PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2579429178

From sgehwolf at openjdk.org  Thu Jan  9 10:18:35 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Jan 2025 10:18:35 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3]
In-Reply-To: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
Message-ID: <FsfdnhQ-QAxHUTtU194sI_wtB6oE3UdiB8oqgrLWIV0=.df55f2a9-ea4e-4d40-b2e3-5cdcea668ebb@github.com>

> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
> 
> Testing:
> - [x] GHA
> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
> 
> Thoughts?

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Expand comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22969/files
  - new: https://git.openjdk.org/jdk/pull/22969/files/6eceb0de..77dc9376

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

  Stats: 8 lines in 2 files changed: 6 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22969.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22969/head:pull/22969

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

From sgehwolf at openjdk.org  Thu Jan  9 10:18:37 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Jan 2025 10:18:37 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]
In-Reply-To: <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
Message-ID: <fnOUwnaVn0QroV4NabItngllZmUxXyYic-s8kacgsSA=.c9dae33b-1f7e-4a6e-b660-eb199b3ee10a@github.com>

On Wed, 8 Jan 2025 14:56:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
>> 
>> Testing:
>> - [x] GHA
>> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright and @comment

I've updated the `@comment` to explain this better. Is it clearer now?

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

PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2579692209

From shade at openjdk.org  Thu Jan  9 10:20:38 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 9 Jan 2025 10:20:38 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3]
In-Reply-To: <FsfdnhQ-QAxHUTtU194sI_wtB6oE3UdiB8oqgrLWIV0=.df55f2a9-ea4e-4d40-b2e3-5cdcea668ebb@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <FsfdnhQ-QAxHUTtU194sI_wtB6oE3UdiB8oqgrLWIV0=.df55f2a9-ea4e-4d40-b2e3-5cdcea668ebb@github.com>
Message-ID: <TSSxGWmUsXxMaqqUo6vfA3UapDuNEOa4uSzeW_sSBIA=.eb9ad0b9-3c1a-47ff-9747-c051ba4488c7@github.com>

On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
>> 
>> Testing:
>> - [x] GHA
>> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand comment

Looks fine to me.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22969#pullrequestreview-2539455608

From egahlin at openjdk.org  Thu Jan  9 13:18:00 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 Jan 2025 13:18:00 GMT
Subject: RFR: 8347287: JFR: Remove use of Security Manager
Message-ID: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>

Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. 

Testing: tier1 + test/jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Update copyright
 - Update specification in seperate issue
 - Remove mistakenly added directory
 - Fix copyright year
 - Remove whitespace
 - Remove whitespace
 - Update copyright to 2025
 - Initial

Changes: https://git.openjdk.org/jdk/pull/22787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22787&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8347287
  Stats: 1986 lines in 86 files changed: 197 ins; 1380 del; 409 mod
  Patch: https://git.openjdk.org/jdk/pull/22787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22787/head:pull/22787

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

From mgronlun at openjdk.org  Thu Jan  9 13:18:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Jan 2025 13:18:00 GMT
Subject: RFR: 8347287: JFR: Remove use of Security Manager
In-Reply-To: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
References: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
Message-ID: <dnEk7L-HQBpzdspwNn8k31z6L1o0zJkuychwR76lHBU=.7bef925b-2d49-4191-b9b1-277dae820050@github.com>

On Tue, 17 Dec 2024 09:25:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. 
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22787#pullrequestreview-2539866422

From sgehwolf at openjdk.org  Thu Jan  9 13:54:40 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 9 Jan 2025 13:54:40 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v2]
In-Reply-To: <KMQueAO8vQhnz8bXb4-4RBwdhfbnGFJA8T6V_c3nkvc=.43b7b5be-d5a5-447b-9ec8-4ad2ee93a2d3@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <3bcgnWkWpHH1-80W7vj2ffjqbP35xUeWJOBKYJrT4mQ=.01528110-d298-483c-a0d2-4f2e1cd2e1c4@github.com>
 <KMQueAO8vQhnz8bXb4-4RBwdhfbnGFJA8T6V_c3nkvc=.43b7b5be-d5a5-447b-9ec8-4ad2ee93a2d3@github.com>
Message-ID: <iQplFyxPsZHHTFHs2lhfnzFGk6RJJsUJY-Vdcc8M8xw=.523913bf-7ba9-45af-aed1-b7a324c07bec@github.com>

On Thu, 9 Jan 2025 03:38:48 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Copyright and @comment
>
> Pardon my ignorance, but in neither of these tests is it evident to me that "patched modules" are being used. Where does that arise?

@dholmes-ora Is the latest patch any better?

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

PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2580239188

From egahlin at openjdk.org  Thu Jan  9 15:02:47 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 9 Jan 2025 15:02:47 GMT
Subject: [jdk24] RFR: 8345337: JFR: jfr view should display all direct
 subfields for an event type
Message-ID: <PglNifhtwdgvDiKEWZyMnss5pO3iYf4qCYVY6g8bJdY=.66f4abc1-d519-455d-b660-e0e085b4e0be@github.com>

8345337: JFR: jfr view should display all direct subfields for an event type

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

Commit messages:
 - Backport 672c413c61d9b155020a0fd4bd1c2bc0661a60fb

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

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

From mgronlun at openjdk.org  Thu Jan  9 15:02:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 9 Jan 2025 15:02:47 GMT
Subject: [jdk24] RFR: 8345337: JFR: jfr view should display all direct
 subfields for an event type
In-Reply-To: <PglNifhtwdgvDiKEWZyMnss5pO3iYf4qCYVY6g8bJdY=.66f4abc1-d519-455d-b660-e0e085b4e0be@github.com>
References: <PglNifhtwdgvDiKEWZyMnss5pO3iYf4qCYVY6g8bJdY=.66f4abc1-d519-455d-b660-e0e085b4e0be@github.com>
Message-ID: <xfgYzYOJyUyNQsQSLdhjRBQ2cNjHjc9FKceq7lCuY5c=.9ae35be1-f175-4f07-ba20-8f7bbc831e2a@github.com>

On Thu, 9 Jan 2025 14:52:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8345337: JFR: jfr view should display all direct subfields for an event type

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23009#pullrequestreview-2540156159

From erik.gahlin at oracle.com  Thu Jan  9 18:23:25 2025
From: erik.gahlin at oracle.com (Erik Gahlin)
Date: Thu, 9 Jan 2025 18:23:25 +0000
Subject: Socket Read event always reads 5B on jdk 23.0.1+11
In-Reply-To: <CAHjY6CUwthaBi3Ay_M5+C1yOPMLHd+cvdQ70j1LxJPw0GXE=Jg@mail.gmail.com>
References: <CAHjY6CUwthaBi3Ay_M5+C1yOPMLHd+cvdQ70j1LxJPw0GXE=Jg@mail.gmail.com>
Message-ID: <DS7PR10MB5118D2151234E08328326EA99D132@DS7PR10MB5118.namprd10.prod.outlook.com>

Hi Steven,

There were changes to the Socket Read event in JDK 22 and JDK 23. I have looked at the implementation again, but it seems fine. Can you reproduce on JDK 21?

Only events that take more than 20 ms are written, which might explain why some events are missing? You can enable all Socket Read events with the following command:

  $ java -XX:StartFlightRecording:jdk.SocketRead#threshold=0ms,filename=rec.jfr ...

This might provide you with greater insight.

Without a standalone reproducer, it's hard to say much more. Our tests of the Socket Read event work, but they do not test the duration because it's hard to do in a quick and reliable way.

https://github.com/openjdk/jdk/tree/master/test/jdk/jdk/jfr/event/io

Thanks
Erik
________________________________
From: hotspot-jfr-dev <hotspot-jfr-dev-retn at openjdk.org> on behalf of Steven Schlansker <stevenschlansker at gmail.com>
Sent: Tuesday, December 17, 2024 8:08 PM
To: hotspot-jfr-dev at openjdk.org <hotspot-jfr-dev at openjdk.org>
Subject: Socket Read event always reads 5B on jdk 23.0.1+11

Hi hotspot-jfr-dev,

I am trying to track down a problem with long db queries - Java
reports 10s, but the database server says the query only took 100ms.

In the flight recording, I look up the Socket Read events and indeed
find my suspiciously long read event. However, the event reports that
only 5B are read, which is hard to believe. In fact, *every* socket
read event reports exactly 5B read. This seems impossible - the server
builds a 45MB response body, and all the data comes from the database.

Should I expect that the socket read event reliably reports Bytes
Read? I don't believe this socket stream uses asynchronous IO, which
doesn't seem to be recorded at all (bummer!)
I tried to read the Socket$SocketInputStream Java code but the
instrumentation seems to happen due to much deeper magic.

We run openjdk 23.0.1+11 on rockylinux 9.5

Example event log, subset:
Start Time    Duration    End Time    Event Thread    Remote Address
 Bytes Read    End of Stream    Remote Host    Remote Port    Timeout
Value    Event Type Id
1734454183069711840 epochns    24210111038 ticks
3815799226963477504 epochticks    company-server-56    10.28.224.20
5 B    false    wsdb    5432    0 ms    jdk.SocketRead
1734454183748414110 epochns    20222774822 ticks
3815799224469286400 epochticks    company-server-39    10.28.224.20
5 B    false    wsdb    5432    0 ms    jdk.SocketRead
1734454590578194253 epochns    4759793838 ticks    3815800104031821312
epochticks    company-server-59    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454441187707733 epochns    4751996960 ticks    3815799775364954112
epochticks    company-server-42    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454425227497984 epochns    4120098692 ticks    3815799739620594688
epochticks    company-server-39    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454241790648566 epochns    1079527886 ticks    3815799333018955264
epochticks    company-server-55    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454590289810962 epochns    884150534 ticks    3815800099521735168
epochticks    company-server-47    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead
1734454649681226560 epochns    757929740 ticks    3815800230056628736
epochticks    company-server-47    10.28.224.20    5 B    false
wsdb    5432    0 ms    jdk.SocketRead


An example stack trace for one of the events:
void jdk.internal.event.SocketReadEvent.emit(long, long, long,
SocketAddress, long)
int java.net.Socket$SocketInputStream.read(byte[], int, int)
int sun.security.ssl.SSLSocketInputRecord.read(InputStream, byte[], int, int)
int sun.security.ssl.SSLSocketInputRecord.readHeader()
int sun.security.ssl.SSLSocketInputRecord.bytesInCompletePacket()
ByteBuffer sun.security.ssl.SSLSocketImpl.readApplicationRecord(ByteBuffer)
int sun.security.ssl.SSLSocketImpl$AppInputStream.read(byte[], int, int)
boolean org.postgresql.core.VisibleBufferedInputStream.readMore(int, boolean)
boolean org.postgresql.core.VisibleBufferedInputStream.ensureBytes(int, boolean)
boolean org.postgresql.core.VisibleBufferedInputStream.ensureBytes(int)
int org.postgresql.core.VisibleBufferedInputStream.read()
int org.postgresql.core.PGStream.receiveChar()
void org.postgresql.core.v3.QueryExecutorImpl.processResults(ResultHandler,
int, boolean)
void org.postgresql.core.v3.QueryExecutorImpl.execute(Query,
ParameterList, ResultHandler, int, int, int, boolean)
void org.postgresql.jdbc.PgStatement.executeInternal(CachedQuery,
ParameterList, int)
void org.postgresql.jdbc.PgStatement.execute(CachedQuery, ParameterList, int)
boolean org.postgresql.jdbc.PgPreparedStatement.executeWithFlags(int)
boolean org.postgresql.jdbc.PgPreparedStatement.execute()
boolean com.zaxxer.hikari.pool.ProxyPreparedStatement.execute()
boolean com.zaxxer.hikari.pool.HikariProxyPreparedStatement.execute()

Thank you for any insight - happy to provide more information if possible.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/hotspot-jfr-dev/attachments/20250109/61cd14a6/attachment-0001.htm>

From sgehwolf at openjdk.org  Fri Jan 10 10:09:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Jan 2025 10:09:51 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3]
In-Reply-To: <FsfdnhQ-QAxHUTtU194sI_wtB6oE3UdiB8oqgrLWIV0=.df55f2a9-ea4e-4d40-b2e3-5cdcea668ebb@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <FsfdnhQ-QAxHUTtU194sI_wtB6oE3UdiB8oqgrLWIV0=.df55f2a9-ea4e-4d40-b2e3-5cdcea668ebb@github.com>
Message-ID: <fKopGPo-0yCzRwtWfsRWNHXN1EJkcqzH7mL6rh0T-ME=.4712b891-d797-4c4d-89a9-c5984b2d65e9@github.com>

On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
>> 
>> Testing:
>> - [x] GHA
>> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand comment

This is a test-only fix and fairly trivial. I'll integrate now. Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2582265348

From sgehwolf at openjdk.org  Fri Jan 10 10:09:51 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 10 Jan 2025 10:09:51 GMT
Subject: Integrated: 8347124: Clean tests with --enable-linkable-runtime
In-Reply-To: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
Message-ID: <XEEdd1i3ETXAJGg-YstExPDjKj4KHfdKIYC9ZE-aOQg=.ab970da6-99b2-4fc9-bc02-3f34f70abc2d@github.com>

On Wed, 8 Jan 2025 14:24:25 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
> 
> Testing:
> - [x] GHA
> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 1f457977
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f457977f062e4ed219c6fa0fe26cb42acaf4bf2
Stats:     14 lines in 2 files changed: 10 ins; 0 del; 4 mod

8347124: Clean tests with --enable-linkable-runtime

Reviewed-by: shade, alanb

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

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

From aturbanov at openjdk.org  Fri Jan 10 10:44:39 2025
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 10 Jan 2025 10:44:39 GMT
Subject: RFR: 8347287: JFR: Remove use of Security Manager
In-Reply-To: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
References: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
Message-ID: <8KnWIHZTp36bAPwl9jX31tvkhK6_7D2o0XAku5Zj23w=.76c01f87-bf17-4374-9a2c-58c0f29a90e2@github.com>

On Tue, 17 Dec 2024 09:25:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. 
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java line 114:

> 112:                         + MAXIMUM_FILE_SIZE + " characters can't be read.");
> 113:             }
> 114:             try (InputStream r = Files.newInputStream(knownPath);) {

Suggestion:

            try (InputStream r = Files.newInputStream(knownPath)) {

src/jdk.jfr/share/classes/jdk/jfr/internal/jfc/JFC.java line 198:

> 196:                 Path file = path.resolveSibling(name + extension);
> 197:                 if (Files.exists(file) && !Files.isDirectory(file)) {
> 198:                     try (Reader r = Files.newBufferedReader(file);) {

Suggestion:

                    try (Reader r = Files.newBufferedReader(file)) {

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

PR Review Comment: https://git.openjdk.org/jdk/pull/22787#discussion_r1910190020
PR Review Comment: https://git.openjdk.org/jdk/pull/22787#discussion_r1910190392

From egahlin at openjdk.org  Fri Jan 10 13:46:52 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 10 Jan 2025 13:46:52 GMT
Subject: RFR: 8347287: JFR: Remove use of Security Manager [v2]
In-Reply-To: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
References: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
Message-ID: <tf6njkySMh_bJXtGNt7D8xnf3lxasXQ3tAYdPoyedVs=.ceb3e9ef-74dd-4bce-981c-a6c016362e89@github.com>

> Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. 
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

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

  Nit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/22787/files
  - new: https://git.openjdk.org/jdk/pull/22787/files/d3cae681..edcbb62f

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

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

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

From mgronlun at openjdk.org  Fri Jan 10 13:46:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Jan 2025 13:46:52 GMT
Subject: RFR: 8347287: JFR: Remove use of Security Manager [v2]
In-Reply-To: <tf6njkySMh_bJXtGNt7D8xnf3lxasXQ3tAYdPoyedVs=.ceb3e9ef-74dd-4bce-981c-a6c016362e89@github.com>
References: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
 <tf6njkySMh_bJXtGNt7D8xnf3lxasXQ3tAYdPoyedVs=.ceb3e9ef-74dd-4bce-981c-a6c016362e89@github.com>
Message-ID: <AQ9htO667ew6j_4dGiZBgFXez48P0k64zFsPoB0XByw=.59cd1cc2-e839-4064-8c25-eb361f36b925@github.com>

On Fri, 10 Jan 2025 13:43:10 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. 
>> 
>> Testing: tier1 + test/jdk/jdk/jfr
>> 
>> Thanks
>> Erik
>
> Erik Gahlin has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Nit

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/22787#pullrequestreview-2542469818

From egahlin at openjdk.org  Fri Jan 10 13:49:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 10 Jan 2025 13:49:49 GMT
Subject: Integrated: 8347287: JFR: Remove use of Security Manager
In-Reply-To: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
References: <TQNJ9Ho3Xr_3UHvL9EtJgKPwOtRLLl7ABRCsmTZYXIA=.7029012b-2615-412c-8496-4250e7dde66d@github.com>
Message-ID: <2ca-VF4ZRxnyHz-uiIuvsFdnOSjOggowahHxuaxfO3A=.87091826-fcc2-40d2-ac83-516fbaa78586@github.com>

On Tue, 17 Dec 2024 09:25:17 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of PR that removes Java related code not needed when the Security Manager is disabled. 
> 
> Testing: tier1 + test/jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: ec7393e9
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ec7393e9190c1b93ca08e1107f734c869f400b89
Stats:     1986 lines in 86 files changed: 197 ins; 1380 del; 409 mod

8347287: JFR: Remove use of Security Manager

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Fri Jan 10 13:54:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 10 Jan 2025 13:54:45 GMT
Subject: [jdk24] Integrated: 8345337: JFR: jfr view should display all direct
 subfields for an event type
In-Reply-To: <PglNifhtwdgvDiKEWZyMnss5pO3iYf4qCYVY6g8bJdY=.66f4abc1-d519-455d-b660-e0e085b4e0be@github.com>
References: <PglNifhtwdgvDiKEWZyMnss5pO3iYf4qCYVY6g8bJdY=.66f4abc1-d519-455d-b660-e0e085b4e0be@github.com>
Message-ID: <AvaXrP19NRy52Yaw9vF2SJrTHNji9OsuMwlqOfzz7Bk=.bb956e0f-5228-4268-991e-08a09106b07e@github.com>

On Thu, 9 Jan 2025 14:52:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8345337: JFR: jfr view should display all direct subfields for an event type

This pull request has now been integrated.

Changeset: c61fbfd6
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c61fbfd6ea0e2b91a0321b6b6cd382f710d0deef
Stats:     4 lines in 1 file changed: 1 ins; 0 del; 3 mod

8345337: JFR: jfr view should display all direct subfields for an event type

Reviewed-by: mgronlun
Backport-of: 672c413c61d9b155020a0fd4bd1c2bc0661a60fb

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

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

From egahlin at openjdk.org  Fri Jan 10 14:00:23 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 10 Jan 2025 14:00:23 GMT
Subject: RFR: 8343510: JFR: Remove AccessControlContext from
 FlightRecorder::addListener specification
Message-ID: <eVdl2GDtnb6HIndLv4Md27NaswkQxNdG1ksKpYAIuzU=.148bb51c-b8e8-42c4-a340-224e8ba03ec6@github.com>

Could I have a review that updates the specification for FlightRecorder::addListener to reflect that the Security Manager is now disabled. 

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Fri Jan 10 14:00:23 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Jan 2025 14:00:23 GMT
Subject: RFR: 8343510: JFR: Remove AccessControlContext from
 FlightRecorder::addListener specification
In-Reply-To: <eVdl2GDtnb6HIndLv4Md27NaswkQxNdG1ksKpYAIuzU=.148bb51c-b8e8-42c4-a340-224e8ba03ec6@github.com>
References: <eVdl2GDtnb6HIndLv4Md27NaswkQxNdG1ksKpYAIuzU=.148bb51c-b8e8-42c4-a340-224e8ba03ec6@github.com>
Message-ID: <o3-vSrhj6VowCd1_IJavcCiVkVXMqYQEMIbOVSaQPTE=.08a63bb8-2330-47e6-bbcb-6c5bbfeda707@github.com>

On Thu, 9 Jan 2025 13:45:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review that updates the specification for FlightRecorder::addListener to reflect that the Security Manager is now disabled. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23006#pullrequestreview-2542496694

From egahlin at openjdk.org  Fri Jan 10 16:01:55 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 10 Jan 2025 16:01:55 GMT
Subject: Integrated: 8343510: JFR: Remove AccessControlContext from
 FlightRecorder::addListener specification
In-Reply-To: <eVdl2GDtnb6HIndLv4Md27NaswkQxNdG1ksKpYAIuzU=.148bb51c-b8e8-42c4-a340-224e8ba03ec6@github.com>
References: <eVdl2GDtnb6HIndLv4Md27NaswkQxNdG1ksKpYAIuzU=.148bb51c-b8e8-42c4-a340-224e8ba03ec6@github.com>
Message-ID: <E_Z6k8XKbW8CKSyMGZBQdbi7MpbS4KmNRiYKTlpKHjE=.12a2adcd-f52c-451b-a803-96f7725d4203@github.com>

On Thu, 9 Jan 2025 13:45:13 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review that updates the specification for FlightRecorder::addListener to reflect that the Security Manager is now disabled. 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 1bf2f5c8
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1bf2f5c8a92b30eabb530737158f57c63a81fef6
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Fri Jan 10 16:35:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 10 Jan 2025 16:35:10 GMT
Subject: [jdk24] RFR: 8343510: JFR: Remove AccessControlContext from
 FlightRecorder::addListener specification
Message-ID: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com>

8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification

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

Commit messages:
 - Backport 1bf2f5c8a92b30eabb530737158f57c63a81fef6

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

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

From mgronlun at openjdk.org  Fri Jan 10 16:35:10 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 10 Jan 2025 16:35:10 GMT
Subject: [jdk24] RFR: 8343510: JFR: Remove AccessControlContext from
 FlightRecorder::addListener specification
In-Reply-To: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com>
References: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com>
Message-ID: <qjDvDLD_hJA-fjmINmESDHsJi0H-_AF5tDHZf4QQyQ4=.7053df1f-8a99-494a-9df8-c6f2dd9cd858@github.com>

On Fri, 10 Jan 2025 16:16:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23041#pullrequestreview-2542909847

From dholmes at openjdk.org  Mon Jan 13 06:04:42 2025
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 13 Jan 2025 06:04:42 GMT
Subject: RFR: 8347124: Clean tests with --enable-linkable-runtime [v3]
In-Reply-To: <FsfdnhQ-QAxHUTtU194sI_wtB6oE3UdiB8oqgrLWIV0=.df55f2a9-ea4e-4d40-b2e3-5cdcea668ebb@github.com>
References: <yGo7YHSUxJaXugyZtAPQU-Dov_8K-_2pRhD20vbNTds=.120db54a-5e8c-4fb3-a897-9a3a4ac550c1@github.com>
 <FsfdnhQ-QAxHUTtU194sI_wtB6oE3UdiB8oqgrLWIV0=.df55f2a9-ea4e-4d40-b2e3-5cdcea668ebb@github.com>
Message-ID: <90L-N_yB8R9WfOVhMC7FM0StbeiRMz9DMa93apWR7R0=.33263ced-4a96-42a7-a89f-0a4ecdd7daa9@github.com>

On Thu, 9 Jan 2025 10:18:35 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this trivial test-only patch in support of running tests on JEP 493 enabled builds. Both tests use the `ToolProvider` API so as to run `jlink` in-process of the test JVM which includes module patches (as in - uses `--patch-module`) which is not supported for JEP 493 enabled JDKs. The proposed fix is to run those two tests in `/othervm` so as to no longer see the module patch of the test JDK.
>> 
>> Testing:
>> - [x] GHA
>> - [x] Affected tests which fail prior the patch and pass after with a JEP 493 enabled JDK. Also tested on a JDK that includes `jmods` folder.
>> 
>> Thoughts?
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Expand comment

Sorry for the tardy response - the updated comment looks good. Thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/22969#issuecomment-2586229113

From sgehwolf at openjdk.org  Mon Jan 13 15:44:55 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 13 Jan 2025 15:44:55 GMT
Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after
 JDK-8347124: No javac
Message-ID: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>

Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped.

I've done that by adding those two required modules in the `@modules` tag.

Testing:
- [ ] GHA
- [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes.

Thoughts?

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

Commit messages:
 - 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac

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

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

From egahlin at openjdk.org  Mon Jan 13 20:57:40 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 13 Jan 2025 20:57:40 GMT
Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after
 JDK-8347124: No javac
In-Reply-To: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
References: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
Message-ID: <7wNRc26-WfbpQoUi_hMa9NXdnN51s8LTvfWOqN6OiSs=.3091bbf5-130e-4ee7-b9dd-3eb181d4fff0@github.com>

On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped.
> 
> I've done that by adding those two required modules in the `@modules` tag.
> 
> Testing:
> - [ ] GHA
> - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes.
> 
> Thoughts?

Marked as reviewed by egahlin (Reviewer).

> 
> Thoughts?
> 

Seems reasonable, as long as the created images don't have other modules it should be fines.

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

PR Review: https://git.openjdk.org/jdk/pull/23079#pullrequestreview-2547868599
PR Comment: https://git.openjdk.org/jdk/pull/23079#issuecomment-2588178645

From dholmes at openjdk.org  Tue Jan 14 02:54:37 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 14 Jan 2025 02:54:37 GMT
Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after
 JDK-8347124: No javac
In-Reply-To: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
References: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
Message-ID: <QPFhZ_0Yi129qOZUKquTQst5cr0xq-4vRl82q3874cM=.b0229a0a-a736-4724-bd8f-7825a090a1df@github.com>

On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped.
> 
> I've done that by adding those two required modules in the `@modules` tag.
> 
> Testing:
> - [ ] GHA
> - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes.
> 
> Thoughts?

Looks good. Thanks for fixing!

I agree this was likely always a problem but never observed when run in an agentVM.

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

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23079#pullrequestreview-2548624479

From sgehwolf at openjdk.org  Tue Jan 14 09:20:46 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Jan 2025 09:20:46 GMT
Subject: RFR: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails after
 JDK-8347124: No javac
In-Reply-To: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
References: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
Message-ID: <EojyfyK6scJA2x3S9N_49HD9GPjIt6bJg7u0O_wyQqo=.2d9cce86-e096-47ad-af4d-2e4597636c4b@github.com>

On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped.
> 
> I've done that by adding those two required modules in the `@modules` tag.
> 
> Testing:
> - [x] GHA
> - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes.
> 
> Thoughts?

Thanks for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/23079#issuecomment-2589399240

From sgehwolf at openjdk.org  Tue Jan 14 09:20:46 2025
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 14 Jan 2025 09:20:46 GMT
Subject: Integrated: 8347496: Test jdk/jfr/jvm/TestModularImage.java fails
 after JDK-8347124: No javac
In-Reply-To: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
References: <vo6BqjOA3RBRcM3SEZoJz1g2fjDibeZBU1xzb_GXKJA=.3384c186-ea6f-471d-8a24-395ebf43b670@github.com>
Message-ID: <mwWkEShNWD_ESrwHfGEYcXvIbE3JJ3O7873EkPtmmzM=.e4dec470-82f9-44b5-8f88-006fbd29843f@github.com>

On Mon, 13 Jan 2025 15:39:19 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this test-only fix. Apparently there are some test configurations out there that run `jdk/jfr/jvm/TestModularImage.java` with limited modules. Specifically `--limit-modules java.base,jdk.jfr`. For this particular test that is not sufficient to be able to run the test. `TestModularImage.java` uses the `ToolProvider` API to get a hold of `javac` as well as for `jlink` without them being present the test should be skipped.
> 
> I've done that by adding those two required modules in the `@modules` tag.
> 
> Testing:
> - [x] GHA
> - [x] `jdk/jfr/jvm/TestModularImage.java` with test option `--limit-modules jdk.jfr,java.base` which now skips the test (instead of failing the test). Running `TestModularImage.java` without the `--limit-modules` option and it passes.
> 
> Thoughts?

This pull request has now been integrated.

Changeset: 39676963
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3967696386ecc706927f05dfae0841b3f23e319d
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8347496: Test jdk/jfr/jvm/TestModularImage.java fails after JDK-8347124: No javac

Reviewed-by: egahlin, dholmes

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

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

From mgronlun at openjdk.org  Tue Jan 14 14:40:11 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 14 Jan 2025 14:40:11 GMT
Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently
Message-ID: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>

Greetings,

This is a hypothetical fix for JDK-8345493, because the issue seems impossible to reproduce, even with instrumentation and extra debug information.

Debugging .mdmp state indicates that a message request thread is not woken up from waiting on a condition variable, even as the sent-in message has been processed. Both the message request thread and the consumer wait on the condition variable instead. This means the message request thread does not wake up to check that its message has been processed.

There is a bit of designed asymmetry in that only a single message thread should be waiting for a message to be processed. The consumer, therefore, signals it using notify(). 

Let's say we have a broken invariant somewhere (not yet found) that allows two threads to post messages?notify() will only wake up a single thread from the associated condition variable.

A safer, intermediate "fix" is to let the consumer issue a notify_all() to wake all potential waiters.

We will continue to investigate the underlying cause but suggest this as an intermediate fix.

Testing: jdk_jfr, stress testing.

Thanks
Markus

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

Commit messages:
 - 8345493

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

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

From egahlin at openjdk.org  Tue Jan 14 16:12:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 14 Jan 2025 16:12:56 GMT
Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently
In-Reply-To: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>
References: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>
Message-ID: <1CCra7fGm0aLlpIS1-0S4V2nWMlnzrL3xH0X1OOdG20=.29ebee20-d72e-4d80-975f-6a498130a715@github.com>

On Tue, 14 Jan 2025 14:35:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This is a hypothetical fix for JDK-8345493, because the issue seems impossible to reproduce, even with instrumentation and extra debug information.
> 
> Debugging .mdmp state indicates that a message request thread is not woken up from waiting on a condition variable, even as the sent-in message has been processed. Both the message request thread and the consumer wait on the condition variable instead. This means the message request thread does not wake up to check that its message has been processed.
> 
> There is a bit of designed asymmetry in that only a single message thread should be waiting for a message to be processed. The consumer, therefore, signals it using notify(). 
> 
> Let's say we have a broken invariant somewhere (not yet found) that allows two threads to post messages?notify() will only wake up a single thread from the associated condition variable.
> 
> A safer, intermediate "fix" is to let the consumer issue a notify_all() to wake all potential waiters.
> 
> We will continue to investigate the underlying cause but suggest this as an intermediate fix.
> 
> Testing: jdk_jfr, stress testing.
> 
> Thanks
> Markus

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23105#pullrequestreview-2550239729

From coleenp at openjdk.org  Tue Jan 14 16:40:50 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 16:40:50 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
Message-ID: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>

Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.

Tested just now with tier1-4 on x86 and aarch64.

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

Commit messages:
 - Round 1 with the script.

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

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

From egahlin at openjdk.org  Tue Jan 14 16:51:37 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 14 Jan 2025 16:51:37 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <MMmRu1l-43g-NoQK5KQExabzCRfDUXtR8iqVUxKDfWU=.ded60175-9779-4b5e-84be-70a7a64a4a8b@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23109#pullrequestreview-2550409017

From coleenp at openjdk.org  Tue Jan 14 16:56:41 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 16:56:41 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <meyngi_hxcZvmfOi6yuqceWxytqsgGOdypZUX1dqXD0=.9d702cc2-09c2-443a-adeb-ced70ed250ee@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

Thanks Erik.  Trivial?

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

PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590543402

From egahlin at openjdk.org  Tue Jan 14 16:56:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 14 Jan 2025 16:56:41 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <meyngi_hxcZvmfOi6yuqceWxytqsgGOdypZUX1dqXD0=.9d702cc2-09c2-443a-adeb-ced70ed250ee@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
 <meyngi_hxcZvmfOi6yuqceWxytqsgGOdypZUX1dqXD0=.9d702cc2-09c2-443a-adeb-ced70ed250ee@github.com>
Message-ID: <eujrfFEhOFZk-UDG6-5__GkjkY19dxEJPerWhCZv3Q4=.2172be2a-7a7a-4b01-9b04-7a872cd060d7@github.com>

On Tue, 14 Jan 2025 16:51:51 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Thanks Erik. Trivial?

Yes!

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

PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590556159

From coleenp at openjdk.org  Tue Jan 14 17:03:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 17:03:46 GMT
Subject: RFR: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <MWpMghTHlnYrtsyyoYaen6g9ysHelKqv25P7jL6oxBw=.c87dfec6-fdf5-4a29-9ee3-d87155810f37@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/23109#issuecomment-2590573131

From coleenp at openjdk.org  Tue Jan 14 17:03:46 2025
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Tue, 14 Jan 2025 17:03:46 GMT
Subject: Integrated: 8347724: Replace SIZE_FORMAT in jfr directory
In-Reply-To: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
References: <3KOw03LCeI15CeFhdVu0hiw9_oFC4o_gVBKmtJ3fwbc=.9df72302-4d07-47fb-b77f-8449ac4be56e@github.com>
Message-ID: <ARRecPuvDAI9PCQYTDB44K85IFqQaWEYYdqDy-zVup8=.015e14a4-16ab-485d-9532-4f46d2d620ac@github.com>

On Tue, 14 Jan 2025 16:35:32 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

> Please review this change to replace SIZE_FORMAT with %zu in the jfr directory.  Most were done with a script with no hand-editing.
> 
> Tested just now with tier1-4 on x86 and aarch64.

This pull request has now been integrated.

Changeset: a01e92cd
Author:    Coleen Phillimore <coleenp at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a01e92cdef1b7fb02035f9246a7c9fccfcf46057
Stats:     28 lines in 9 files changed: 0 ins; 0 del; 28 mod

8347724: Replace SIZE_FORMAT in jfr directory

Reviewed-by: egahlin

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

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

From egahlin at openjdk.org  Tue Jan 14 22:34:45 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 14 Jan 2025 22:34:45 GMT
Subject: [jdk24] Integrated: 8343510: JFR: Remove AccessControlContext from
 FlightRecorder::addListener specification
In-Reply-To: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com>
References: <1Q4iIDJWx02EigJh6bPYbrZTWiCtCbCHciQqeriSmhk=.548361e9-86cc-458c-8008-904af4a05c47@github.com>
Message-ID: <cHB7RBhgEHJ-XaSfcf3P6JuIVxVgwv7WXiBwPi0qc98=.17bbd501-7c2c-4b60-b886-c245b1d0b254@github.com>

On Fri, 10 Jan 2025 16:16:09 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> 8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification

This pull request has now been integrated.

Changeset: 1399f253
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1399f253b03c0deef862eb1ef3ffb16eb0a56717
Stats:     2 lines in 1 file changed: 0 ins; 1 del; 1 mod

8343510: JFR: Remove AccessControlContext from FlightRecorder::addListener specification

Reviewed-by: mgronlun
Backport-of: 1bf2f5c8a92b30eabb530737158f57c63a81fef6

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

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

From mgronlun at openjdk.org  Wed Jan 15 13:04:59 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 15 Jan 2025 13:04:59 GMT
Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently [v2]
In-Reply-To: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>
References: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>
Message-ID: <VkdGs1b3dIwRj7Kt_S0GfU9kuLEgNqarMUYVwvH2Sso=.2893a2fb-e3ac-4efd-8967-01493dad93b5@github.com>

> Greetings,
> 
> This is the fix for JDK-8345493.
> 
> Problem Summary:
> 1. Threads calling JVM.begin_recording() and JVM.end_recording() only hold the PlatformRecorder lock (not the MetadataRepository lock)
> 2. The periodic flush thread only holds the MetadataRepository lock, not the PlatformRecorder lock.
> 
> Problem solution:
> The periodic flush thread must acquire both the PlatformRecorder lock and the MetadataRepository lock (in that order). 
> 
> Testing: jdk_jfr, stress testing.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:

 - revert notify_all()
 - FlushTask to acquire PlatformRecorder and MetadataRepository locks

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23105/files
  - new: https://git.openjdk.org/jdk/pull/23105/files/742f391c..5c8e9f10

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

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

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

From mbaesken at openjdk.org  Wed Jan 15 14:09:09 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 15 Jan 2025 14:09:09 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS
Message-ID: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>

The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
java.lang.AssertionError: Expected at least one event
at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:565)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.run(Thread.java:1447)

The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.

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

Commit messages:
 - JDK-8346875

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

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

From egahlin at openjdk.org  Wed Jan 15 14:43:38 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 15 Jan 2025 14:43:38 GMT
Subject: RFR: 8345493: JFR: JVM.flush hangs intermittently [v2]
In-Reply-To: <VkdGs1b3dIwRj7Kt_S0GfU9kuLEgNqarMUYVwvH2Sso=.2893a2fb-e3ac-4efd-8967-01493dad93b5@github.com>
References: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>
 <VkdGs1b3dIwRj7Kt_S0GfU9kuLEgNqarMUYVwvH2Sso=.2893a2fb-e3ac-4efd-8967-01493dad93b5@github.com>
Message-ID: <0NUmybYTykAs_a6FJ3t41taSnIVd3ZQ9LiYhsqf88Q4=.0af32073-c978-4d0f-9451-11a299f52afc@github.com>

On Wed, 15 Jan 2025 13:04:59 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> This is the fix for JDK-8345493.
>> 
>> Problem Summary:
>> 1. Threads calling JVM.begin_recording() and JVM.end_recording() only hold the PlatformRecorder lock (not the MetadataRepository lock)
>> 2. The periodic flush thread only holds the MetadataRepository lock, not the PlatformRecorder lock.
>> 
>> Problem solution:
>> The periodic flush thread must acquire both the PlatformRecorder lock and the MetadataRepository lock (in that order). 
>> 
>> Testing: jdk_jfr, stress testing.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - revert notify_all()
>  - FlushTask to acquire PlatformRecorder and MetadataRepository locks

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23105#pullrequestreview-2552956424

From mgronlun at openjdk.org  Wed Jan 15 16:21:43 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 15 Jan 2025 16:21:43 GMT
Subject: Integrated: 8345493: JFR: JVM.flush hangs intermittently
In-Reply-To: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>
References: <i_ZVZ-4M8WkmuDaCPxyUNmdj-RDmr4Ov37Nwl3ro5-k=.e537e750-ca60-4c7a-b40f-35d8b2492819@github.com>
Message-ID: <F8yoWDJfJS8ZE1JI7Gf1kkxxb1nf30vQA_3rc9SnnKc=.dd87df37-bf9a-4505-b137-b1a1712d8537@github.com>

On Tue, 14 Jan 2025 14:35:07 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> This is the fix for JDK-8345493.
> 
> Problem Summary:
> 1. Threads calling JVM.begin_recording() and JVM.end_recording() only hold the PlatformRecorder lock (not the MetadataRepository lock)
> 2. The periodic flush thread only holds the MetadataRepository lock, not the PlatformRecorder lock.
> 
> Problem solution:
> The periodic flush thread must acquire both the PlatformRecorder lock and the MetadataRepository lock (in that order). 
> 
> Testing: jdk_jfr, stress testing.
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 4257215a
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4257215a9fa02f74ccd4fc62893d4b1a232a8754
Stats:     9 lines in 2 files changed: 7 ins; 0 del; 2 mod

8345493: JFR: JVM.flush hangs intermittently

Reviewed-by: egahlin

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

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

From mgronlun at openjdk.org  Wed Jan 15 16:26:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 15 Jan 2025 16:26:47 GMT
Subject: [jdk24] RFR: 8345493: JFR: JVM.flush hangs intermittently
Message-ID: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com>

8345493: JFR: JVM.flush hangs intermittently

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

Commit messages:
 - Backport 4257215a9fa02f74ccd4fc62893d4b1a232a8754

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

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

From egahlin at openjdk.org  Wed Jan 15 16:33:42 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 15 Jan 2025 16:33:42 GMT
Subject: [jdk24] RFR: 8345493: JFR: JVM.flush hangs intermittently
In-Reply-To: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com>
References: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com>
Message-ID: <zjs-X3xFax5OGZGK93dYjWKFQdwh3atlguwxVi6mkQU=.3c0441f7-46de-462f-8684-4bfbb84c6959@github.com>

On Wed, 15 Jan 2025 16:19:30 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8345493: JFR: JVM.flush hangs intermittently

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23141#pullrequestreview-2553294239

From mgronlun at openjdk.org  Wed Jan 15 16:45:41 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Wed, 15 Jan 2025 16:45:41 GMT
Subject: [jdk24] Integrated: 8345493: JFR: JVM.flush hangs intermittently
In-Reply-To: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com>
References: <7w69pk60ub1LDw3dB8_nIqB4YiDt4Hve0icxfyRnQDU=.e11df01d-dc36-433f-aba0-7fafe20ed5bf@github.com>
Message-ID: <xwJhQaNd-4Dlgn-wVJ7FpBbgP_RWguNwzGD-EBSWFmc=.ace43916-50e0-438d-b2e0-afd6fe79628a@github.com>

On Wed, 15 Jan 2025 16:19:30 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> 8345493: JFR: JVM.flush hangs intermittently

This pull request has now been integrated.

Changeset: 1495f7ad
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1495f7addbaab5ed6bfb582a63f8cc2f0c97a100
Stats:     9 lines in 2 files changed: 7 ins; 0 del; 2 mod

8345493: JFR: JVM.flush hangs intermittently

Reviewed-by: egahlin
Backport-of: 4257215a9fa02f74ccd4fc62893d4b1a232a8754

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

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

From duke at openjdk.org  Wed Jan 15 22:30:45 2025
From: duke at openjdk.org (duke)
Date: Wed, 15 Jan 2025 22:30:45 GMT
Subject: Withdrawn: 8344191: Build code should not have classpath exception
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <AJAYVwkH3Ma-yxOCmM0bFSSiFukyr01NVWCAW2YOp_c=.e33de2b1-60db-46f8-9171-8cd2f13c5a64@github.com>

On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

This pull request has been closed without being integrated.

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

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

From egahlin at openjdk.org  Thu Jan 16 03:51:34 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 16 Jan 2025 03:51:34 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS
In-Reply-To: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
Message-ID: <sQ1DPTo2ZP0Kzs-QnJ7itSAofLIDfVb1TvN8aDOpdfQ=.8618c115-eedc-447b-9fa9-e7b11e32d7b0@github.com>

On Wed, 15 Jan 2025 14:02:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
> java.lang.AssertionError: Expected at least one event
> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.

Do you think it is this lines that prevent us from getting a sample.
https://github.com/openjdk/jdk/blob/9c430c92257739730155df05f340fe144fd24098/src/hotspot/os/bsd/os_perf_bsd.cpp#L140

Maybe we should do some work instead of additional sleeping?

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

PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2594419548

From mbaesken at openjdk.org  Thu Jan 16 08:11:35 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 16 Jan 2025 08:11:35 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS
In-Reply-To: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
Message-ID: <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com>

On Wed, 15 Jan 2025 14:02:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
> java.lang.AssertionError: Expected at least one event
> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.

Not sure if it is this line.  Should we maybe add some UL tracing; enable it for the test and see if we hit this ?

> Maybe we should do some work instead of additional sleeping?

Could be that this helps;  or increase the sleep time (but less than I did) AND do some CPU intensive work .

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

PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2594780617

From egahlin at openjdk.org  Thu Jan 16 10:48:35 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 16 Jan 2025 10:48:35 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS
In-Reply-To: <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
 <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com>
Message-ID: <QWF-m2DOmGhOVJnwsk_73e3lGjoXwm9zo3kw0oT2m1Y=.70e2f9db-b686-477b-ae42-b604a5e60773@github.com>

On Thu, 16 Jan 2025 08:09:19 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work .

You could keep the 100 ms and do some CPU intensive work. If it still fails, then we'll know it's not CPU work related. If we change both at once, it's harder to analyze.

If I remember correctly, we didn't have sleep at all initially (2012). Then we had a smaller sleep which was later increased to 100 ms. We should probably have tried to add CPU related work instead of increasing the sleep time.

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

PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2595185436

From mgronlun at openjdk.org  Thu Jan 16 13:59:06 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 16 Jan 2025 13:59:06 GMT
Subject: RFR: 8347922: Remove
 runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt and
 TEST.groups
Message-ID: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>

Greetings,

Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt and TEST.groups.

Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC.

Thanks
Markus

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

Commit messages:
 - 8347922

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

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

From egahlin at openjdk.org  Thu Jan 16 14:03:34 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 16 Jan 2025 14:03:34 GMT
Subject: RFR: 8347922: Remove
 runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt and
 TEST.groups
In-Reply-To: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>
References: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>
Message-ID: <kAzoIHPyudLl9QNI4gdgG9BaNwlxascPn4OiVya0q5g=.487e32ea-9bb4-45db-b6c5-d47f51b3b866@github.com>

On Thu, 16 Jan 2025 13:53:49 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt and TEST.groups.
> 
> Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC.
> 
> Thanks
> Markus

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23158#pullrequestreview-2556242652

From mbaesken at openjdk.org  Thu Jan 16 14:45:16 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 16 Jan 2025 14:45:16 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS [v2]
In-Reply-To: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
Message-ID: <XcFjGC8H9EFWvlPzSePKMZLdPZHrNKmjawaVYxojAu0=.63c93223-ea4d-4eba-a99f-25d9f7302030@github.com>

> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
> java.lang.AssertionError: Expected at least one event
> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  adjust the program, burn some cycles instead

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23136/files
  - new: https://git.openjdk.org/jdk/pull/23136/files/ad334587..382a12f6

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

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

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

From mbaesken at openjdk.org  Thu Jan 16 14:52:39 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 16 Jan 2025 14:52:39 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS [v2]
In-Reply-To: <XcFjGC8H9EFWvlPzSePKMZLdPZHrNKmjawaVYxojAu0=.63c93223-ea4d-4eba-a99f-25d9f7302030@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
 <XcFjGC8H9EFWvlPzSePKMZLdPZHrNKmjawaVYxojAu0=.63c93223-ea4d-4eba-a99f-25d9f7302030@github.com>
Message-ID: <qFLHMs_P6XYmLs60O3Zp6luWLNz8_uVgZ3280nJ_LPc=.6b32cb6c-7528-4e89-9729-01c7a2d19031@github.com>

On Thu, 16 Jan 2025 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
>> java.lang.AssertionError: Expected at least one event
>> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust the program, burn some cycles instead

Hi Erik, I added some code doing a few calculations. Let's see if this is good .

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

PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2595932390

From gziemski at openjdk.org  Thu Jan 16 19:46:15 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 16 Jan 2025 19:46:15 GMT
Subject: RFR: 8345500: Timeout in jdk.jfr.api.consumer.streaming.TestJVMCrash
Message-ID: <UM6vAPzvHNQVGL4uDHtBKAorx5VtBC0uaus43fExDX4=.c6aad20d-5b4c-4c2f-b77f-12a10d1af990@github.com>

In this fix we add 1 second delay after we create a process.

On macOS we seem to be creating a process so quickly, that other threads need time to see it.

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

Commit messages:
 - allow process to be visible by other threads

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

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

From egahlin at openjdk.org  Thu Jan 16 19:59:38 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 16 Jan 2025 19:59:38 GMT
Subject: RFR: 8345500: Timeout in
 jdk.jfr.api.consumer.streaming.TestJVMCrash
In-Reply-To: <UM6vAPzvHNQVGL4uDHtBKAorx5VtBC0uaus43fExDX4=.c6aad20d-5b4c-4c2f-b77f-12a10d1af990@github.com>
References: <UM6vAPzvHNQVGL4uDHtBKAorx5VtBC0uaus43fExDX4=.c6aad20d-5b4c-4c2f-b77f-12a10d1af990@github.com>
Message-ID: <L4GVhsVqslpq1c1Kc3xj9yUJjjjDsuIpTLAzBgj67Pg=.f1a22a07-62b8-4bc3-96e0-30cce2ac4ce7@github.com>

On Thu, 16 Jan 2025 19:39:01 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> In this fix we add 1 second delay after we create a process.
> 
> On macOS we seem to be creating a process so quickly, that other threads need time to see it.

I don't think this is the correct way to fix the issue. Users may write code that doesn't wait 1 s and run into the same problem. Why shouldn't a client be able to poll? Also, it's only a matter of time before it happens again, either because the hardware is slow or because the processes are starved due to other processes running on the machine.

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

PR Comment: https://git.openjdk.org/jdk/pull/23163#issuecomment-2596779153

From egahlin at openjdk.org  Thu Jan 16 20:04:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 16 Jan 2025 20:04:36 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS [v2]
In-Reply-To: <XcFjGC8H9EFWvlPzSePKMZLdPZHrNKmjawaVYxojAu0=.63c93223-ea4d-4eba-a99f-25d9f7302030@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
 <XcFjGC8H9EFWvlPzSePKMZLdPZHrNKmjawaVYxojAu0=.63c93223-ea4d-4eba-a99f-25d9f7302030@github.com>
Message-ID: <5IZ_0IqI0ypBeE7PNHqJawhmSyVfRxF_Wkdjav0GNZc=.5b69d890-0cdf-41ad-9636-5e5ba520ee95@github.com>

On Thu, 16 Jan 2025 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
>> java.lang.AssertionError: Expected at least one event
>> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust the program, burn some cycles instead

I tried running the test 100 times on different operating systems and hardware. No failures. Let's try this.

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

Marked as reviewed by egahlin (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23136#pullrequestreview-2557185942

From gziemski at openjdk.org  Thu Jan 16 23:01:35 2025
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Thu, 16 Jan 2025 23:01:35 GMT
Subject: RFR: 8345500: Timeout in
 jdk.jfr.api.consumer.streaming.TestJVMCrash
In-Reply-To: <L4GVhsVqslpq1c1Kc3xj9yUJjjjDsuIpTLAzBgj67Pg=.f1a22a07-62b8-4bc3-96e0-30cce2ac4ce7@github.com>
References: <UM6vAPzvHNQVGL4uDHtBKAorx5VtBC0uaus43fExDX4=.c6aad20d-5b4c-4c2f-b77f-12a10d1af990@github.com>
 <L4GVhsVqslpq1c1Kc3xj9yUJjjjDsuIpTLAzBgj67Pg=.f1a22a07-62b8-4bc3-96e0-30cce2ac4ce7@github.com>
Message-ID: <G8ugw4wFhzJGTtcI-lPzUj9fBP8btsV1CPLBOZkacR0=.d243b54c-c3e1-40ed-b2a6-b67c55305d0f@github.com>

On Thu, 16 Jan 2025 19:57:12 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> I don't think this is the correct way to fix the issue. Users may write code that doesn't wait 1 s and run into the same problem. Why shouldn't a client be able to poll repeatedly? Also, it's only a matter of time before it happens again, either because the hardware is slow or because the processes are starved due to other things running on the machine.

To be honest I'm not 100% happy with the fix, it was just the simplest one that I could think of. Let me look into it a bit more.

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

PR Comment: https://git.openjdk.org/jdk/pull/23163#issuecomment-2597076705

From mbaesken at openjdk.org  Fri Jan 17 08:01:48 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Jan 2025 08:01:48 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS [v2]
In-Reply-To: <XcFjGC8H9EFWvlPzSePKMZLdPZHrNKmjawaVYxojAu0=.63c93223-ea4d-4eba-a99f-25d9f7302030@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
 <XcFjGC8H9EFWvlPzSePKMZLdPZHrNKmjawaVYxojAu0=.63c93223-ea4d-4eba-a99f-25d9f7302030@github.com>
Message-ID: <t90Akbe8gKtz08Uvg_L5pkTcWD3KXUHftQcjNl09TVs=.a0d59f11-9833-444b-9e38-517c9fee5a54@github.com>

On Thu, 16 Jan 2025 14:45:16 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
>> java.lang.AssertionError: Expected at least one event
>> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
>> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
>> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
>> at java.base/java.lang.Thread.run(Thread.java:1447)
>> 
>> The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adjust the program, burn some cycles instead

Hi Erik, thanks for the review ! Let's see if this is better than the sleep  (or maybe we need both, sleep and cycle burning) .

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

PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2597639959

From mbaesken at openjdk.org  Fri Jan 17 08:01:49 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 17 Jan 2025 08:01:49 GMT
Subject: Integrated: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails
 on macOS
In-Reply-To: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
Message-ID: <FzJBa5WugwD1hF6J5hGLiB5Xw0zHRm01wtmVgRTmuhc=.391db7d6-0d43-46fa-bb77-29affea20bdf@github.com>

On Wed, 15 Jan 2025 14:02:55 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> The test fails on some new Mac instances (macOS 14.5 (macOS aarch64) , CPU Apple M2) with :
> java.lang.AssertionError: Expected at least one event
> at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:62)
> at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
> at java.base/java.lang.reflect.Method.invoke(Method.java:565)
> at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
> at java.base/java.lang.Thread.run(Thread.java:1447)
> 
> The current sleep value seems to be a bit too slow for those machines.  The issues occured (mostly) with fastdebug binaries.

This pull request has now been integrated.

Changeset: a3eef6c2
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a3eef6c2416eb0e02fbd154d84c98b12bcb66e97
Stats:     23 lines in 1 file changed: 19 ins; 1 del; 3 mod

8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on macOS

Reviewed-by: egahlin

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

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

From mgronlun at openjdk.org  Fri Jan 17 17:35:51 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 17 Jan 2025 17:35:51 GMT
Subject: RFR: 8347922: Remove
 runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt and
 TEST.groups [v2]
In-Reply-To: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>
References: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>
Message-ID: <xl_tnfu7Uv4xzewIUxqcrHuGuVXj0aSjPfUWUn_AaQQ=.826affae-bc9d-4eea-95c8-4058bb425835@github.com>

> Greetings,
> 
> Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt and TEST.groups.
> 
> Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC.
> 
> Thanks
> Markus

Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:

  do not modify TEST.groups

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/23158/files
  - new: https://git.openjdk.org/jdk/pull/23158/files/dca3d53c..0c661b42

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

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

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

From egahlin at openjdk.org  Fri Jan 17 17:46:34 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 17 Jan 2025 17:46:34 GMT
Subject: RFR: 8347922: Remove
 runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt [v2]
In-Reply-To: <xl_tnfu7Uv4xzewIUxqcrHuGuVXj0aSjPfUWUn_AaQQ=.826affae-bc9d-4eea-95c8-4058bb425835@github.com>
References: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>
 <xl_tnfu7Uv4xzewIUxqcrHuGuVXj0aSjPfUWUn_AaQQ=.826affae-bc9d-4eea-95c8-4058bb425835@github.com>
Message-ID: <eJIuqqzhNBTrylB57frJzR-KFSom52A7VQ1ZU2V3AbE=.ad2f7ac3-e34c-41c1-b090-ea9fea2a6b7e@github.com>

On Fri, 17 Jan 2025 17:35:51 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt.
>> 
>> Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC.
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   do not modify TEST.groups

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23158#pullrequestreview-2559613287

From mgronlun at openjdk.org  Mon Jan 20 08:56:43 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 20 Jan 2025 08:56:43 GMT
Subject: Integrated: 8347922: Remove
 runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt
In-Reply-To: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>
References: <DCzLvPGUCVpQNW0lAzuN8cF4vO3cyzaRwVoMiWu1qyw=.7f6e6a46-2f84-4b2f-9cfb-b9132154e766@github.com>
Message-ID: <8WJ57ZFYu4zAXhQwRgo3NyPzLfo1bROYP1O_p61Mboo=.8fce7cab-9c20-4eda-884d-097eebead139@github.com>

On Thu, 16 Jan 2025 13:53:49 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Removing the HelloCustom_JFR.java test exclusion from ProblemList.txt.
> 
> Testing: Repeated testing of HelloCustom_JFR.java with and without -XX:+UseZGC.
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: 4b4b1e91
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4b4b1e912a3193cc95c956acc770015f707449b1
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8347922: Remove runtime/cds/appcds/customLoader/HelloCustom_JFR.java from ProblemList.txt

Reviewed-by: egahlin

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

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

From egahlin at openjdk.org  Mon Jan 20 18:41:39 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 20 Jan 2025 18:41:39 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v5]
In-Reply-To: <CVS-QWIDcmKgGRfcZKSAo2tsqbmsjAubV_1D4nxkemg=.4c1cebba-2473-4462-b503-a1b98d275c9c@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <jPTulnXnFVqhHlevdOXxBGeBj8DPAuvtjpHGVxgK2xc=.21b945cd-edcc-44bc-a1fb-24a3764380c9@github.com>
 <0cyBOkicHRv3O8XkoAzzpNfC6auxjkPVtsrvRybLa44=.4b07f7e0-65a0-4e87-8758-d03f015e3661@github.com>
 <i5fdjBh7b9tYYlJnXrOcgNdkXXHypZeO0zo-43k7S4s=.f38fee13-a51f-4a6d-893f-460e3ee2a14f@github.com>
 <3bizpeZPDx1GkDuHtNSq1229cleBGYHZW6s4Cx8hGwQ=.2a6a2dc1-462f-41b8-86af-adcc36f81d8b@github.com>
 <TTudzryf1I-y9xMvSgSvbaklcfNcufmPdAKDKDY8i5w=.1ab552fc-d8ea-4c00-94ec-b57bb27ac71e@github.com>
 <LrwICPJAbghXB0yrGolbodIr28Kz_w2ddd9cm2u-0uE=.a905f64f-ae1e-4217-b7d4-2b37dbf1f94f@github.com>
 <9j67W3RcuigGBre_a2BfGeMsRlWvEFcoUg3iRmglPVQ=.4a0d1d85-eca9-4669-88f1-a8ed1159d3cb@github.com>
 <xRhZXRH84sxJwvDHy1Tb3ONo8LwZoA5BZxPLVdiL38k=.f34f99ea-46ab-4248-8902-0574c57d4faf@github.com>
 <zjeijmSEP4kI2pUL_mHfivMwkjE4EwEUtKon5AUGPEw=.1ecde1ce-5cc9-4ec6-ae4f-33ef7769ff83@github.com>
 <H2R7qV5JDew2AF-1qTBWoYpY3KM7bQ-15Sz
 5nlPzd9U=.412a4543-6db6-4c17-a3fa-f34d3f5538c4@github.com>
 <xqj9Uffno4vZWpf6VLW9oNc3I4hPEVYBuwq0hRIvSgk=.f25d0ad9-64c5-43e2-8fdc-654ab25b20bc@github.com>
 <CVS-QWIDcmKgGRfcZKSAo2tsqbmsjAubV_1D4nxkemg=.4c1cebba-2473-4462-b503-a1b98d275c9c@github.com>
Message-ID: <yz5-D1MAHydOKbMLooLg9AP4YxeSnk1l32FEQRaa4dA=.774c794f-b03a-4c31-bb71-83ae0d7a9f82@github.com>

On Thu, 19 Dec 2024 19:16:55 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> I'm not sure if one or two events are most suitable. If possible, I would like to discuss it with Markus to get some more input. He will back in January.
>
> Regarding one or two events. I'm fine with integrating as-is and then revisit it before FC, if needed.

I talked to Markus, and we think two events would provide the greatest flexibility for future settings and events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1922757394

From mbaesken at openjdk.org  Thu Jan 23 09:11:08 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 23 Jan 2025 09:11:08 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS
In-Reply-To: <QWF-m2DOmGhOVJnwsk_73e3lGjoXwm9zo3kw0oT2m1Y=.70e2f9db-b686-477b-ae42-b604a5e60773@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
 <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com>
 <QWF-m2DOmGhOVJnwsk_73e3lGjoXwm9zo3kw0oT2m1Y=.70e2f9db-b686-477b-ae42-b604a5e60773@github.com>
Message-ID: <gIxNeQKaPsOQPxo2Km-mnH8HFrj0ZORO-oiU8y6BAjE=.c3e9cda8-6817-4771-ad96-ee3694f6a688@github.com>

On Thu, 16 Jan 2025 10:46:24 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Not sure if it is this line.  Should we maybe add some UL tracing; enable it for the test and see if we hit this ?
>> 
>>> Maybe we should do some work instead of additional sleeping?
>> 
>> Could be that this helps;  or increase the sleep time (but less than I did) AND do some CPU intensive work .
>
>> Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work .
> 
> You could keep the 100 ms and do some CPU intensive work. If it still fails, then we'll know it's not CPU work related. If we change both at once, it's harder to analyze.
> 
> If I remember correctly, we didn't have sleep at all initially (2012). Then we had a smaller sleep which was later increased to 100 ms. We should probably have tried to add CPU related work instead of increasing the sleep time.

Hi Erik  @egahlin  ,  we unfortunately still sometimes see the error after this change 

----------System.out:(1/41)----------
Found 183072 primes while burning cycles
----------System.err:(11/642)----------
java.lang.AssertionError: Expected at least one event
	at jdk.jfr.event.os.TestCPULoad.main(TestCPULoad.java:80)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
	at java.base/java.lang.reflect.Method.invoke(Method.java:565)
	at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
	at java.base/java.lang.Thread.run(Thread.java:1447)

So burning cycles did not really help .

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

PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2609230974

From egahlin at openjdk.org  Fri Jan 24 02:28:58 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 24 Jan 2025 02:28:58 GMT
Subject: RFR: 8346875: Test jdk/jdk/jfr/event/os/TestCPULoad.java fails on
 macOS
In-Reply-To: <QWF-m2DOmGhOVJnwsk_73e3lGjoXwm9zo3kw0oT2m1Y=.70e2f9db-b686-477b-ae42-b604a5e60773@github.com>
References: <dm7Y1iUw-gOXXZ7qRXtvXfjwxvfMlwxNawZxiEvA9rk=.8d794809-2241-41d6-addf-d1d613b4dd8c@github.com>
 <5t7JgjdWE9NYq5CidLwh2XJcXh3Cc2DOBPd5Vi0fNdE=.e8bd9c7c-4440-40c6-92d0-84b63339a896@github.com>
 <QWF-m2DOmGhOVJnwsk_73e3lGjoXwm9zo3kw0oT2m1Y=.70e2f9db-b686-477b-ae42-b604a5e60773@github.com>
Message-ID: <WFD9lMmMv_UyMLGXR-9q1D6un6vOyFC3FF6mbjLFwjM=.12b2b550-8302-4485-95a4-5108f81f0980@github.com>

On Thu, 16 Jan 2025 10:46:24 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Not sure if it is this line.  Should we maybe add some UL tracing; enable it for the test and see if we hit this ?
>> 
>>> Maybe we should do some work instead of additional sleeping?
>> 
>> Could be that this helps;  or increase the sleep time (but less than I did) AND do some CPU intensive work .
>
>> Could be that this helps; or increase the sleep time (but less than I did) AND do some CPU intensive work .
> 
> You could keep the 100 ms and do some CPU intensive work. If it still fails, then we'll know it's not CPU work related. If we change both at once, it's harder to analyze.
> 
> If I remember correctly, we didn't have sleep at all initially (2012). Then we had a smaller sleep which was later increased to 100 ms. We should probably have tried to add CPU related work instead of increasing the sleep time.

> Hi Erik @egahlin , we unfortunately still sometimes see the error after this change

I've noticed the same thing when running them in parallel locally, i.e.,

    $ jtreg-conc:32 -v:a -jdk ... test/jdk/jdk/jfr 

You could try adding logging (log_debug(jfr, system)("...")) and see if you can reproduce the issue. If it's not a product bug, you could try to use an event stream instead.

    public static void main(String... args) throws Exception {
      List<RecordedEvent> events = new CopyOnWriteArrayList<>();
      try (var rs = new RecordingStream()) {
        rs.setReuse(false);
        rs.enable("jdk.CPULoad").withPeriod(Duration.ofMillis(50));
        rs.onEvent(e -> {
          events.add(e);
          rs.close();
        });
        rs.start();
        verifyEvent(events.getFirst());
      }
    }
    
    private static void verifyEvent(RecordedEvent e) throws Exception {
      ...
    }`

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

PR Comment: https://git.openjdk.org/jdk/pull/23136#issuecomment-2611409245

From mgronlun at openjdk.org  Fri Jan 24 10:40:48 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Fri, 24 Jan 2025 10:40:48 GMT
Subject: RFR: 8318098: Update jfr tests to replace keyword jfr with
 vm.flagless
In-Reply-To: <nXYifnGGUXS1CoUGZiMuJgD10ty8wL_I5_hGzzO4Kq8=.9491ef9f-42ab-445c-9f58-3d0401fef596@github.com>
References: <nXYifnGGUXS1CoUGZiMuJgD10ty8wL_I5_hGzzO4Kq8=.9491ef9f-42ab-445c-9f58-3d0401fef596@github.com>
Message-ID: <_uOSUMMSvGhGU6WkVdjg6iIi3SU9rhyi9qlLi3zYiPY=.fda4acbd-8774-4d38-b70e-56c0e639cb77@github.com>

On Fri, 24 Jan 2025 01:08:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> A lot of jfr tests are very specific. Currently all of them are marked with jfr keyword and excluded when VM flags are set.
> 
> It makes sense to mark them with @requires <something> to be complaint with all other openjdk tests. 
> The next step is to review tests and remove vm.flagless from tests that should be executed with different VM flags.
> 
> Bug https://bugs.openjdk.org/browse/JDK-8318097 is filed for this activity.

Blanket review. Did not check all files.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/23285#pullrequestreview-2572300298

From lmesnik at openjdk.org  Sat Jan 25 19:02:53 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Sat, 25 Jan 2025 19:02:53 GMT
Subject: Integrated: 8318098: Update jfr tests to replace keyword jfr with
 vm.flagless
In-Reply-To: <nXYifnGGUXS1CoUGZiMuJgD10ty8wL_I5_hGzzO4Kq8=.9491ef9f-42ab-445c-9f58-3d0401fef596@github.com>
References: <nXYifnGGUXS1CoUGZiMuJgD10ty8wL_I5_hGzzO4Kq8=.9491ef9f-42ab-445c-9f58-3d0401fef596@github.com>
Message-ID: <pRbzmBGL1a_JKyeV4Jk9Xo1guXuLehhefwkJjYdZF2c=.de64c2c6-b113-47e8-ad34-e38a14fcd2af@github.com>

On Fri, 24 Jan 2025 01:08:31 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> A lot of jfr tests are very specific. Currently all of them are marked with jfr keyword and excluded when VM flags are set.
> 
> It makes sense to mark them with @requires <something> to be complaint with all other openjdk tests. 
> The next step is to review tests and remove vm.flagless from tests that should be executed with different VM flags.
> 
> Bug https://bugs.openjdk.org/browse/JDK-8318097 is filed for this activity.

This pull request has now been integrated.

Changeset: 99002e4f
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99002e4f9d421d08d912187a1f01809d85820427
Stats:     1090 lines in 582 files changed: 2 ins; 0 del; 1088 mod

8318098: Update jfr tests to replace keyword jfr with vm.flagless

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Thu Jan 30 15:13:24 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 30 Jan 2025 15:13:24 GMT
Subject: RFR: 8348430: Update jfr tests to allow execution with different vm
 flags
Message-ID: <VJWpSbrj3ctp48vS1h7MnYXKvlJA4ibjoI34Ax3rp_A=.96f9b721-412f-4bec-9d5c-c81674ed61b4@github.com>

Could I have review of a change that allows some tests to run with flags.

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From mgronlun at openjdk.org  Thu Jan 30 16:49:52 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 30 Jan 2025 16:49:52 GMT
Subject: RFR: 8348430: Update jfr tests to allow execution with different
 vm flags
In-Reply-To: <VJWpSbrj3ctp48vS1h7MnYXKvlJA4ibjoI34Ax3rp_A=.96f9b721-412f-4bec-9d5c-c81674ed61b4@github.com>
References: <VJWpSbrj3ctp48vS1h7MnYXKvlJA4ibjoI34Ax3rp_A=.96f9b721-412f-4bec-9d5c-c81674ed61b4@github.com>
Message-ID: <gmNrsd3_7FRaUM6TGrWnsFCOUTk14_jhWeS5Qghzvv8=.c2e2bb87-ef17-4340-90e3-42f2b114c098@github.com>

On Thu, 30 Jan 2025 14:25:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a change that allows some tests to run with flags.
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/23369#pullrequestreview-2584467279

From egahlin at openjdk.org  Fri Jan 31 08:58:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 31 Jan 2025 08:58:49 GMT
Subject: Integrated: 8348430: Update jfr tests to allow execution with
 different vm flags
In-Reply-To: <VJWpSbrj3ctp48vS1h7MnYXKvlJA4ibjoI34Ax3rp_A=.96f9b721-412f-4bec-9d5c-c81674ed61b4@github.com>
References: <VJWpSbrj3ctp48vS1h7MnYXKvlJA4ibjoI34Ax3rp_A=.96f9b721-412f-4bec-9d5c-c81674ed61b4@github.com>
Message-ID: <zcwJV2zbjjqZRb7Ua8bZfsMIlQhsuNp31UoPd92VWBU=.bac94394-aeab-46ff-9368-79da3d237ad2@github.com>

On Thu, 30 Jan 2025 14:25:51 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a change that allows some tests to run with flags.
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 8f7e6e2d
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8f7e6e2dbc0a3ccf56242bf071e57bfd671de951
Stats:     10 lines in 10 files changed: 0 ins; 10 del; 0 mod

8348430: Update jfr tests to allow execution with different vm flags

Reviewed-by: mgronlun

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

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