From egahlin at openjdk.org  Mon Sep  1 12:00:41 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 1 Sep 2025 12:00:41 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <ZHFJbzLE75LKyGr0KHJNWH8aSVKoM-8JEPw6EwFcijM=.2daca368-baa2-449c-9148-d6ce8ee2a0d3@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Does your change handle logging to a file?

I looked into fixing this when I did the initial implementation, but I didn't think it was worth addressing. It only applies to jfr+startup and if the user wants the warning level. If a user doesn't want the message, they can specify jfr+startup=error.

Do we log anything with jfr+startup=warning?

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3242090448

From jbechberger at openjdk.org  Mon Sep  1 12:16:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 1 Sep 2025 12:16:44 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <BqiiVfOsqjbyhmhCwKsiQNobdVkyeRj3vAL12iQNUW0=.098eaab2-c9f8-4cf6-b304-1f9a2049ba1e@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Without this change, `jfr+startup=warning` doesn't affect the startup logging at all, and it shows the startup message, which was confusing to one of our users (why is it showing `[info]` tagged startup messages when the warning level is set).

I'll look into how it handles files later in the day

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3242135188

From jbachorik at openjdk.org  Tue Sep  2 08:31:44 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Tue, 2 Sep 2025 08:31:44 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v2]
In-Reply-To: <sMS_NiR-sAXCfMMh3uuXsNWHB0pGTWUEk3t4CcAYey0=.205069f3-e0e7-4e0f-bb6d-0d65abe9dc41@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <sMS_NiR-sAXCfMMh3uuXsNWHB0pGTWUEk3t4CcAYey0=.205069f3-e0e7-4e0f-bb6d-0d65abe9dc41@github.com>
Message-ID: <ZKI2NBwAs0auW0_42rzu363juezRPXy2TWhmsh3VM2Q=.5ea9db9f-fe32-4faa-b76f-fde931011204@github.com>

On Mon, 25 Aug 2025 14:29:08 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add queue locking on thread termination

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 185:

> 183:     }
> 184:     if (factor > 1) {
> 185:       u4 new_capacity = capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor;

NIT: Could use the MAX2 macro - no real functionality change, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2315328833

From jbechberger at openjdk.org  Tue Sep  2 14:08:25 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 2 Sep 2025 14:08:25 GMT
Subject: RFR: 8366486: Test
 jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out
Message-ID: <QrLWkI-3ZxvQF4Cx2HVcVQaCRykAQDXRqXJyfyD4mBY=.a155de35-8693-46d8-bf2f-d5c6326e87b6@github.com>

Fix test case by keeping the sampled thread alive long enough.

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

Commit messages:
 - Fix issue

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

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

From jbechberger at openjdk.org  Tue Sep  2 14:10:49 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 2 Sep 2025 14:10:49 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v2]
In-Reply-To: <ZKI2NBwAs0auW0_42rzu363juezRPXy2TWhmsh3VM2Q=.5ea9db9f-fe32-4faa-b76f-fde931011204@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <sMS_NiR-sAXCfMMh3uuXsNWHB0pGTWUEk3t4CcAYey0=.205069f3-e0e7-4e0f-bb6d-0d65abe9dc41@github.com>
 <ZKI2NBwAs0auW0_42rzu363juezRPXy2TWhmsh3VM2Q=.5ea9db9f-fe32-4faa-b76f-fde931011204@github.com>
Message-ID: <RIV1Z3iEeiC1pvfwdXFyI9Ve56WvbpHDJTFf347dvrQ=.3cd1f3a7-3875-4e51-b8c4-f3a2eaac2b31@github.com>

On Tue, 2 Sep 2025 08:29:13 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add queue locking on thread termination
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 185:
> 
>> 183:     }
>> 184:     if (factor > 1) {
>> 185:       u4 new_capacity = capacity * factor > CPU_TIME_QUEUE_MAX_CAPACITY ? CPU_TIME_QUEUE_MAX_CAPACITY : capacity * factor;
> 
> NIT: Could use the MAX2 macro - no real functionality change, though.

MIN2 :)

I didn't know these macros existed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2316213419

From jbechberger at openjdk.org  Wed Sep  3 11:41:32 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 3 Sep 2025 11:41:32 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v3]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <Ai23Wcprs3sBtHbymMrBlY1qDjmwc4FIEvt1IDD80Eg=.4e15307e-621a-493f-b6d9-a66d66e938ed@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Add test case and fix bug

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/97669fe5..cf65d57e

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

  Stats: 173 lines in 4 files changed: 172 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/26926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926

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

From jbechberger at openjdk.org  Wed Sep  3 14:22:44 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 3 Sep 2025 14:22:44 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <qSUpiA5KWqYjdnu2fhdurDwOjdeqA8kzHZ8FFt6YtzI=.b64a7d51-540e-46fc-968e-3a41255cf464@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Regarding files:

`-Xlog:jfr+startup=info:file=a.txt` causes the startup message to be written to the file, but `-Xlog:jfr+startup=warning:file=a.txt` doesn't.

So it works both for files and stdout, the implementation changes the behaviour at the root.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3249467266

From egahlin at openjdk.org  Wed Sep  3 14:35:53 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 3 Sep 2025 14:35:53 GMT
Subject: RFR: 8366809: JFR: Use factory for aggregator functions
Message-ID: <mCJ54xxQwrby3OJmmZ6U5W07T_FGErMhC9Kg5LhrtLQ=.3a578ef3-2372-4110-ae05-1ba68745d8d8@github.com>

Could I have a review of a PR that replaces the selection of the aggregator function with a factory, so that the selection only needs to happen once per column instead of for every row?

Testing: jdk/jdk/jfr + manual inspection 'jfr view' output

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From jbechberger at openjdk.org  Thu Sep  4 10:17:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 4 Sep 2025 10:17:02 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v4]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <axdnh03GeLsLh-8VzJ7QkvY3UlgW5urwtkABsnk1SzA=.35efdc90-9b20-42da-a7ba-e04e9e4c9a56@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Improve auto size test case

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/cf65d57e..57dc56ca

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

  Stats: 113 lines in 6 files changed: 81 ins; 19 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/26926.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26926/head:pull/26926

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

From jbechberger at openjdk.org  Thu Sep  4 10:23:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 4 Sep 2025 10:23:16 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v5]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <mtktXkz2F-2XMFH_mFu9rn83SOPNNUE41pmnMIMCc6w=.87d5de08-5ed4-49dd-a800-921f2e0bd0e8@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix last commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/57dc56ca..6bd7cd5c

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

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

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

From ysuenaga at openjdk.org  Thu Sep  4 11:34:54 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 4 Sep 2025 11:34:54 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
Message-ID: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.


$ jfr print --events jdk.CPUInformation test.jfr
jdk.CPUInformation {
  startTime = 10:49:27.692 (2025-09-04)
  cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
  description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi
 on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
  sockets = 1
  cores = 7
  hwThreads = 14
}


Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.

We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.

This patch sets `0` to `cores` and "Hybrid Architecture" is added to `description` as following if `jdk.CPUInformation` is generated on hybrid CPU. I want to set `-1` to `cores` TBH, but I didn't because `cores` is declared as `uint` - `-1` is equivalent with `UINT_MAX`, it looks like strange at here.


jdk.CPUInformation {
  startTime = 10:48:12.420 (2025-09-04)
  cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
  description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
Features: ebx: 0x42800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi
 on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC, Hybrid Architecture"
  sockets = 1
  cores = 0
  hwThreads = 14
}


This change affects showing information only, would not change the behavior like active processor count.

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

Commit messages:
 - Revert "Update condition"
 - Update condition
 - Add fallback code if logical_cpus == 0
 - 8365633: JFR reports incorrect number of cores on hybrid CPU

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

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

From ysuenaga at openjdk.org  Thu Sep  4 11:34:54 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 4 Sep 2025 11:34:54 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>

On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

src/hotspot/cpu/x86/vm_version_x86.cpp line 2581:

> 2579:     // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least)
> 2580:     threads_per_package = threads_per_core() * cores_per_cpu();
> 2581:   }

Check `thread_per_package` from `CPUID` to avoid SIGFPE (div by zero).

`CPUID` leaf 0Bh with ECX (subleaf) = 1 seems to return `0` as number of logical processors in spite of leaf 08h is supported in some older processors. It's strange, but I saw it on AMD EPYC 7763 on GitHub Actions runner. The problem appears as following.

I haven't faced this problem on AMD Ryzen 3 3300X.


#
# A fatal error has been detected by the Java Runtime Environment:
#
#  SIGFPE (0x8) at pc=0x00007f19e11ffeed, pid=11344, tid=11345
#
# JRE version: OpenJDK Runtime Environment (26.0) (build 26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420)
# Java VM: OpenJDK 64-Bit Server VM (26-internal-YaSuenag-ebf4aec23fa95c8d54d1196c7be85e99f0846420, mixed mode, sharing, tiered, compressed oops, compressed class ptrs, g1 gc, linux-amd64)
# Problematic frame:
# V  [libjvm.so+0x11ffeed]  VM_Version::initialize_cpu_information()+0x2d
#
# CreateCoredumpOnCrash turned off, no core file dumped
#
# JFR recording file will be written. Location: /home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/scratch/1/hs_err_pid11344.jfr
#
# If you would like to submit a bug report, please visit:
#   https://bugreport.java.com/bugreport/crash.jsp
#

---------------  S U M M A R Y ------------

Command Line: -Xmx768m -XX:MaxRAMPercentage=12.5 -Dtest.boot.jdk=/home/runner/work/jdk/jdk/bootjdk/jdk -Djava.io.tmpdir=/home/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part3/tmp -ea -esa -XX:-CreateCoredumpOnCrash -Xlog:jfr=trace -XX:StartFlightRecording:filename=./dumped.jfr,dumponexit=true,settings=profile jdk.jfr.startupargs.TestDumpOnExit$TestMain

Host: AMD EPYC 7763 64-Core Processor, 4 cores, 15G, Ubuntu 22.04.5 LTS
Time: Thu Sep  4 07:17:02 2025 UTC elapsed time: 0.570221 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread (0x00007f19d802ad20):  JavaThread "main"             [_thread_in_vm, id=11345, stack(0x00007f19dff00000,0x00007f19e0000000) (1024K)]

Stack: [0x00007f19dff00000,0x00007f19e0000000],  sp=0x00007f19dfffbd40,  free space=1007k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x11ffeed]  VM_Version::initialize_cpu_information()+0x2d  (vm_version_x86.cpp:2581)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2321741255

From egahlin at openjdk.org  Thu Sep  4 14:56:20 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 4 Sep 2025 14:56:20 GMT
Subject: RFR: 8366896: JFR: Add gc view support for ZGC
Message-ID: <mmKb8L4-OHgyL-vjGna6AbvzMXQIPNofEj7JIYvKG6c=.d2866325-3d61-46ff-b76d-f1c2dc043de1@github.com>

Could I have a review of a PR that fixes the 'jfr gc view' when using ZGC?

Could I have a review of a PR that fixes the 'jfr gc view' when using ZGC? The problem is that jdk.YoungGarbageCollection and jdk.OldGarbageCollection events are not used with ZGC. Instead, jdk.ZYoungGarbageCollection and jdk.ZOldGarbageCollection are used.

Before:
**$ jfr view gc recording.jfr**
    
                              Garbage Collections
    
    Start    GC ID Type                  Heap Before GC Heap After GC Longest Pause
    -------- ----- --------------------- -------------- ------------- -------------
    16:13:43     0 Unknown                     868.0 MB        1.6 GB    0.00808 ms
    16:13:43     1 Unknown                       1.7 GB        3.8 GB    0.00796 ms
    16:13:44     2 Unknown                       3.8 GB        9.0 GB     0.0136 ms
    16:13:45     3 Unknown                       6.6 GB        9.0 GB     0.0203 ms
    16:13:46     4 Unknown                       9.0 GB        9.0 GB    0.00867 ms
    16:13:48     5 Unknown                       9.0 GB        9.0 GB    0.00775 ms
 
 
 After:
 **$ jfr view gc recording.jfr**

                                       Garbage Collections
    
    Start    GC ID Type                         Heap Before GC Heap After GC Longest Pause
    -------- ----- ---------------------------- -------------- ------------- -------------
    16:13:43     0 ZGC Old Garbage Collection         868.0 MB        1.6 GB    0.00808 ms
    16:13:43     1 ZGC Old Garbage Collection           1.7 GB        3.8 GB    0.00796 ms
    16:13:44     2 ZGC Old Garbage Collection           3.8 GB        9.0 GB     0.0136 ms
    16:13:45     3 ZGC Young Garbage Collection         6.6 GB        9.0 GB     0.0203 ms
    16:13:46     4 ZGC Young Garbage Collection         9.0 GB        9.0 GB    0.00867 ms
    16:13:48     5 ZGC Young Garbage Collection         9.0 GB        9.0 GB    0.00775 ms

Note: "Unknown" can still occur if not all events for a GC ID have been emitted.

I also made a change so that GCs are now ordered according to GC ID. This prevents issues where entries with a start time of N/A appear first in cases where not all events are emitted for a GC cycle.

Testing: jdk/jdk/jfr + manual inspection with ZGC, G1, Parallel and Serial.

Thanks
Erik

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

Commit messages:
 - Order by GC id
 - Initial

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

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

From egahlin at openjdk.org  Thu Sep  4 15:08:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 4 Sep 2025 15:08:46 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <YH4HOVticFf84cM7om5wqSgxW_-50ssuwg3O65ZpTRw=.dba3e186-a1cb-46fe-a68c-523ff80862da@github.com>

On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

If a value is missing, emit jmc_undefined_long in event.set_cores(...), so it will show up as N/A in both JMC and the JFR tool.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3254159055

From ysuenaga at openjdk.org  Fri Sep  5 01:26:25 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Fri, 5 Sep 2025 01:26:25 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
In-Reply-To: <YH4HOVticFf84cM7om5wqSgxW_-50ssuwg3O65ZpTRw=.dba3e186-a1cb-46fe-a68c-523ff80862da@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <YH4HOVticFf84cM7om5wqSgxW_-50ssuwg3O65ZpTRw=.dba3e186-a1cb-46fe-a68c-523ff80862da@github.com>
Message-ID: <KThfk1AiQU-5xsK1Ucb2oKbhPxvHIOFNBkOF3-PD-J0=.58884c2d-ed27-4359-b275-2244ffcd60e4@github.com>

On Thu, 4 Sep 2025 15:06:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> If a value is missing, emit jmc_undefined_long in event.set_cores(...), so it will show up as N/A in both JMC and the JFR tool.

It couldn't for now because `cores` is declared as `uint`.

<Field type="uint" name="cores" label="Cores" />

I checked generated code from `metadata.xml`, the field as declared as `uint` (32 bit), so we cannot store `jmc_undefined_long` as `long`.

class EventCPUInformation : public JfrEvent<EventCPUInformation>
{
 private:
  const char* _cpu;
  const char* _description;
  unsigned _sockets;
  unsigned _cores;
  unsigned _hwThreads;


But I agree with @egahlin to show up "N/A" in this case. I think it is the most simple way to change data type to `long` for number of CPU cores in `metadata.xml`. Can we do that? I concern the impact for JFR recording data format.

As an another option, we can update `EventPrintWriter::getUnsigned` to handle `unsigned int` - it might be reasonable to fix this problem.

Which solution is better?

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3256751516

From jbechberger at openjdk.org  Fri Sep  5 08:00:50 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 08:00:50 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v6]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix build on non Linux

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/6bd7cd5c..d67261a7

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

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

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

From jbachorik at openjdk.org  Fri Sep  5 09:28:13 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Fri, 5 Sep 2025 09:28:13 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v6]
In-Reply-To: <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
Message-ID: <Bcp19leZBg79dhux9VSz841ZXvYTtjw0Oc0R4vYIyCk=.249b62c3-86d8-497e-b37d-854bb91cad68@github.com>

On Fri, 5 Sep 2025 08:00:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build on non Linux

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 289:

> 287:     return Atomic::load(&_out_of_stack_walking_iterations);
> 288:   }
> 289:   #endif

Should this be ASSERT of DEBUG_ONLY? 
Eg. the fields are defined via DEBUG_ONLY.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 86:

> 84:                                           .sum();
> 85:                 ret.add(new LossEvent(actualStart, lostSamples));
> 86:             }

NIT: This could be probably more efficient by bulding time quantized bucket

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324570334
PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324578773

From jbachorik at openjdk.org  Fri Sep  5 09:28:13 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Fri, 5 Sep 2025 09:28:13 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v6]
In-Reply-To: <Bcp19leZBg79dhux9VSz841ZXvYTtjw0Oc0R4vYIyCk=.249b62c3-86d8-497e-b37d-854bb91cad68@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
 <Bcp19leZBg79dhux9VSz841ZXvYTtjw0Oc0R4vYIyCk=.249b62c3-86d8-497e-b37d-854bb91cad68@github.com>
Message-ID: <ydKAZ3AN0A73mNx0nOMzeZeLlxDlS25yhmthDS4iIh8=.e48d82f4-1d9c-471e-8999-60dc50c0755f@github.com>

On Fri, 5 Sep 2025 09:22:02 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on non Linux
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 289:
> 
>> 287:     return Atomic::load(&_out_of_stack_walking_iterations);
>> 288:   }
>> 289:   #endif
> 
> Should this be ASSERT of DEBUG_ONLY? 
> Eg. the fields are defined via DEBUG_ONLY.

Hm, is this because of the definition in whitebox.cpp where we need if/else to return default value if not running with ASSERT ?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324573741

From jbechberger at openjdk.org  Fri Sep  5 09:28:14 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 09:28:14 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v6]
In-Reply-To: <ydKAZ3AN0A73mNx0nOMzeZeLlxDlS25yhmthDS4iIh8=.e48d82f4-1d9c-471e-8999-60dc50c0755f@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
 <Bcp19leZBg79dhux9VSz841ZXvYTtjw0Oc0R4vYIyCk=.249b62c3-86d8-497e-b37d-854bb91cad68@github.com>
 <ydKAZ3AN0A73mNx0nOMzeZeLlxDlS25yhmthDS4iIh8=.e48d82f4-1d9c-471e-8999-60dc50c0755f@github.com>
Message-ID: <gU_v-iEifLItHc5R3HbGnQjfVERpJFay9dII6InTn94=.a1c15206-fb1b-426c-b5fb-fc18b21d9d5a@github.com>

On Fri, 5 Sep 2025 09:23:34 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 289:
>> 
>>> 287:     return Atomic::load(&_out_of_stack_walking_iterations);
>>> 288:   }
>>> 289:   #endif
>> 
>> Should this be ASSERT of DEBUG_ONLY? 
>> Eg. the fields are defined via DEBUG_ONLY.
>
> Hm, is this because of the definition in whitebox.cpp where we need if/else to return default value if not running with ASSERT ?

Per definition of the macros it's the same

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324574706

From jbechberger at openjdk.org  Fri Sep  5 09:28:14 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 09:28:14 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v6]
In-Reply-To: <gU_v-iEifLItHc5R3HbGnQjfVERpJFay9dII6InTn94=.a1c15206-fb1b-426c-b5fb-fc18b21d9d5a@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
 <Bcp19leZBg79dhux9VSz841ZXvYTtjw0Oc0R4vYIyCk=.249b62c3-86d8-497e-b37d-854bb91cad68@github.com>
 <ydKAZ3AN0A73mNx0nOMzeZeLlxDlS25yhmthDS4iIh8=.e48d82f4-1d9c-471e-8999-60dc50c0755f@github.com>
 <gU_v-iEifLItHc5R3HbGnQjfVERpJFay9dII6InTn94=.a1c15206-fb1b-426c-b5fb-fc18b21d9d5a@github.com>
Message-ID: <x-El6EVKf9guAiLmXuCL6KX1vVZTDgcldGdzs7fMR3w=.1c6b2800-a347-458d-9f63-1036c51b1a0e@github.com>

On Fri, 5 Sep 2025 09:24:04 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Hm, is this because of the definition in whitebox.cpp where we need if/else to return default value if not running with ASSERT ?
>
> Per definition of the macros it's the same

DEBUG_ONLY is apparently the short version of ?ifdef ASSERT'

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324577412

From jbechberger at openjdk.org  Fri Sep  5 09:32:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 09:32:16 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v6]
In-Reply-To: <Bcp19leZBg79dhux9VSz841ZXvYTtjw0Oc0R4vYIyCk=.249b62c3-86d8-497e-b37d-854bb91cad68@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
 <Bcp19leZBg79dhux9VSz841ZXvYTtjw0Oc0R4vYIyCk=.249b62c3-86d8-497e-b37d-854bb91cad68@github.com>
Message-ID: <mVLhXWa4H0f4NBmTTv4x40QLnZgIEwquoTGxQXrw0wI=.29360ef1-5e24-41ef-b36d-fd43aacf05b6@github.com>

On Fri, 5 Sep 2025 09:25:56 GMT, Jaroslav Bachorik <jbachorik at openjdk.org> wrote:

>> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix build on non Linux
>
> test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 86:
> 
>> 84:                                           .sum();
>> 85:                 ret.add(new LossEvent(actualStart, lostSamples));
>> 86:             }
> 
> NIT: This could be probably more efficient by bulding time quantized bucket

Sure. But I'm only getting 10 or so events, so I didn't think it would be worth it

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26926#discussion_r2324587444

From jbachorik at openjdk.org  Fri Sep  5 10:15:32 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Fri, 5 Sep 2025 10:15:32 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v6]
In-Reply-To: <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <bXnGuDH6uacywrtaGp7W0WE5K7r1D9ASyJjeDOGLKu0=.e5c37fde-5224-4c27-aac4-dec4e4bb0784@github.com>
Message-ID: <nKHDlJGnhyxeSACPQh22xm4ZsuPev8otEgLuP87ynqY=.cdc3bd0a-b393-418c-a4ab-dc7d8f01d73f@github.com>

On Fri, 5 Sep 2025 08:00:50 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build on non Linux

I have a few more minor questions/nits

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

PR Review: https://git.openjdk.org/jdk/pull/26926#pullrequestreview-3188765342

From jbechberger at openjdk.org  Fri Sep  5 10:46:39 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 10:46:39 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v7]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <U4lEucOYWdUjomxELJos4SQjWNEfq_59MgzifB3GVyw=.47362712-0993-485f-a090-9227cbf9b45a@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/d67261a7..fa60329a

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

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

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

From jbechberger at openjdk.org  Fri Sep  5 11:19:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 11:19:54 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v8]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <h4yopqepimz5VfFH72b32ehjxjvIsmpEHS3afOkKjcM=.b7cb6b92-9a6b-4f89-9228-888fe8880194@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix headers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/fa60329a..7e902494

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

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

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

From jbechberger at openjdk.org  Fri Sep  5 11:29:11 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 11:29:11 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v8]
In-Reply-To: <h4yopqepimz5VfFH72b32ehjxjvIsmpEHS3afOkKjcM=.b7cb6b92-9a6b-4f89-9228-888fe8880194@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <h4yopqepimz5VfFH72b32ehjxjvIsmpEHS3afOkKjcM=.b7cb6b92-9a6b-4f89-9228-888fe8880194@github.com>
Message-ID: <Jd979DsqZWe54lKh3d-0extrzmWZ3IADU2_gpkw1P0c=.496f2ccd-bf9c-497c-be14-97e9d5ca9c2a@github.com>

On Fri, 5 Sep 2025 11:19:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix headers

I'm looking forward to your nits :)

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

PR Comment: https://git.openjdk.org/jdk/pull/26926#issuecomment-3258016760

From jbechberger at openjdk.org  Fri Sep  5 11:41:29 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 5 Sep 2025 11:41:29 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v9]
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <gDcHM4i8_9kXv8Uu73nAfiospVdn8QaPXuH823liz4Q=.a2212d59-5dc1-447d-96da-c6be53ca545a@github.com>

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Fix usage of INCLUDE_JFR

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26926/files
  - new: https://git.openjdk.org/jdk/pull/26926/files/7e902494..cab51632

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

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

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

From egahlin at openjdk.org  Mon Sep  8 20:21:48 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 8 Sep 2025 20:21:48 GMT
Subject: RFR: 8367107: JFR: Refactor policy tests out of TestRemoteDump
Message-ID: <wh6psCWgzj600LUmxYJ3gx4COfBRpsdPkXoPUrK-OCU=.85fe9c08-6855-4d6b-af5b-fc3b97e0c04b@github.com>

Could I get a review of a PR that splits TestRemoteDump.java into two test files?

This change prevents timeouts and reduces wall clock time, as the tests can now run in parallel. As part of the change, I am reverting the modification to TestRemoteDump introduced with [JFR: Improve slow tests](https://bugs.openjdk.org/browse/JDK-8364756), which made the test flaky. I also removed unused imports and fixed the incorrect test summary.

Testing: 100 * (TestRemoteDump and TestDumpRetention)

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From ysuenaga at openjdk.org  Tue Sep  9 08:29:09 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Sep 2025 08:29:09 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v2]
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <gWmRTDDImw-XscG36RwOO2YvMVjECB6LU_Sv-S1tMEw=.08215632-5242-48b3-9e8b-1f3e5cffb915@github.com>

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:

  Use jmc_undefined_long if runs on hybrid CPU

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27080/files
  - new: https://git.openjdk.org/jdk/pull/27080/files/7ac3885f..2ebbde5f

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

  Stats: 16 lines in 4 files changed: 7 ins; 4 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27080/head:pull/27080

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

From ysuenaga at openjdk.org  Tue Sep  9 08:29:10 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Sep 2025 08:29:10 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <FNi_b6S3B15biVDqpfrgGRhc7ijYGtQ7R1IEAvgIUFA=.7887f146-adde-46c3-bd04-1db8195594f7@github.com>

On Thu, 4 Sep 2025 02:15:01 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

I updated this patch to set `jmc_undefined_long` if runs on hybrid CPU. It passed jdk_jfr test on my laptop.

@egahlin Can you review?

You can see `jdk.CPUInformation` event generated on hybrid CPU as following:

jdk.CPUInformation {
  startTime = 16:15:19.185 (2025-09-09)
  cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
  description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
Features: ebx: 0x10800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instructi
 on, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC, Hybrid Architecture"
  sockets = 1
  cores = N/A
  hwThreads = 14
}

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3269483510

From jbachorik at openjdk.org  Tue Sep  9 10:07:12 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Tue, 9 Sep 2025 10:07:12 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v9]
In-Reply-To: <gDcHM4i8_9kXv8Uu73nAfiospVdn8QaPXuH823liz4Q=.a2212d59-5dc1-447d-96da-c6be53ca545a@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <gDcHM4i8_9kXv8Uu73nAfiospVdn8QaPXuH823liz4Q=.a2212d59-5dc1-447d-96da-c6be53ca545a@github.com>
Message-ID: <Vcb4bsscyxELRKRPmpBwFyXMLRrqAoxRtEoD3KDsiuQ=.a130b5c0-84be-40cb-8c08-5f8248a664bc@github.com>

On Fri, 5 Sep 2025 11:41:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix usage of INCLUDE_JFR

Marked as reviewed by jbachorik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26926#pullrequestreview-3200624714

From jbachorik at openjdk.org  Tue Sep  9 10:12:25 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Tue, 9 Sep 2025 10:12:25 GMT
Subject: RFR: 8366486: Test
 jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out
In-Reply-To: <QrLWkI-3ZxvQF4Cx2HVcVQaCRykAQDXRqXJyfyD4mBY=.a155de35-8693-46d8-bf2f-d5c6326e87b6@github.com>
References: <QrLWkI-3ZxvQF4Cx2HVcVQaCRykAQDXRqXJyfyD4mBY=.a155de35-8693-46d8-bf2f-d5c6326e87b6@github.com>
Message-ID: <q-jagLUQYACftnt9z__US1jbJebbxnQeZYurrRGClg8=.afdbbcbb-e364-4ebe-a7bf-e2ab854cdf8d@github.com>

On Tue, 2 Sep 2025 14:01:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fix test case by keeping the sampled thread alive long enough.

Marked as reviewed by jbachorik (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27053#pullrequestreview-3200653261

From jbechberger at openjdk.org  Tue Sep  9 10:18:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 9 Sep 2025 10:18:53 GMT
Subject: Integrated: 8366486: Test
 jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out
In-Reply-To: <QrLWkI-3ZxvQF4Cx2HVcVQaCRykAQDXRqXJyfyD4mBY=.a155de35-8693-46d8-bf2f-d5c6326e87b6@github.com>
References: <QrLWkI-3ZxvQF4Cx2HVcVQaCRykAQDXRqXJyfyD4mBY=.a155de35-8693-46d8-bf2f-d5c6326e87b6@github.com>
Message-ID: <XaUmVVgJx0kQ3hTJa8bL_s7uSpWcagA9Nco_bzol08k=.85dfcf9d-e018-4a62-8cea-7e50510ca892@github.com>

On Tue, 2 Sep 2025 14:01:23 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Fix test case by keeping the sampled thread alive long enough.

This pull request has now been integrated.

Changeset: 4fc917c2
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4fc917c25005d1f88fe43069fe623e243bd022c3
Stats:     8 lines in 1 file changed: 1 ins; 5 del; 2 mod

8366486: Test jdk/jfr/event/profiling/TestCPUTimeSampleMultipleRecordings.java is timing out

Reviewed-by: jbachorik

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

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

From jbechberger at openjdk.org  Tue Sep  9 10:20:02 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 9 Sep 2025 10:20:02 GMT
Subject: Integrated: 8366082: Improve queue size computation in CPU-time
 sampler
In-Reply-To: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
Message-ID: <YpdbPfFcpMeMEIOkX9Qq2hoGIepKVFyv-AMmu8LlrC0=.aa0e1734-41c8-4b82-8a0f-1d7cbd808d08@github.com>

On Mon, 25 Aug 2025 12:41:11 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.

This pull request has now been integrated.

Changeset: 002f936e
Author:    Johannes Bechberger <jbechberger at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/002f936ef21943ff1c8c03618091793768e756ac
Stats:     299 lines in 7 files changed: 276 ins; 7 del; 16 mod

8366082: Improve queue size computation in CPU-time sampler

Reviewed-by: jbachorik

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

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

From egahlin at openjdk.org  Tue Sep  9 10:34:09 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 9 Sep 2025 10:34:09 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v2]
In-Reply-To: <gWmRTDDImw-XscG36RwOO2YvMVjECB6LU_Sv-S1tMEw=.08215632-5242-48b3-9e8b-1f3e5cffb915@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <gWmRTDDImw-XscG36RwOO2YvMVjECB6LU_Sv-S1tMEw=.08215632-5242-48b3-9e8b-1f3e5cffb915@github.com>
Message-ID: <rNZPWDr4-JS1vL56xmMjXW7fqpJ1AQVRtW27JMAuw60=.71054c0f-d290-49eb-9db0-1c48ec3d7c98@github.com>

On Tue, 9 Sep 2025 08:29:09 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
>> 
>> 
>> $ jfr print --events jdk.CPUInformation test.jfr
>> jdk.CPUInformation {
>>   startTime = 10:49:27.692 (2025-09-04)
>>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
>> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
>> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
>> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
>> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
>> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instru
 ction, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>>   sockets = 1
>>   cores = 7
>>   hwThreads = 14
>> }
>> 
>> 
>> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
>> 
>> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
>> 
>> This patc...
>
> Yasumasa Suenaga has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use jmc_undefined_long if runs on hybrid CPU

It should not be a problem to change to type long. Values are stored as compressed integers, but you might want to check the event in JMC just to be sure. Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores").

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270024207

From ysuenaga at openjdk.org  Tue Sep  9 11:04:34 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Sep 2025 11:04:34 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v2]
In-Reply-To: <rNZPWDr4-JS1vL56xmMjXW7fqpJ1AQVRtW27JMAuw60=.71054c0f-d290-49eb-9db0-1c48ec3d7c98@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <gWmRTDDImw-XscG36RwOO2YvMVjECB6LU_Sv-S1tMEw=.08215632-5242-48b3-9e8b-1f3e5cffb915@github.com>
 <rNZPWDr4-JS1vL56xmMjXW7fqpJ1AQVRtW27JMAuw60=.71054c0f-d290-49eb-9db0-1c48ec3d7c98@github.com>
Message-ID: <lNRncIpjPMEYoyy7y8Xa34X35cVBI10UusqP5Wc1zyM=.a5f4733c-44c7-4d13-9a12-7bae68da1b97@github.com>

On Tue, 9 Sep 2025 10:27:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> you might want to check the event in JMC just to be sure. 

I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC.

<img width="812" height="340" alt="image" src="https://github.com/user-attachments/assets/1919ac46-77c5-4658-8fa1-8aea7aa6bef2" />


> Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores").

I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270165692

From egahlin at openjdk.org  Tue Sep  9 11:35:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 9 Sep 2025 11:35:10 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v2]
In-Reply-To: <lNRncIpjPMEYoyy7y8Xa34X35cVBI10UusqP5Wc1zyM=.a5f4733c-44c7-4d13-9a12-7bae68da1b97@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <gWmRTDDImw-XscG36RwOO2YvMVjECB6LU_Sv-S1tMEw=.08215632-5242-48b3-9e8b-1f3e5cffb915@github.com>
 <rNZPWDr4-JS1vL56xmMjXW7fqpJ1AQVRtW27JMAuw60=.71054c0f-d290-49eb-9db0-1c48ec3d7c98@github.com>
 <lNRncIpjPMEYoyy7y8Xa34X35cVBI10UusqP5Wc1zyM=.a5f4733c-44c7-4d13-9a12-7bae68da1b97@github.com>
Message-ID: <cH-4LWzSO72_B88RK49RMhT4skrP_QkFy5gE8XIcs5g=.97212c3b-fabe-43d1-b4c9-632373ab0d78@github.com>

On Tue, 9 Sep 2025 11:01:32 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC.

Interesting, it has worked in the past.

> I hope the problem would be found by jdk_jfr tests

Try to add:

    +           event.getInt("cores");
    +           Integer value = event.getValue("cores");
 
to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value.

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270271752

From ysuenaga at openjdk.org  Tue Sep  9 11:58:56 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Sep 2025 11:58:56 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v2]
In-Reply-To: <cH-4LWzSO72_B88RK49RMhT4skrP_QkFy5gE8XIcs5g=.97212c3b-fabe-43d1-b4c9-632373ab0d78@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <gWmRTDDImw-XscG36RwOO2YvMVjECB6LU_Sv-S1tMEw=.08215632-5242-48b3-9e8b-1f3e5cffb915@github.com>
 <rNZPWDr4-JS1vL56xmMjXW7fqpJ1AQVRtW27JMAuw60=.71054c0f-d290-49eb-9db0-1c48ec3d7c98@github.com>
 <lNRncIpjPMEYoyy7y8Xa34X35cVBI10UusqP5Wc1zyM=.a5f4733c-44c7-4d13-9a12-7bae68da1b97@github.com>
 <cH-4LWzSO72_B88RK49RMhT4skrP_QkFy5gE8XIcs5g=.97212c3b-fabe-43d1-b4c9-632373ab0d78@github.com>
Message-ID: <HpBEeUJUgMQgE5ULKbfoDLBlyTXLv40vkeZUZx93ev8=.27f7c291-7b44-46cb-b8f8-ee431e1ce24a@github.com>

On Tue, 9 Sep 2025 11:32:20 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>>> you might want to check the event in JMC just to be sure. 
>> 
>> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC.
>> 
>> <img width="812" height="340" alt="image" src="https://github.com/user-attachments/assets/1919ac46-77c5-4658-8fa1-8aea7aa6bef2" />
>> 
>> 
>>> Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores").
>> 
>> I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box.
>
>> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC.
> 
> Interesting, it has worked in the past.
> 
>> I hope the problem would be found by jdk_jfr tests
> 
> Try to add:
> 
>     +           event.getInt("cores");
>     +           Integer value = event.getValue("cores");
>  
> to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value.

@egahlin 

`event.getInt("cores")`: failed

java.lang.IllegalArgumentException: Attempt to get field "cores" with illegal data type conversion int
        at jdk.jfr/jdk.jfr.consumer.RecordedObject.newIllegalArgumentException(RecordedObject.java:890)
        at jdk.jfr/jdk.jfr.consumer.RecordedObject.getInt(RecordedObject.java:553)
        at jdk.jfr.event.os.TestCPUInformation.main(TestCPUInformation.java:56)
        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:1474)


`Integer value = event.getValue("cores")`: failed

java.lang.ClassCastException: class java.lang.Long cannot be cast to class java.lang.Integer (java.lang.Long and java.lang.Integer are in module java.base of loader 'bootstrap')
        at jdk.jfr.event.os.TestCPUInformation.main(TestCPUInformation.java:57)
        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:1474)

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3270354691

From ysuenaga at openjdk.org  Tue Sep  9 13:47:45 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 9 Sep 2025 13:47:45 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
Message-ID: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>

> On hybrid CPU like Intel Arrow Lake, JFR reports incorrect number of cores in `jdk.CPUInformation`.
> 
> 
> $ jfr print --events jdk.CPUInformation test.jfr
> jdk.CPUInformation {
>   startTime = 10:49:27.692 (2025-09-04)
>   cpu = "Intel (null) (HT) SSE SSE2 SSE3 SSSE3 SSE4.1 SSE4.2 Core Intel64"
>   description = "Brand: Intel(R) Core(TM) Ultra 5 225U, Vendor: GenuineIntel
> Family: <unknown> (0x6), Model: <unknown> (0xb5), Stepping: 0x0
> Ext. family: 0x0, Ext. model: 0xb, Type: 0x0, Signature: 0x000b0650
> Features: ebx: 0x40800800, ecx: 0xfffaf38b, edx: 0xbfcbfbff
> Ext. features: eax: 0x00000000, ebx: 0x00000000, ecx: 0x00000121, edx: 0x2c100800
> Supports: On-Chip FPU, Virtual Mode Extensions, Debugging Extensions, Page Size Extensions, Time Stamp Counter, Model Specific Registers, Physical Address Extension, Machine Check Exceptions, CMPXCHG8B Instruction, On-Chip APIC, Fast System Call, Memory Type Range Registers, Page Global Enable, Machine Check Architecture, Conditional Mov Instruction, Page Attribute Table, 36-bit Page Size Extension, CLFLUSH Instruction, ACPI registers in MSR space, Intel Architecture MMX Technology, Fast Float Point Save and Restore, Streaming SIMD extensions, Streaming SIMD extensions 2, Self-Snoop, Hyper Threading, Thermal Monitor, Streaming SIMD Extensions 3, PCLMULQDQ, MONITOR/MWAIT instructions, Enhanced Intel SpeedStep technology, Thermal Monitor 2, Supplemental Streaming SIMD Extensions 3, Fused Multiply-Add, CMPXCHG16B, xTPR Update Control, Perfmon and Debug Capability, Process-context identifiers, Streaming SIMD extensions 4.1, Streaming SIMD extensions 4.2, x2APIC, MOVBE, Popcount instruc
 tion, TSC-Deadline, AESNI, XSAVE, OSXSAVE, AVX, F16C, LAHF/SAHF instruction support, Advanced Bit Manipulations: LZCNT, SYSCALL/SYSRET, Execute Disable Bit, RDTSCP, Intel 64 Architecture, Invariant TSC"
>   sockets = 1
>   cores = 7
>   hwThreads = 14
> }
> 
> 
> Flight record in above was created on Intel Core Ultra 5 225U. According to [datasheet](https://www.intel.com/content/www/us/en/products/sku/241861/intel-core-ultra-5-processor-225u-12m-cache-up-to-4-80-ghz/specifications.html), it has 12 cores, 14 threads. Thus JFR should report `12` in `cores`.
> 
> We tackled similar issue on [JDK-8365633](https://bugs.openjdk.org/browse/JDK-8365633), then we concluded it is difficult to calculate number of physical cores. Thus we might not set correct value at here, but we should avoid to set incorrect value at least.
> 
> This patch sets `0` to `cores` and "Hybrid Architecture" ...

Yasumasa Suenaga has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into jfr-on-hy-cpu
 - Use jmc_undefined_long if runs on hybrid CPU
 - Revert "Update condition"
   
   This reverts commit ebf4aec23fa95c8d54d1196c7be85e99f0846420.
 - Update condition
 - Add fallback code if logical_cpus == 0
 - 8365633: JFR reports incorrect number of cores on hybrid CPU

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27080/files
  - new: https://git.openjdk.org/jdk/pull/27080/files/2ebbde5f..aeea3fb0

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

  Stats: 14182 lines in 512 files changed: 6597 ins; 4715 del; 2870 mod
  Patch: https://git.openjdk.org/jdk/pull/27080.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27080/head:pull/27080

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

From dholmes at openjdk.org  Wed Sep 10 06:15:29 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 10 Sep 2025 06:15:29 GMT
Subject: RFR: 8366082: Improve queue size computation in CPU-time sampler
 [v9]
In-Reply-To: <gDcHM4i8_9kXv8Uu73nAfiospVdn8QaPXuH823liz4Q=.a2212d59-5dc1-447d-96da-c6be53ca545a@github.com>
References: <sUrfUbGYr7sely-KVGMbavYsPwkgKH4hFAZPhVtEk3s=.1f0762ec-2dc8-4a2c-ab20-afe3327607c8@github.com>
 <gDcHM4i8_9kXv8Uu73nAfiospVdn8QaPXuH823liz4Q=.a2212d59-5dc1-447d-96da-c6be53ca545a@github.com>
Message-ID: <xchaJJPvW2AeIe1-qmi04rf08gPFgO-usj_EAmXLq0Q=.d64edc2e-0b89-4453-b168-600b912f1c66@github.com>

On Fri, 5 Sep 2025 11:41:29 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> Improve the sample queue size computation for the CPU-time sampler by increasing the size dynamically when needed, but keeping the default size small.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix usage of INCLUDE_JFR

The new test is failing in our CI. I will file a bug and assign it to you.

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

PR Comment: https://git.openjdk.org/jdk/pull/26926#issuecomment-3273454107

From jbechberger at openjdk.org  Wed Sep 10 10:58:34 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Wed, 10 Sep 2025 10:58:34 GMT
Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler
Message-ID: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>

Remove acq-rel semantics where it isn't needed.

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

Commit messages:
 - Remove unnecessary line
 - Remove redundant synchronization

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

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

From mdoerr at openjdk.org  Fri Sep 12 20:46:24 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Fri, 12 Sep 2025 20:46:24 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <vt3ZUDr6KvxtqcN3dvYUV6Nrgc3_ctHeZvNrZ7Vyoxg=.101f4eec-fe03-4e1e-a431-b072091c21a6@github.com>

On Wed, 27 Aug 2025 12:07:54 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

This PR needs an update since `Atomic` has been renamed to `AtomicAccess`.

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

PR Comment: https://git.openjdk.org/jdk/pull/26957#issuecomment-3286765432

From jbechberger at openjdk.org  Mon Sep 15 09:31:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 15 Sep 2025 09:31:27 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning [v2]
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <lUsJpO0Xk9mPoJOvexhw7BN1JT1tNvFf7YnFIuxS9Q0=.49185bd6-cf12-4b3b-9873-35d09931d05c@github.com>

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into parttimenerd_fix_startup
 - Fix startup message printing

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26957/files
  - new: https://git.openjdk.org/jdk/pull/26957/files/95c47b2a..56cef57f

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

  Stats: 46693 lines in 1755 files changed: 26974 ins; 11155 del; 8564 mod
  Patch: https://git.openjdk.org/jdk/pull/26957.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26957/head:pull/26957

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

From jbechberger at openjdk.org  Mon Sep 15 09:32:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Mon, 15 Sep 2025 09:32:54 GMT
Subject: RFR: 8366232: JFR startup messages are shown with
 -Xlog:jfr+startup=warning [v3]
In-Reply-To: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
References: <qkEgiV-tg_ggShVsp_m3aWy9VWhxgfig3ik5KzruO6U=.5c35e852-2a09-4794-8787-acffdba806ec@github.com>
Message-ID: <JJKhKwC29uyPBTdUGTIi6OZB4VlYYqu6LjhMeIJlqKQ=.f9f46a9d-a9e0-4224-947d-72d1f3dece08@github.com>

> Only print the JFR startup messages when no or a < warning log level is set explicitly by the user.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Rename Atomic:: to AtomicAccess::

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26957/files
  - new: https://git.openjdk.org/jdk/pull/26957/files/56cef57f..4b827459

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

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

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

From mgronlun at openjdk.org  Mon Sep 15 13:29:00 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 15 Sep 2025 13:29:00 GMT
Subject: RFR: 8367107: JFR: Refactor policy tests out of TestRemoteDump
In-Reply-To: <wh6psCWgzj600LUmxYJ3gx4COfBRpsdPkXoPUrK-OCU=.85fe9c08-6855-4d6b-af5b-fc3b97e0c04b@github.com>
References: <wh6psCWgzj600LUmxYJ3gx4COfBRpsdPkXoPUrK-OCU=.85fe9c08-6855-4d6b-af5b-fc3b97e0c04b@github.com>
Message-ID: <wncPGpmlXFle0AAJTCWGV_Nus5c_VEpEXEYVEEKyOc8=.0c6fa94c-9072-458d-a1e7-7dbf959130d8@github.com>

On Mon, 8 Sep 2025 20:10:59 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I get a review of a PR that splits TestRemoteDump.java into two test files?
> 
> This change prevents timeouts and reduces wall clock time, as the tests can now run in parallel. As part of the change, I am reverting the modification to TestRemoteDump introduced with [JFR: Improve slow tests](https://bugs.openjdk.org/browse/JDK-8364756), which made the test flaky. I also removed unused imports and fixed the incorrect test summary.
> 
> Testing: 100 * (TestRemoteDump and TestDumpRetention)
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27153#pullrequestreview-3224605742

From ysuenaga at openjdk.org  Tue Sep 16 13:25:44 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 16 Sep 2025 13:25:44 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v2]
In-Reply-To: <cH-4LWzSO72_B88RK49RMhT4skrP_QkFy5gE8XIcs5g=.97212c3b-fabe-43d1-b4c9-632373ab0d78@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <gWmRTDDImw-XscG36RwOO2YvMVjECB6LU_Sv-S1tMEw=.08215632-5242-48b3-9e8b-1f3e5cffb915@github.com>
 <rNZPWDr4-JS1vL56xmMjXW7fqpJ1AQVRtW27JMAuw60=.71054c0f-d290-49eb-9db0-1c48ec3d7c98@github.com>
 <lNRncIpjPMEYoyy7y8Xa34X35cVBI10UusqP5Wc1zyM=.a5f4733c-44c7-4d13-9a12-7bae68da1b97@github.com>
 <cH-4LWzSO72_B88RK49RMhT4skrP_QkFy5gE8XIcs5g=.97212c3b-fabe-43d1-b4c9-632373ab0d78@github.com>
Message-ID: <cHwDOdOxHrZYbzi6l1790rAjwNumLdqdjAD2hA_exOA=.81365f6f-34f5-4653-b8da-5964c09baed7@github.com>

On Tue, 9 Sep 2025 11:32:20 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>>> you might want to check the event in JMC just to be sure. 
>> 
>> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC.
>> 
>> <img width="812" height="340" alt="image" src="https://github.com/user-attachments/assets/1919ac46-77c5-4658-8fa1-8aea7aa6bef2" />
>> 
>> 
>>> Problem might be the API, e.g. int cores = event.getInt("cores") or Integer cores = event.getValue("cores").
>> 
>> I hope the problem would be found by jdk_jfr tests - it passed on both GHA and my Linux box.
>
>> I checked the flight record, but JMC 9.1 showed raw min_jlong value. I think it is a problem on JMC.
> 
> Interesting, it has worked in the past.
> 
>> I hope the problem would be found by jdk_jfr tests
> 
> Try to add:
> 
>     +           event.getInt("cores");
>     +           Integer value = event.getValue("cores");
>  
> to TestCPUInformation.java. There's no need to check in the changes, but it would be good to know what happens if it is a long value.

@egahlin Could you review?

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

PR Comment: https://git.openjdk.org/jdk/pull/27080#issuecomment-3296425149

From krk at openjdk.org  Tue Sep 16 16:12:36 2025
From: krk at openjdk.org (Kerem Kat)
Date: Tue, 16 Sep 2025 16:12:36 GMT
Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler
In-Reply-To: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
References: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
Message-ID: <d8RIxkrQ1kM8Sel6D1n48rl9AD7P1aSWhprHMx1GlhA=.ad9332fb-f92e-46ef-9886-889a82286670@github.com>

On Wed, 27 Aug 2025 12:50:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Remove acq-rel semantics where it isn't needed.

src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 169:

> 167:   }
> 168:   if (_capacity < CPU_TIME_QUEUE_MAX_CAPACITY) {
> 169:     float ratio = (float)lost_samples_due_to_queue_full / (float)_capacity;

Can `_capacity` be zero here now?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26960#discussion_r2352999805

From jbechberger at openjdk.org  Tue Sep 16 16:20:19 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 16 Sep 2025 16:20:19 GMT
Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler
In-Reply-To: <d8RIxkrQ1kM8Sel6D1n48rl9AD7P1aSWhprHMx1GlhA=.ad9332fb-f92e-46ef-9886-889a82286670@github.com>
References: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
 <d8RIxkrQ1kM8Sel6D1n48rl9AD7P1aSWhprHMx1GlhA=.ad9332fb-f92e-46ef-9886-889a82286670@github.com>
Message-ID: <EfRkUzKxwxtSw6Uc32A76bSa-s-yJnPESU0UE6OKkqs=.595f0e82-599a-4d23-8124-8d59b44104ad@github.com>

On Tue, 16 Sep 2025 16:09:19 GMT, Kerem Kat <krk at openjdk.org> wrote:

>> Remove acq-rel semantics where it isn't needed.
>
> src/hotspot/share/jfr/periodic/sampling/jfrCPUTimeThreadSampler.cpp line 169:
> 
>> 167:   }
>> 168:   if (_capacity < CPU_TIME_QUEUE_MAX_CAPACITY) {
>> 169:     float ratio = (float)lost_samples_due_to_queue_full / (float)_capacity;
> 
> Can `_capacity` be zero here now?

No, because _capacity is always increasing and starts with `20`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/26960#discussion_r2353017471

From dholmes at openjdk.org  Wed Sep 17 21:29:59 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 17 Sep 2025 21:29:59 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <93ro1DNd1rt6ugTIpPqFl15-9ZcUzT3LW4J7TV9lAgc=.50b7e0a7-f805-4a9c-b780-56ca27085abb@github.com>

On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This change hopefully fixes the test failures by making the test cases more resilient.

Added hotspot-jfr label

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3304617964

From egahlin at openjdk.org  Wed Sep 17 21:43:25 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 17 Sep 2025 21:43:25 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <9XVUwAuoeQY1SlNtUkKK7y3K16raaY_vbN2GpNT2baU=.dbed2741-5029-485e-927a-97f661534967@github.com>

On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This change hopefully fixes the test failures by making the test cases more resilient.

This test causes noise. Can @jbachorik or @apangin take a look?

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3304646592

From apangin at openjdk.org  Thu Sep 18 02:09:35 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Thu, 18 Sep 2025 02:09:35 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>

On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This change hopefully fixes the test failures by making the test cases more resilient.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 99:

> 97:     }
> 98: 
> 99:     public static void main(String[] args) throws Exception {

A brief high-level explanation of what the test does would be useful.
>From what I understood, the test starts CPU time sampling with a short interval (1ms), temporarily disables processing of native samples to cause queue overflow, then enables it back to report lost samples. Repeats the cycle 5 times and verifies that the queue has grown by the time of the last iteration, thereby decreasing the amount of losses.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 103:

> 101:             // setup recording
> 102:             AtomicLong burstThreadId = new AtomicLong();
> 103:             final long startTimeMillis = System.currentTimeMillis();

Do not use `System.currentTimeMillis()` for time intervals: 1) it suffers from rounding errors due to low resolution; 2) it is not guaranteed to be monotonic. Use `System.nanoTime()` or `Instant.now()` instead.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 119:

> 117:             rs.startAsync();
> 118:             // this thread runs all along
> 119:             Thread burstThread = new Thread(() -> WHITE_BOX.busyWaitCPUTime(8000));

Instead of having a magic constant, is it possible to run `busyWaitCPUTime` continuously until explicitly stopped?

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 154:

> 152:         ThreadMXBean bean = ManagementFactory.getThreadMXBean();
> 153:         long start = bean.getCurrentThreadCpuTime();
> 154:         while (bean.getCurrentThreadCpuTime() - start < millis * 1_000_000) {

Isn't this method supposed to check CPU time of the passed `thread` rather than current thread?

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 165:

> 163:         }
> 164:         // check that there are at least 3 time boxes
> 165:         Asserts.assertTrue(timeBoxedLosses.size() > 3);

Not sure what this assert means. From what I see, the size of `timeBoxedLosses` should be exactly equal to the number of main loop iterations (5).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357301273
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357230947
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357285587
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357280422
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357246767

From apangin at openjdk.org  Thu Sep 18 02:09:36 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Thu, 18 Sep 2025 02:09:36 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
Message-ID: <9faaJWDTc4hOBRJ5p1ZZcX879KV1385Njd4IAL7Bu-c=.3cc8526c-a553-446f-8c90-8cc7c446a437@github.com>

On Thu, 18 Sep 2025 01:55:28 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 154:
> 
>> 152:         ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>> 153:         long start = bean.getCurrentThreadCpuTime();
>> 154:         while (bean.getCurrentThreadCpuTime() - start < millis * 1_000_000) {
> 
> Isn't this method supposed to check CPU time of the passed `thread` rather than current thread?

BTW, is there a specific reason to burn cpu in a separate thread? It can be done in the same `main` thread, isn't it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2357283696

From ysuenaga at openjdk.org  Thu Sep 18 08:18:58 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 18 Sep 2025 08:18:58 GMT
Subject: RFR: 8367953: JFR sampler threads does not appear in thread dump
Message-ID: <UuNI7Uk8-1yDYYf0z-y2NEReYfyOcSr0kMeEV8WX7zA=.7140b016-815d-44ab-ae0f-6353144cf533@github.com>

I tried to get thread dump of the process which is enabled JFR, then I got strange thread dump like this:


os_prio=0 cpu=64.47ms elapsed=20.34s tid=0x00007ff7cd3ffae0 nid=59812 runnable
os_prio=0 cpu=12.76ms elapsed=20.34s tid=0x00007ff7cd3ff5a0 nid=59811 runnable


Thread name is lacked in the dump (and lacks of LF in addition).
I checked them with `ps -eL -o pid,tid,comm`, then I was aware they were JFR sampler threads.


  59789 59811 JFR CPU Sampler
  59789 59812 JFR Sampler Thr


So they should be shown like this:


"JFR Sampler Thread" os_prio=0 cpu=25.59ms elapsed=8.77s tid=0x00007f5f45626a50 nid=62979 runnable

"JFR CPU Sampler Thread" os_prio=0 cpu=4.78ms elapsed=8.78s tid=0x00007f5f45626060 nid=62978 runnable


They are implemented in `JfrSamplerThread` and `JfrCPUSamplerThread`, extends `NonJavaThread`. They do not have `print_on()`, so `Thread::print_on()` would be used - it would not print thread name.

Other child class of `NonJavaThread` like `WatcherThread` overrides `print_on` to show thread name. Thus both of JFR sampler threads should do so.

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

Commit messages:
 - Remove override qualifier
 - 8367953: JFR sampler threads does not appear in thread dump

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

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

From jbachorik at openjdk.org  Thu Sep 18 08:37:14 2025
From: jbachorik at openjdk.org (Jaroslav Bachorik)
Date: Thu, 18 Sep 2025 08:37:14 GMT
Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler
In-Reply-To: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
References: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
Message-ID: <N_SaC26BZqQ7Htyy9piPaSI9CJ8VEjlbrw7YOe0c46U=.2defc52e-7211-4f40-93b1-716cc8a07854@github.com>

On Wed, 27 Aug 2025 12:50:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Remove acq-rel semantics where it isn't needed.

This looks good. 
Could you add some code comments, perhaps in the *.h file, explaining why we can afford to do this and don't have to enforce the memory ordering and atomics?

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

PR Review: https://git.openjdk.org/jdk/pull/26960#pullrequestreview-3238197922

From jbechberger at openjdk.org  Thu Sep 18 12:54:16 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 12:54:16 GMT
Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler
 [v2]
In-Reply-To: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
References: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
Message-ID: <S1D_wG_XbUcaKC2KPeThuyLHhKRnnN5RoPAhFXfGaqI=.4b19adad-2243-4184-991c-87d55d59fa41@github.com>

> Remove acq-rel semantics where it isn't needed.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Extend comment

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26960/files
  - new: https://git.openjdk.org/jdk/pull/26960/files/f8dfe276..fbb21255

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

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

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

From jbechberger at openjdk.org  Thu Sep 18 12:54:17 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 12:54:17 GMT
Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler
In-Reply-To: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
References: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
Message-ID: <SXu-Gd5tq82DypmUrxGt_4dQnU_kegbbhsNoG_0dSaU=.269f5d62-0f42-433a-bc00-9f303ebce57c@github.com>

On Wed, 27 Aug 2025 12:50:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> Remove acq-rel semantics where it isn't needed.

Is this enough?

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

PR Comment: https://git.openjdk.org/jdk/pull/26960#issuecomment-3307283924

From jbechberger at openjdk.org  Thu Sep 18 13:00:01 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 13:00:01 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
Message-ID: <_uoBONcm-SYGzYs8fKBgfwmfhIeqZaBgimjZYtqJ92g=.7827f207-de8e-4842-91cb-f15230b2b40f@github.com>

On Thu, 18 Sep 2025 01:16:44 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 103:
> 
>> 101:             // setup recording
>> 102:             AtomicLong burstThreadId = new AtomicLong();
>> 103:             final long startTimeMillis = System.currentTimeMillis();
> 
> Do not use `System.currentTimeMillis()` for time intervals: 1) it suffers from rounding errors due to low resolution; 2) it is not guaranteed to be monotonic. Use `System.nanoTime()` or `Instant.now()` instead.

Thanks

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359140696

From jbechberger at openjdk.org  Thu Sep 18 13:00:35 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 13:00:35 GMT
Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler
 [v3]
In-Reply-To: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
References: <FMBxc9ve9Jw66eCgCTK0wYW_z5HrPXuvMwzX77BNmCY=.1b2f5c53-bb01-4af4-a66c-c41c388608c0@github.com>
Message-ID: <Pu8fFgeQUjkyw0X0NRqPF13c3GUL3sNhIFUz64Bat2Y=.f1561ea9-b5f1-48fa-a276-a3a5807ff17e@github.com>

> Remove acq-rel semantics where it isn't needed.

Johannes Bechberger has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' into parttimenerd_reduce_synchronization
 - Extend comment
 - Remove unnecessary line
 - Remove redundant synchronization

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

Changes: https://git.openjdk.org/jdk/pull/26960/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26960&range=02
  Stats: 41 lines in 2 files changed: 12 ins; 12 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/26960.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26960/head:pull/26960

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

From jbechberger at openjdk.org  Thu Sep 18 13:09:27 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 13:09:27 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
Message-ID: <F4j4Nu5mKbkf7A40IgNRHnTozFQgZ-_Ub22uGzPI65E=.fdd60624-d2b0-490e-8741-2945c8a961d3@github.com>

On Thu, 18 Sep 2025 01:30:44 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 165:
> 
>> 163:         }
>> 164:         // check that there are at least 3 time boxes
>> 165:         Asserts.assertTrue(timeBoxedLosses.size() > 3);
> 
> Not sure what this assert means. From what I see, the size of `timeBoxedLosses` should be exactly equal to the number of main loop iterations (5).

It should.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359195279

From jbechberger at openjdk.org  Thu Sep 18 13:20:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 13:20:57 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <9faaJWDTc4hOBRJ5p1ZZcX879KV1385Njd4IAL7Bu-c=.3cc8526c-a553-446f-8c90-8cc7c446a437@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
 <9faaJWDTc4hOBRJ5p1ZZcX879KV1385Njd4IAL7Bu-c=.3cc8526c-a553-446f-8c90-8cc7c446a437@github.com>
Message-ID: <re0p5SDCML6y2hE7HF8aNKcIKjJXO_4msjJcXXj-DpA=.5f29bc7d-5f84-4470-8bb2-6816c6c9efbf@github.com>

On Thu, 18 Sep 2025 01:58:18 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 154:
>> 
>>> 152:         ThreadMXBean bean = ManagementFactory.getThreadMXBean();
>>> 153:         long start = bean.getCurrentThreadCpuTime();
>>> 154:         while (bean.getCurrentThreadCpuTime() - start < millis * 1_000_000) {
>> 
>> Isn't this method supposed to check CPU time of the passed `thread` rather than current thread?
>
> BTW, is there a specific reason to burn cpu in a separate thread? It can be done in the same `main` thread, isn't it?

> Isn't this method supposed to check CPU time of the passed thread rather than current thread?

You're correct.

> It can be done in the same main thread, isn't it?

You're correct and it makes the code so much easier.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359252129

From jbechberger at openjdk.org  Thu Sep 18 13:30:31 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 13:30:31 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <mcbONvsZ-_a6zzh2a6Gb7pMCHZVcbywCKjf0vrNHOp4=.4f3ea9b3-5ed7-453a-b855-0d4b5923e9f6@github.com>
Message-ID: <81w2mpMAaOI3WCzt3qEPCGDKblt0nPdT6ULvaDx9BtM=.7eb2a3e5-a114-4be7-aba4-0335d104bd94@github.com>

On Thu, 18 Sep 2025 02:06:27 GMT, Andrei Pangin <apangin at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 99:
> 
>> 97:     }
>> 98: 
>> 99:     public static void main(String[] args) throws Exception {
> 
> A brief high-level explanation of what the test does would be useful.
> From what I understood, the test starts CPU time sampling with a short interval (1ms), temporarily disables processing of native samples to cause queue overflow, then enables it back to report lost samples. Repeats the cycle 5 times and verifies that the queue has grown by the time of the last iteration, thereby decreasing the amount of losses.

Almost. But I only check the loss. I'll use an updated version of your text.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359312057

From jbechberger at openjdk.org  Thu Sep 18 14:02:53 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 14:02:53 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v2]
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <dAFGvkOGnh-cL8HggMWoN7AdbciTyQ7SWc010e-o69A=.80e7b085-d9f5-487e-885a-13333e8d63c2@github.com>

> This change hopefully fixes the test failures by making the test cases more resilient.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Simplify code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27293/files
  - new: https://git.openjdk.org/jdk/pull/27293/files/15569d5d..1dc6ad1d

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

  Stats: 85 lines in 5 files changed: 18 ins; 51 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/27293.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27293/head:pull/27293

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

From jbechberger at openjdk.org  Thu Sep 18 14:02:54 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 14:02:54 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <OtNizRqSgsvi5iMxhJmb68P7sUHaoT6KK0BL0vwjkZM=.6c1debcd-f70a-45d5-9cee-a89199b11dea@github.com>

On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

> This change hopefully fixes the test failures by making the test cases more resilient.

Thanks to the tips of @apangin I was able to drastically reduce both size and complexity of the test case. I hope it runs better now. What I improved

- Only use a single thread
- No arbitrary waits, just one native wait in the loop
- Properly documented the test scenario

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3307625621

From apangin at openjdk.org  Thu Sep 18 14:15:59 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Thu, 18 Sep 2025 14:15:59 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v2]
In-Reply-To: <dAFGvkOGnh-cL8HggMWoN7AdbciTyQ7SWc010e-o69A=.80e7b085-d9f5-487e-885a-13333e8d63c2@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <dAFGvkOGnh-cL8HggMWoN7AdbciTyQ7SWc010e-o69A=.80e7b085-d9f5-487e-885a-13333e8d63c2@github.com>
Message-ID: <EmlRi7FDQSmJ5GOGuhEzjcDm8-xAaNLahjw8iAs1ZzQ=.ffb30058-69d1-4305-8660-35ed917be3fc@github.com>

On Thu, 18 Sep 2025 14:02:53 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Simplify code

Thanks! Much better, indeed. Added a few more minor comments.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 74:

> 72:         private final List<Long> timeBoxEnds = new ArrayList<>();
> 73: 
> 74:         public synchronized void addEvent(LossEvent event) {

Since the test is now single-threaded, all `synchronized` are redundant.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 106:

> 104:         try (RecordingStream rs = new RecordingStream()) {
> 105:             // setup recording
> 106:             AtomicLong burstThreadId = new AtomicLong();

Does not need to be `AtomicLong`. Can be `long` and initialized right here.

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 130:

> 128:                 WHITE_BOX.busyWaitCPUTime(1000);
> 129:                 // going out-of-native at the end of the previous call should have triggered
> 130:                 // the safepoint handler, thereby also triggering the stack walkingand creation

typo: walking_and

test/jdk/jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java line 145:

> 143:     static void disableOutOfStackWalking() {
> 144:         boolean supported = WHITE_BOX.cpuSamplerSetOutOfStackWalking(false);
> 145:         if (!supported) {

Why not simply `assertTrue(supported, ...)`?

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

PR Review: https://git.openjdk.org/jdk/pull/27293#pullrequestreview-3239996378
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359507524
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359518683
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359523702
PR Review Comment: https://git.openjdk.org/jdk/pull/27293#discussion_r2359530422

From jbechberger at openjdk.org  Thu Sep 18 14:48:11 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 14:48:11 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v3]
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <_LgONwP1Tgunjanim54_sYkPkqq-uRHjjbqVDoPYf_0=.45c05cb7-a616-4704-b367-cff3dad7926c@github.com>

> This change hopefully fixes the test failures by making the test cases more resilient.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Tiny fixes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27293/files
  - new: https://git.openjdk.org/jdk/pull/27293/files/1dc6ad1d..5a1ec5f9

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

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

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

From jbechberger at openjdk.org  Thu Sep 18 14:51:33 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Thu, 18 Sep 2025 14:51:33 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v4]
In-Reply-To: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
Message-ID: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>

> This change hopefully fixes the test failures by making the test cases more resilient.

Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:

  Remove synchronized

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27293/files
  - new: https://git.openjdk.org/jdk/pull/27293/files/5a1ec5f9..c7c72770

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

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

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

From apangin at openjdk.org  Thu Sep 18 15:54:01 2025
From: apangin at openjdk.org (Andrei Pangin)
Date: Thu, 18 Sep 2025 15:54:01 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v4]
In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
Message-ID: <mKlpNNOqyIfpsS9s2kZ8nSrhvVCr9pjDGDhPQMVnX-8=.b9d16333-bec8-47fd-8589-678cd523cc95@github.com>

On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove synchronized

Marked as reviewed by apangin (Author).

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

PR Review: https://git.openjdk.org/jdk/pull/27293#pullrequestreview-3240632801

From dholmes at openjdk.org  Fri Sep 19 05:30:16 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 05:30:16 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v4]
In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
Message-ID: <QD8cAhhyBt6Tnz5-l9MiInwldfXc0arWJ62lXD88nAo=.d9f25d06-d1a0-44c5-b095-c578237ebcac@github.com>

On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove synchronized

I will run the updated test through our CI ...

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3310645145

From dholmes at openjdk.org  Fri Sep 19 06:31:17 2025
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 19 Sep 2025 06:31:17 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v4]
In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
Message-ID: <TEaok9Q80jf1jitKC9pavd9kkRrCwoCSEtT8PsA4y1k=.7ada8705-460e-43cb-ab5b-5e316619f52f@github.com>

On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove synchronized

The test is still failing in our CI on linux-aarch64-debug:

[58.916s][info][jfr,startup] Started recording 1. No limit specified, using maxsize=250MB as default.
[58.916s][info][jfr,startup] 
[58.916s][info][jfr,startup] Use jcmd 2600244 JFR.dump name=1 filename=FILEPATH to copy recording data to file.
Lost samples: 41 at 978 start time 1758260993451
Lost samples in time box 0: 0
Lost samples: 5 at 1078 start time 1758260993451
Lost samples in time box 1959: 0
Lost samples in time box 2967: 0
Lost samples in time box 3969: 0
Lost samples in time box 4970: 0
----------System.err:(15/1004)----------
java.lang.RuntimeException: assertTrue: expected true, was false
	at jdk.test.lib.Asserts.fail(Asserts.java:715)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:545)
	at jdk.test.lib.Asserts.assertTrue(Asserts.java:531)
	at jdk.jfr.event.profiling.TestCPUTimeSampleQueueAutoSizes.checkThatLossDecreased(TestCPUTimeSampleQueueAutoSizes.java:154)
	at jdk.jfr.event.profiling.TestCPUTimeSampleQueueAutoSizes.main(TestCPUTimeSampleQueueAutoSizes.java:136)
	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:1474)


I ran with `-Xcomp -ea -esa -XX:CompileThreshold=100 -XX:+UnlockExperimentalVMOptions -server -XX:+TieredCompilation -XX:+VerifyOops'` as used in some of our higher tier testing where we saw initial failures.

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3310786254

From jbechberger at openjdk.org  Fri Sep 19 11:48:57 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Fri, 19 Sep 2025 11:48:57 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v4]
In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
Message-ID: <q1szKUBT1rRQbMAs8uoaXeGJ4GXGeUSBxVcMqv5IyrY=.38e3e931-b1e1-4f1f-a198-717e39106291@github.com>

On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove synchronized

Interesting. I'm further simplifying the test case, removing all the time-box code.

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3311888120

From egahlin at openjdk.org  Fri Sep 19 11:59:46 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 19 Sep 2025 11:59:46 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v4]
In-Reply-To: <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <3tx8u2KSzSzLQG8wa-YCiQGCwS--B1q56JZFiYbklhQ=.396d1328-3591-46de-9e82-5e3a065c8b8a@github.com>
Message-ID: <Gmdb_Q6BF6RzMCoXkcXeDFwfLzhgCiP1AO8r_leu3L8=.abf6d2c4-75cc-44cb-a22a-1778fe5c7a8d@github.com>

On Thu, 18 Sep 2025 14:51:33 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove synchronized

Could you add  "@requires vm.flagless" to reduce risk of false positives.

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3311917878

From egahlin at openjdk.org  Fri Sep 19 12:07:09 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 19 Sep 2025 12:07:09 GMT
Subject: Integrated: 8367107: JFR: Refactor policy tests out of TestRemoteDump
In-Reply-To: <wh6psCWgzj600LUmxYJ3gx4COfBRpsdPkXoPUrK-OCU=.85fe9c08-6855-4d6b-af5b-fc3b97e0c04b@github.com>
References: <wh6psCWgzj600LUmxYJ3gx4COfBRpsdPkXoPUrK-OCU=.85fe9c08-6855-4d6b-af5b-fc3b97e0c04b@github.com>
Message-ID: <gSHm_SUnZc6gtWKw_2Rn6tmnktxU-nct5bjeBaOfV3o=.b2cbd886-465b-43ef-9869-430fe58f834e@github.com>

On Mon, 8 Sep 2025 20:10:59 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I get a review of a PR that splits TestRemoteDump.java into two test files?
> 
> This change prevents timeouts and reduces wall clock time, as the tests can now run in parallel. As part of the change, I am reverting the modification to TestRemoteDump introduced with [JFR: Improve slow tests](https://bugs.openjdk.org/browse/JDK-8364756), which made the test flaky. I also removed unused imports and fixed the incorrect test summary.
> 
> Testing: 100 * (TestRemoteDump and TestDumpRetention)
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 802d9c23
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/802d9c23dc83dcd37964fa3a894fa6d01f501176
Stats:     197 lines in 2 files changed: 123 ins; 73 del; 1 mod

8367107: JFR: Refactor policy tests out of TestRemoteDump

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Fri Sep 19 18:24:10 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Fri, 19 Sep 2025 18:24:10 GMT
Subject: RFR: 8367948: JFR: MethodTrace threshold setting has no effect
Message-ID: <vdeHJxj5UylDA74FOBiKc7WsI3NB2nmvU_0mxkpwB28=.29355843-2e84-4449-ad4b-e4490c43f295@github.com>

Could I have a review of the PR that ensures thresholds work with the MethodTrace event?

Testing: jdk/jdk/jfr 

Thanks
Erik

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

Commit messages:
 - Initial

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

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

From shade at openjdk.org  Mon Sep 22 08:10:18 2025
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 22 Sep 2025 08:10:18 GMT
Subject: RFR: 8367948: JFR: MethodTrace threshold setting has no effect
In-Reply-To: <vdeHJxj5UylDA74FOBiKc7WsI3NB2nmvU_0mxkpwB28=.29355843-2e84-4449-ad4b-e4490c43f295@github.com>
References: <vdeHJxj5UylDA74FOBiKc7WsI3NB2nmvU_0mxkpwB28=.29355843-2e84-4449-ad4b-e4490c43f295@github.com>
Message-ID: <GKGdf4s0OLWbW5JAt2owvJ7VCo_XHZDYOBA7xR3iojQ=.dfcc0a49-eb25-41dd-92f6-98eb04a08ccb@github.com>

On Fri, 19 Sep 2025 18:14:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the PR that ensures thresholds work with the MethodTrace event?
> 
> Testing: jdk/jdk/jfr 
> 
> Thanks
> Erik

Looks reasonable, thanks.

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

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27396#pullrequestreview-3251077967

From mgronlun at openjdk.org  Mon Sep 22 12:02:34 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 22 Sep 2025 12:02:34 GMT
Subject: RFR: 8362573: Incorrect weight of the first ObjectAllocationSample
 JFR event (regression) [v2]
In-Reply-To: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
References: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
Message-ID: <0SK2wHpB1mVMHEVRLWQjDSlIMWUOCHQNR3MkZEqFpgM=.e4725dd6-2178-4b96-9592-b47b246bd43d@github.com>

> Greetings,
> 
> Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled.
> 
> The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads.
> 
> This time also includes a regression test.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  simplified test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26900/files
  - new: https://git.openjdk.org/jdk/pull/26900/files/9ec4bc95..3287e371

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

  Stats: 39 lines in 1 file changed: 6 ins; 25 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/26900.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26900/head:pull/26900

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

From mgronlun at openjdk.org  Tue Sep 23 12:32:04 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 23 Sep 2025 12:32:04 GMT
Subject: RFR: 8362573: Incorrect weight of the first ObjectAllocationSample
 JFR event (regression) [v3]
In-Reply-To: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
References: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
Message-ID: <YOK6BvrsuNH38bAKwMq0Q3SFE-3S0eCLVtsYmZvm_gQ=.dc02af0c-f8ea-4131-9907-3e93b1e4bc1f@github.com>

> Greetings,
> 
> Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled.
> 
> The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads.
> 
> This time also includes a regression test.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  invert condition

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26900/files
  - new: https://git.openjdk.org/jdk/pull/26900/files/3287e371..2fda62f7

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

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

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

From egahlin at openjdk.org  Tue Sep 23 12:39:09 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 23 Sep 2025 12:39:09 GMT
Subject: Integrated: 8367948: JFR: MethodTrace threshold setting has no effect
In-Reply-To: <vdeHJxj5UylDA74FOBiKc7WsI3NB2nmvU_0mxkpwB28=.29355843-2e84-4449-ad4b-e4490c43f295@github.com>
References: <vdeHJxj5UylDA74FOBiKc7WsI3NB2nmvU_0mxkpwB28=.29355843-2e84-4449-ad4b-e4490c43f295@github.com>
Message-ID: <ceE9_aHMQPlokU9X3I07j8fdUDCtCYDBueoel6MvjoE=.1fbcab78-0f85-4cf1-88e4-cae2aca3c9a8@github.com>

On Fri, 19 Sep 2025 18:14:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of the PR that ensures thresholds work with the MethodTrace event?
> 
> Testing: jdk/jdk/jfr 
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 4bc86a26
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4bc86a26db1eb3d054d80c9759fe04686e1e36b3
Stats:     34 lines in 3 files changed: 29 ins; 0 del; 5 mod

8367948: JFR: MethodTrace threshold setting has no effect

Reviewed-by: shade

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

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

From egahlin at openjdk.org  Tue Sep 23 13:07:26 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 23 Sep 2025 13:07:26 GMT
Subject: RFR: 8362573: Incorrect weight of the first ObjectAllocationSample
 JFR event (regression) [v3]
In-Reply-To: <YOK6BvrsuNH38bAKwMq0Q3SFE-3S0eCLVtsYmZvm_gQ=.dc02af0c-f8ea-4131-9907-3e93b1e4bc1f@github.com>
References: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
 <YOK6BvrsuNH38bAKwMq0Q3SFE-3S0eCLVtsYmZvm_gQ=.dc02af0c-f8ea-4131-9907-3e93b1e4bc1f@github.com>
Message-ID: <KUdO85tks95XpB3VVmohv4pbZJLjQS6yvhwZtLRUTGE=.39b12ed9-a52f-428e-804e-3bdad560e9be@github.com>

On Tue, 23 Sep 2025 12:32:04 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled.
>> 
>> The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads.
>> 
>> This time also includes a regression test.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   invert condition

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26900#pullrequestreview-3257922536

From mgronlun at openjdk.org  Tue Sep 23 14:03:07 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 23 Sep 2025 14:03:07 GMT
Subject: RFR: 8366809: JFR: Use factory for aggregator functions
In-Reply-To: <mCJ54xxQwrby3OJmmZ6U5W07T_FGErMhC9Kg5LhrtLQ=.3a578ef3-2372-4110-ae05-1ba68745d8d8@github.com>
References: <mCJ54xxQwrby3OJmmZ6U5W07T_FGErMhC9Kg5LhrtLQ=.3a578ef3-2372-4110-ae05-1ba68745d8d8@github.com>
Message-ID: <D4k8y27hOOM5YJDqvlZfJynyo8SLjm3CAvul9svREYc=.a2878022-1e09-4e75-a268-cbd32734f4cd@github.com>

On Wed, 3 Sep 2025 14:27:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that replaces the selection of the aggregator function with a factory, so that the selection only needs to happen once per column instead of for every row?
> 
> Testing: jdk/jdk/jfr + manual inspection 'jfr view' output
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27072#pullrequestreview-3258175851

From egahlin at openjdk.org  Tue Sep 23 14:56:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 23 Sep 2025 14:56:44 GMT
Subject: Integrated: 8366809: JFR: Use factory for aggregator functions
In-Reply-To: <mCJ54xxQwrby3OJmmZ6U5W07T_FGErMhC9Kg5LhrtLQ=.3a578ef3-2372-4110-ae05-1ba68745d8d8@github.com>
References: <mCJ54xxQwrby3OJmmZ6U5W07T_FGErMhC9Kg5LhrtLQ=.3a578ef3-2372-4110-ae05-1ba68745d8d8@github.com>
Message-ID: <0p7qMZ1CEHeKRRVHWifQPudzWtfynxXWVjzYBF2S-Ls=.3de07e36-5c0b-4eec-a1a6-fcf31d95fec5@github.com>

On Wed, 3 Sep 2025 14:27:26 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that replaces the selection of the aggregator function with a factory, so that the selection only needs to happen once per column instead of for every row?
> 
> Testing: jdk/jdk/jfr + manual inspection of 'jfr view' output
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 4df04a25
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/4df04a254397836b1bfe384ac9e6413e1ff9b242
Stats:     40 lines in 3 files changed: 10 ins; 2 del; 28 mod

8366809: JFR: Use factory for aggregator functions

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Tue Sep 23 16:53:29 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 23 Sep 2025 16:53:29 GMT
Subject: RFR: 8366896: JFR: Use GarbageCollection.name in gc view [v2]
In-Reply-To: <mmKb8L4-OHgyL-vjGna6AbvzMXQIPNofEj7JIYvKG6c=.d2866325-3d61-46ff-b76d-f1c2dc043de1@github.com>
References: <mmKb8L4-OHgyL-vjGna6AbvzMXQIPNofEj7JIYvKG6c=.d2866325-3d61-46ff-b76d-f1c2dc043de1@github.com>
Message-ID: <1guOK92TfRZAFX7pukwlqKjqZ92hSXBUG3DRZiYf1DQ=.718dc5ca-0c9d-4b80-a4e5-484cab5e8fd0@github.com>

> Could I have a review of a PR that fixes the 'jfr gc view'?
> 
> I also changed so events are ordered by GC ID and not start time. This works better in case not all events for a GC ID has been emitted.
> 
> Testing: jdk/jdk/jfr + manual inspection with ZGC, Shenandoah, G1, Parallel and Serial.
> 
> Thanks
> Erik

Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:

 - Use column name Name and update tests
 - Update to use GC.name

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/27099/files
  - new: https://git.openjdk.org/jdk/pull/27099/files/dd247b35..e200f005

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

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

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

From ysuenaga at openjdk.org  Wed Sep 24 23:56:10 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Wed, 24 Sep 2025 23:56:10 GMT
Subject: RFR: 8367953: JFR sampler threads does not appear in thread dump
In-Reply-To: <UuNI7Uk8-1yDYYf0z-y2NEReYfyOcSr0kMeEV8WX7zA=.7140b016-815d-44ab-ae0f-6353144cf533@github.com>
References: <UuNI7Uk8-1yDYYf0z-y2NEReYfyOcSr0kMeEV8WX7zA=.7140b016-815d-44ab-ae0f-6353144cf533@github.com>
Message-ID: <R63z1SZmafBcXPNFcP2ZRUcFriU6anXTLcKZbwty6KY=.350f3414-bc22-4106-b55b-55737d151962@github.com>

On Thu, 18 Sep 2025 05:30:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get thread dump of the process which is enabled JFR, then I got strange thread dump like this:
> 
> 
> os_prio=0 cpu=64.47ms elapsed=20.34s tid=0x00007ff7cd3ffae0 nid=59812 runnable
> os_prio=0 cpu=12.76ms elapsed=20.34s tid=0x00007ff7cd3ff5a0 nid=59811 runnable
> 
> 
> Thread name is lacked in the dump (and lacks of LF in addition).
> I checked them with `ps -eL -o pid,tid,comm`, then I was aware they were JFR sampler threads.
> 
> 
>   59789 59811 JFR CPU Sampler
>   59789 59812 JFR Sampler Thr
> 
> 
> So they should be shown like this:
> 
> 
> "JFR Sampler Thread" os_prio=0 cpu=25.59ms elapsed=8.77s tid=0x00007f5f45626a50 nid=62979 runnable
> 
> "JFR CPU Sampler Thread" os_prio=0 cpu=4.78ms elapsed=8.78s tid=0x00007f5f45626060 nid=62978 runnable
> 
> 
> They are implemented in `JfrSamplerThread` and `JfrCPUSamplerThread`, extends `NonJavaThread`. They do not have `print_on()`, so `Thread::print_on()` would be used - it would not print thread name.
> 
> Other child class of `NonJavaThread` like `WatcherThread` overrides `print_on` to show thread name. Thus both of JFR sampler threads should do so.

PING: Can I get reviewer(s)? Thanks!

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

PR Comment: https://git.openjdk.org/jdk/pull/27357#issuecomment-3331097046

From mgronlun at openjdk.org  Thu Sep 25 10:38:55 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 25 Sep 2025 10:38:55 GMT
Subject: RFR: 8366896: JFR: Use GarbageCollection.name in gc view [v2]
In-Reply-To: <1guOK92TfRZAFX7pukwlqKjqZ92hSXBUG3DRZiYf1DQ=.718dc5ca-0c9d-4b80-a4e5-484cab5e8fd0@github.com>
References: <mmKb8L4-OHgyL-vjGna6AbvzMXQIPNofEj7JIYvKG6c=.d2866325-3d61-46ff-b76d-f1c2dc043de1@github.com>
 <1guOK92TfRZAFX7pukwlqKjqZ92hSXBUG3DRZiYf1DQ=.718dc5ca-0c9d-4b80-a4e5-484cab5e8fd0@github.com>
Message-ID: <6c6uvQwAasBzUIr8kL-2Le_I0RiFTwLH89E2rdZKTAo=.e44cd394-9289-4a97-a73d-809d7c5e56dd@github.com>

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

>> Could I have a review of a PR that fixes the 'jfr gc view'?
>> 
>> 
>> Before:
>> 
>>     $ jfr view gc z.jfr
>>     
>>                                   Garbage Collections
>>     
>>     Start    GC ID Type                  Heap Before GC Heap After GC Longest Pause
>>     -------- ----- --------------------- -------------- ------------- -------------
>>     N/A         61 Unknown                       5.2 GB           N/A           N/A
>>     N/A         63 Unknown                       7.2 GB           N/A           N/A
>>     16:13:43     0 Unknown                     868.0 MB        1.6 GB    0.00808 ms
>>     16:13:43     1 Unknown                       1.7 GB        3.8 GB    0.00796 ms
>>     16:13:44     2 Unknown                       3.8 GB        9.0 GB     0.0136 ms
>>     
>>     $ jfr view gc shen.jfr
>>     
>>                                   Garbage Collections
>>     
>>     Start    GC ID Type                  Heap Before GC Heap After GC Longest Pause
>>     -------- ----- --------------------- -------------- ------------- -------------
>>     16:16:07     0 Unknown                       2.3 GB        4.9 GB      0.139 ms
>>     16:16:08     1 Unknown                       4.9 GB        6.3 GB     0.0693 ms
>>     16:16:09     2 Unknown                       6.3 GB        1.2 GB     0.0812 ms
>>     16:16:09     3 Unknown                       1.8 GB        5.2 GB     0.0824 ms
>>     16:16:09     4 Unknown                       5.2 GB        9.0 GB     0.0930 ms
>>     
>>     $ jfr view gc g1.jfr
>>     
>>                                     Garbage Collections
>>     
>>     Start    GC ID Type                     Heap Before GC Heap After GC Longest Pause
>>     -------- ----- ------------------------ -------------- ------------- -------------
>>     14:45:23     0 Young Garbage Collection        49.1 MB       14.2 MB       2.52 ms
>>     14:45:24     1 Old Garbage Collection          46.2 MB       24.6 MB       16.1 ms
>>     14:45:24     2 Old Garbage Collection          40.6 MB       24.6 MB       12.0 ms
>>     14:45:25     3 Young Garbage Collection        40.6 MB       41.2 MB      0.946 ms
>>     14:45:25     4 Old Garbage Collection          41.2 MB       49.2 MB           0 s
>>     
>>     $ jfr view gc serial.jfr
>>     
>>                                     Garbage Collections
>>     
>>     Start    GC ID Type                     Heap Before GC Heap After GC Longest Pause
>>     -------- ----- ------------------------ -------------- ------------- ----------...
>
> Erik Gahlin has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Use column name Name and update tests
>  - Update to use GC.name

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27099#pullrequestreview-3266996251

From egahlin at openjdk.org  Thu Sep 25 12:12:32 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 25 Sep 2025 12:12:32 GMT
Subject: Integrated: 8366896: JFR: Use GarbageCollection.name in gc view
In-Reply-To: <mmKb8L4-OHgyL-vjGna6AbvzMXQIPNofEj7JIYvKG6c=.d2866325-3d61-46ff-b76d-f1c2dc043de1@github.com>
References: <mmKb8L4-OHgyL-vjGna6AbvzMXQIPNofEj7JIYvKG6c=.d2866325-3d61-46ff-b76d-f1c2dc043de1@github.com>
Message-ID: <D56GA8THJbV7CRMR-k9TEeTISD_2RHbwpX-nsDhGLRM=.6dbe497f-f853-4578-8963-187be920a424@github.com>

On Thu, 4 Sep 2025 14:35:07 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that fixes the 'jfr gc view'?
> 
> 
> Before:
> 
>     $ jfr view gc z.jfr
>     
>                                   Garbage Collections
>     
>     Start    GC ID Type                  Heap Before GC Heap After GC Longest Pause
>     -------- ----- --------------------- -------------- ------------- -------------
>     N/A         61 Unknown                       5.2 GB           N/A           N/A
>     N/A         63 Unknown                       7.2 GB           N/A           N/A
>     16:13:43     0 Unknown                     868.0 MB        1.6 GB    0.00808 ms
>     16:13:43     1 Unknown                       1.7 GB        3.8 GB    0.00796 ms
>     16:13:44     2 Unknown                       3.8 GB        9.0 GB     0.0136 ms
>     
>     $ jfr view gc shen.jfr
>     
>                                   Garbage Collections
>     
>     Start    GC ID Type                  Heap Before GC Heap After GC Longest Pause
>     -------- ----- --------------------- -------------- ------------- -------------
>     16:16:07     0 Unknown                       2.3 GB        4.9 GB      0.139 ms
>     16:16:08     1 Unknown                       4.9 GB        6.3 GB     0.0693 ms
>     16:16:09     2 Unknown                       6.3 GB        1.2 GB     0.0812 ms
>     16:16:09     3 Unknown                       1.8 GB        5.2 GB     0.0824 ms
>     16:16:09     4 Unknown                       5.2 GB        9.0 GB     0.0930 ms
>     
>     $ jfr view gc g1.jfr
>     
>                                     Garbage Collections
>     
>     Start    GC ID Type                     Heap Before GC Heap After GC Longest Pause
>     -------- ----- ------------------------ -------------- ------------- -------------
>     14:45:23     0 Young Garbage Collection        49.1 MB       14.2 MB       2.52 ms
>     14:45:24     1 Old Garbage Collection          46.2 MB       24.6 MB       16.1 ms
>     14:45:24     2 Old Garbage Collection          40.6 MB       24.6 MB       12.0 ms
>     14:45:25     3 Young Garbage Collection        40.6 MB       41.2 MB      0.946 ms
>     14:45:25     4 Old Garbage Collection          41.2 MB       49.2 MB           0 s
>     
>     $ jfr view gc serial.jfr
>     
>                                     Garbage Collections
>     
>     Start    GC ID Type                     Heap Before GC Heap After GC Longest Pause
>     -------- ----- ------------------------ -------------- ------------- -------------
>     16:33:59     0 Young Garbage Collection       154.8 MB       83.2 MB       41.5 ms
>    ...

This pull request has now been integrated.

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

8366896: JFR: Use GarbageCollection.name in gc view

Reviewed-by: mgronlun

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

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

From mgronlun at openjdk.org  Mon Sep 29 07:52:30 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Mon, 29 Sep 2025 07:52:30 GMT
Subject: RFR: 8367953: JFR sampler threads does not appear in thread dump
In-Reply-To: <UuNI7Uk8-1yDYYf0z-y2NEReYfyOcSr0kMeEV8WX7zA=.7140b016-815d-44ab-ae0f-6353144cf533@github.com>
References: <UuNI7Uk8-1yDYYf0z-y2NEReYfyOcSr0kMeEV8WX7zA=.7140b016-815d-44ab-ae0f-6353144cf533@github.com>
Message-ID: <pz7w5LzXmhL36MNOQslOAKlNKYc85fmsOT818C19ynE=.dec0346c-beed-4d37-a9cc-ac809549f4c4@github.com>

On Thu, 18 Sep 2025 05:30:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get thread dump of the process which is enabled JFR, then I got strange thread dump like this:
> 
> 
> os_prio=0 cpu=64.47ms elapsed=20.34s tid=0x00007ff7cd3ffae0 nid=59812 runnable
> os_prio=0 cpu=12.76ms elapsed=20.34s tid=0x00007ff7cd3ff5a0 nid=59811 runnable
> 
> 
> Thread name is lacked in the dump (and lacks of LF in addition).
> I checked them with `ps -eL -o pid,tid,comm`, then I was aware they were JFR sampler threads.
> 
> 
>   59789 59811 JFR CPU Sampler
>   59789 59812 JFR Sampler Thr
> 
> 
> So they should be shown like this:
> 
> 
> "JFR Sampler Thread" os_prio=0 cpu=25.59ms elapsed=8.77s tid=0x00007f5f45626a50 nid=62979 runnable
> 
> "JFR CPU Sampler Thread" os_prio=0 cpu=4.78ms elapsed=8.78s tid=0x00007f5f45626060 nid=62978 runnable
> 
> 
> They are implemented in `JfrSamplerThread` and `JfrCPUSamplerThread`, extends `NonJavaThread`. They do not have `print_on()`, so `Thread::print_on()` would be used - it would not print thread name.
> 
> Other child class of `NonJavaThread` like `WatcherThread` overrides `print_on` to show thread name. Thus both of JFR sampler threads should do so.

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27357#pullrequestreview-3278362053

From egahlin at openjdk.org  Mon Sep 29 20:44:34 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 29 Sep 2025 20:44:34 GMT
Subject: RFR: 8368563: JFR: Improve jfr query help text
Message-ID: <Q0uiqDl5IXylIc4qt860u-AsTHnZrEh5mUAf36XUPpU=.04fd4383-b183-4bfb-82cd-9b86f26a1d6e@github.com>

Could I have review of PR that improves the help text for `jfr query`?

Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Fix alignment
 - Initial

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

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

From egahlin at openjdk.org  Mon Sep 29 23:02:19 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Mon, 29 Sep 2025 23:02:19 GMT
Subject: RFR: 8368809: JFR: Remove events from testSettingConfiguration in
 TestActiveSettingEvent
Message-ID: <4rW-9yRkWGxqPFk2RiG0jrTcr6TgAlYad4bhUD-Urxw=.bbe718a6-b136-4245-8d74-c7f5bb71e04c@github.com>

Could I have a review of a PR that removes an old test hack that is no longer needed. 

Testing: jdk/jfr/event/runtime/TestActiveSettingEvent.java

Thanks
Erik

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

Commit messages:
 - Add missing s
 - Improve formatting
 - Initial

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

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

From dholmes at openjdk.org  Tue Sep 30 07:03:53 2025
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 30 Sep 2025 07:03:53 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v9]
In-Reply-To: <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
Message-ID: <k_Fzqhp9zEsFXf2avFBuez8X1zIo-nKv3ljvCf5SHcY=.b6e19947-9fc4-4b6c-889e-0ff6dcd00e30@github.com>

On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build issue

Needed to add back the hotspot-jfr label as skara had removed it.

JFR folk can we please get this re-reviewed and approved. Thanks.

@parttimenerd  perhaps you could rally other JEP 509 folk to review this fix.

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3350276492

From mgronlun at openjdk.org  Tue Sep 30 08:19:49 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 30 Sep 2025 08:19:49 GMT
Subject: RFR: 8368563: JFR: Improve jfr query help text
In-Reply-To: <Q0uiqDl5IXylIc4qt860u-AsTHnZrEh5mUAf36XUPpU=.04fd4383-b183-4bfb-82cd-9b86f26a1d6e@github.com>
References: <Q0uiqDl5IXylIc4qt860u-AsTHnZrEh5mUAf36XUPpU=.04fd4383-b183-4bfb-82cd-9b86f26a1d6e@github.com>
Message-ID: <4wDzFXbTYl2kbpYN46NiOWeIXVRIZmTF7baLrthoni0=.08b9ca45-a3ac-4ed6-ae5d-f9a78006d725@github.com>

On Mon, 29 Sep 2025 20:29:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a PR that improves the help text for `jfr query`?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27558#pullrequestreview-3283183157

From mgronlun at openjdk.org  Tue Sep 30 08:48:42 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 30 Sep 2025 08:48:42 GMT
Subject: RFR: 8368809: JFR: Remove events from testSettingConfiguration in
 TestActiveSettingEvent
In-Reply-To: <4rW-9yRkWGxqPFk2RiG0jrTcr6TgAlYad4bhUD-Urxw=.bbe718a6-b136-4245-8d74-c7f5bb71e04c@github.com>
References: <4rW-9yRkWGxqPFk2RiG0jrTcr6TgAlYad4bhUD-Urxw=.bbe718a6-b136-4245-8d74-c7f5bb71e04c@github.com>
Message-ID: <-zeqxLr0W9TfRudME1aTLWf4YyvQCz99eslY5aqKw8I=.c81acc03-6d70-440f-9233-2a7271197640@github.com>

On Mon, 29 Sep 2025 22:46:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that removes an old test hack that is no longer needed. 
> 
> Testing: jdk/jfr/event/runtime/TestActiveSettingEvent.java
> 
> Thanks
> Erik

Marked as reviewed by mgronlun (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/27565#pullrequestreview-3283307941

From egahlin at openjdk.org  Tue Sep 30 09:34:44 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 30 Sep 2025 09:34:44 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v9]
In-Reply-To: <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
Message-ID: <3HaxpHnrD03IwGt4i_7sHtJOBKzAeKiYXjoprxlO2wM=.171690a4-b55d-49ce-9a1c-f5090940638d@github.com>

On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build issue

Thanks for adding vm.flagless. 

The other changes are better reviewed by those more familiar with the code introduced in JEP 509.

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3350952789

From mgronlun at openjdk.org  Tue Sep 30 10:05:33 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 30 Sep 2025 10:05:33 GMT
Subject: RFR: 8362573: Incorrect weight of the first ObjectAllocationSample
 JFR event (regression) [v4]
In-Reply-To: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
References: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
Message-ID: <st2MLJE4NxEpnObz_UsHnA9SCRebsUfhW5VnwcnjrZU=.8eda952c-c808-4cef-8238-97b6cb86a779@github.com>

> Greetings,
> 
> Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled.
> 
> The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads.
> 
> This time also includes a regression test.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

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

  missing imports in test

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/26900/files
  - new: https://git.openjdk.org/jdk/pull/26900/files/2fda62f7..95516294

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

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

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

From jbechberger at openjdk.org  Tue Sep 30 10:18:15 2025
From: jbechberger at openjdk.org (Johannes Bechberger)
Date: Tue, 30 Sep 2025 10:18:15 GMT
Subject: RFR: 8367302: New test
 jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082
 is failing [v9]
In-Reply-To: <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
References: <_r1coqZyHEizPTOsA2G7GwvCirLxzmPPCx5SHmFwhfo=.a3d42724-c1e3-416d-9d6f-bb58e48b626e@github.com>
 <QPlAvSZgZ6mf-OtAZ6aFeyDk7ETRfB52IHkF4wD8yzg=.afec4167-9d7c-48d7-866d-2eaa387b6f3d@github.com>
Message-ID: <AWHThZIA8Ay3elncy_r1uDaTWR3OKf0XduewTLNhvPk=.9747fc78-e40e-4660-b53c-4d5e0eb510ab@github.com>

On Tue, 23 Sep 2025 15:02:51 GMT, Johannes Bechberger <jbechberger at openjdk.org> wrote:

>> This change hopefully fixes the test failures by making the test cases more resilient.
>
> Johannes Bechberger has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix build issue

Andrei has already reviewed. Maybe @jbachorik could rereview it.

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

PR Comment: https://git.openjdk.org/jdk/pull/27293#issuecomment-3351139204

From egahlin at openjdk.org  Tue Sep 30 10:29:43 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 30 Sep 2025 10:29:43 GMT
Subject: RFR: 8362573: Incorrect weight of the first ObjectAllocationSample
 JFR event (regression) [v4]
In-Reply-To: <st2MLJE4NxEpnObz_UsHnA9SCRebsUfhW5VnwcnjrZU=.8eda952c-c808-4cef-8238-97b6cb86a779@github.com>
References: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
 <st2MLJE4NxEpnObz_UsHnA9SCRebsUfhW5VnwcnjrZU=.8eda952c-c808-4cef-8238-97b6cb86a779@github.com>
Message-ID: <pTzJHHSqAVv6psgg_7m1rzLFRliYAeumBIr-fsu4H1E=.3365b584-47d8-497a-a6c7-2a144d6cd47b@github.com>

On Tue, 30 Sep 2025 10:05:33 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

>> Greetings,
>> 
>> Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled.
>> 
>> The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads.
>> 
>> This time also includes a regression test.
>> 
>> Testing: jdk_jfr
>> 
>> Thanks
>> Markus
>
> Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missing imports in test

Marked as reviewed by egahlin (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/26900#pullrequestreview-3283843292

From mgronlun at openjdk.org  Tue Sep 30 10:38:31 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Tue, 30 Sep 2025 10:38:31 GMT
Subject: Integrated: 8362573: Incorrect weight of the first
 ObjectAllocationSample JFR event (regression)
In-Reply-To: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
References: <_ImYz-zP8dEz_aDZ-lkhfxT4sCnFtLsuX7qWWKlvsRE=.5dad6c7b-f7c4-4315-b86b-59fac07b2aa5@github.com>
Message-ID: <Y1G_ZaCNABBs_DErzLdjAv5mXm0yUggNY-9-XXVGUuU=.76e36ab7-b687-4658-b3cd-02a56ed8637f@github.com>

On Fri, 22 Aug 2025 11:28:04 GMT, Markus Gr?nlund <mgronlun at openjdk.org> wrote:

> Greetings,
> 
> Fix to ensure that the ObjectAllocationSample event sample weight property is initialized correctly when the event is enabled.
> 
> The previous clearing logic has been integrated into the existing thread iteration as part of the notify process, to avoid double passes. In addition, clearing and the event only apply to the set of JavaThreads.
> 
> This time also includes a regression test.
> 
> Testing: jdk_jfr
> 
> Thanks
> Markus

This pull request has now been integrated.

Changeset: b19e8721
Author:    Markus Gr?nlund <mgronlun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b19e872192106f47c5d9b425230cc2bfe3e4786c
Stats:     177 lines in 7 files changed: 116 ins; 30 del; 31 mod

8362573: Incorrect weight of the first ObjectAllocationSample JFR event (regression)

Reviewed-by: egahlin

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

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

From ysuenaga at openjdk.org  Tue Sep 30 11:35:59 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Tue, 30 Sep 2025 11:35:59 GMT
Subject: Integrated: 8367953: JFR sampler threads does not appear in thread
 dump
In-Reply-To: <UuNI7Uk8-1yDYYf0z-y2NEReYfyOcSr0kMeEV8WX7zA=.7140b016-815d-44ab-ae0f-6353144cf533@github.com>
References: <UuNI7Uk8-1yDYYf0z-y2NEReYfyOcSr0kMeEV8WX7zA=.7140b016-815d-44ab-ae0f-6353144cf533@github.com>
Message-ID: <xiJOlRQaJndXMpe5Cm-FXs_JvcWTfBuXyXj9NbS0in0=.3a404f6c-a038-4687-a9a6-2a5f3e118ce2@github.com>

On Thu, 18 Sep 2025 05:30:27 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> I tried to get thread dump of the process which is enabled JFR, then I got strange thread dump like this:
> 
> 
> os_prio=0 cpu=64.47ms elapsed=20.34s tid=0x00007ff7cd3ffae0 nid=59812 runnable
> os_prio=0 cpu=12.76ms elapsed=20.34s tid=0x00007ff7cd3ff5a0 nid=59811 runnable
> 
> 
> Thread name is lacked in the dump (and lacks of LF in addition).
> I checked them with `ps -eL -o pid,tid,comm`, then I was aware they were JFR sampler threads.
> 
> 
>   59789 59811 JFR CPU Sampler
>   59789 59812 JFR Sampler Thr
> 
> 
> So they should be shown like this:
> 
> 
> "JFR Sampler Thread" os_prio=0 cpu=25.59ms elapsed=8.77s tid=0x00007f5f45626a50 nid=62979 runnable
> 
> "JFR CPU Sampler Thread" os_prio=0 cpu=4.78ms elapsed=8.78s tid=0x00007f5f45626060 nid=62978 runnable
> 
> 
> They are implemented in `JfrSamplerThread` and `JfrCPUSamplerThread`, extends `NonJavaThread`. They do not have `print_on()`, so `Thread::print_on()` would be used - it would not print thread name.
> 
> Other child class of `NonJavaThread` like `WatcherThread` overrides `print_on` to show thread name. Thus both of JFR sampler threads should do so.

This pull request has now been integrated.

Changeset: 64c46d8e
Author:    Yasumasa Suenaga <ysuenaga at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/64c46d8efc27911b8667c3974275c075cf79a311
Stats:     14 lines in 2 files changed: 14 ins; 0 del; 0 mod

8367953: JFR sampler threads does not appear in thread dump

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Tue Sep 30 14:18:36 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 30 Sep 2025 14:18:36 GMT
Subject: Integrated: 8368563: JFR: Improve jfr query help text
In-Reply-To: <Q0uiqDl5IXylIc4qt860u-AsTHnZrEh5mUAf36XUPpU=.04fd4383-b183-4bfb-82cd-9b86f26a1d6e@github.com>
References: <Q0uiqDl5IXylIc4qt860u-AsTHnZrEh5mUAf36XUPpU=.04fd4383-b183-4bfb-82cd-9b86f26a1d6e@github.com>
Message-ID: <8Kwkogklhgev45mCE7G8s5zUXPjsyZ4wKM1lPlCAPpM=.c6a6821f-5efa-485a-a60c-0bf809fcbdaf@github.com>

On Mon, 29 Sep 2025 20:29:22 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have review of a PR that improves the help text for `jfr query`?
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 8cc54ec6
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8cc54ec6b86fc5b80af02939363eccd8e3e899e7
Stats:     18 lines in 2 files changed: 2 ins; 1 del; 15 mod

8368563: JFR: Improve jfr query help text

Reviewed-by: mgronlun

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

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

From egahlin at openjdk.org  Tue Sep 30 14:27:38 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 30 Sep 2025 14:27:38 GMT
Subject: Integrated: 8368809: JFR: Remove events from testSettingConfiguration
 in TestActiveSettingEvent
In-Reply-To: <4rW-9yRkWGxqPFk2RiG0jrTcr6TgAlYad4bhUD-Urxw=.bbe718a6-b136-4245-8d74-c7f5bb71e04c@github.com>
References: <4rW-9yRkWGxqPFk2RiG0jrTcr6TgAlYad4bhUD-Urxw=.bbe718a6-b136-4245-8d74-c7f5bb71e04c@github.com>
Message-ID: <jUW5D0GlRuRUOLLxlG0l9xM4rHURyaIbhIfHaUrnysU=.e62bfed9-3c08-4560-bcc5-452a34806dc5@github.com>

On Mon, 29 Sep 2025 22:46:47 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review of a PR that removes an old test hack that is no longer needed. 
> 
> Testing: jdk/jfr/event/runtime/TestActiveSettingEvent.java
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 6b4b1020
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6b4b10200ed10365e1ae1ca02ade773ce5a108c3
Stats:     27 lines in 1 file changed: 4 ins; 22 del; 1 mod

8368809: JFR: Remove events from testSettingConfiguration in TestActiveSettingEvent

Reviewed-by: mgronlun

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

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