From egahlin at openjdk.org  Wed Oct  1 19:57:18 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 1 Oct 2025 19:57:18 GMT
Subject: RFR: 8368670: Deadlock in JFR on event register + class load
Message-ID: <pGN17Uuhpz7g-hew3uW2LH8ASmnmkmS1_vxiSaagxOs=.f91eabd5-285a-46d3-9e87-99a704d0d27b@github.com>

Could I have a review a PR that prevents a deadlock? The MetadataRepository::isEnabled check is an optimization that allows JFR to instrument disabled event classes lazily.

The available settings object is never modified after it has been created, so it is sufficient to publish it using a volatile.


Testing: jdk/jdk/jfr

Thanks
Erik

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

Commit messages:
 - Fix
 - Use volatile
 - Initial

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

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

From dholmes at openjdk.org  Wed Oct  1 21:27:28 2025
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 1 Oct 2025 21:27:28 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: <ZGShcyp4QEyuOSXn5iu4MCN2mMg1sICQTLIwIz26eqE=.b09ba240-62bb-4da4-8692-526d3939070c@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

The non-test changes only affect the WhiteBox API which in turn is only for testing, so that all seems fine to me.

Approved.

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

Marked as reviewed by dholmes (Reviewer).

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

From ysuenaga at openjdk.org  Thu Oct  2 04:17:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 04:17:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <RJwCMGN-7dnD8yKTtoX-U1mpv4v2DhtpIoykz3WbS48=.d7a344fc-faec-4005-8664-8c18729b7e5a@github.com>

On Tue, 9 Sep 2025 13:47:45 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 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

Can someone review this PR? I think I have to got reviewers both HotSpot and JFR.

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

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

From dholmes at openjdk.org  Thu Oct  2 05:26:48 2025
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 2 Oct 2025 05:26:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
Message-ID: <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>

On Thu, 4 Sep 2025 11:29:14 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

>> 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
>
> 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 0Bh 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_cp...

Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ??

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

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

From ysuenaga at openjdk.org  Thu Oct  2 06:12:48 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 06:12:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <qas7gE3esv66Kp8mS3fyE-78wM3ZKDEExN5DWZiPHP0=.6381d9f7-8bf2-4ea1-a562-ea64dd7e1590@github.com>
 <orcLV-dg3MG4LiuwyNaPGQanx3MYCfjeZHZbl0RB_e4=.bc59c6fb-84c0-4e0e-8778-859402575f17@github.com>
Message-ID: <AvGHA6qkOj8cYqb7DUggXv8yTBX5qm45MkhZhIAJRB0=.1c9a904d-d4ab-486d-a6b8-a09bc85b93a7@github.com>

On Thu, 2 Oct 2025 05:24:12 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> 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 0Bh 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=interp...
>
> Sorry I don't follow this change. If there is a division-by-zero problem then don't we need a fix the method that would report zero i.e. `threads_per_core()` or `cores_per_cpu()` ??

I want to use number of logical processors from `CPUID` instruction directly because we can't believe `threads_per_core()` on hybrid CPU. Some of cores (e.g. E cores) might not have hyper threading even though `CPUID` reports HT flag.
Thus I think we have to check the value here.

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

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

From egahlin at openjdk.org  Thu Oct  2 06:39:47 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 2 Oct 2025 06:39:47 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <8iCd3iDn3FS3lVx_cXyKBUFpWy40a_9sfH4tJ848FNM=.69c598c7-3f0b-48bb-8ce4-24c036fcb469@github.com>

On Tue, 9 Sep 2025 13:47:45 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 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

I'm not sure promoting the value to a long is a good idea anymore, but I'm not completely against it either. Maybe it's sufficient to update the description of the cores field and say the value may be incorrect if there is hybrid cores? Maybe there should be a field indicating hybrid cores, or maybe we should do something else.

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

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

From ysuenaga at openjdk.org  Thu Oct  2 07:16:00 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 07:16:00 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>

On Tue, 9 Sep 2025 13:47:45 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 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

I saw similar behavior in `VM.info` dcmd, and I modified the output for CPU information in #26808 - removed thread-related information, and added "hybrid" flag.

But I think we cannot apply similar method in JFR because we have to treat number of cores even if "hybrid" flag would be added in event definition, and also we might change all of viewer (JMC, jfr command, and more) to hide number of cores if hybrid flag is set. It is impractical I think.

So I think it is the most reasonable to set `min_jlong` which already means "N/A".

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

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

From egahlin at openjdk.org  Thu Oct  2 08:00:48 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 2 Oct 2025 08:00:48 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
 <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>
Message-ID: <mZdVCHH74ceb9IyieRk3UJ6p5gkvfmc3gqC86rSYpSM=.047755ca-8a08-45cc-8d4c-5e8f4d245e1e@github.com>

On Thu, 2 Oct 2025 07:12:49 GMT, Yasumasa Suenaga <ysuenaga at openjdk.org> wrote:

> So I think it is the most reasonable to set `min_jlong` which already means "N/A".

I don't think using the min_jlong value is the problem, we do that for other event values, but promoting the field to a long value might be too disruptive. It's a value users are likely to extract programmatically.

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

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

From ysuenaga at openjdk.org  Thu Oct  2 08:44:06 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 08:44:06 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <mZdVCHH74ceb9IyieRk3UJ6p5gkvfmc3gqC86rSYpSM=.047755ca-8a08-45cc-8d4c-5e8f4d245e1e@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
 <1HsPYcAAyNpsaiVYaYEmM3oNtOeSdWKIJg4hue1cmas=.bbc913bc-7345-440c-8014-4c88a8e7239c@github.com>
 <mZdVCHH74ceb9IyieRk3UJ6p5gkvfmc3gqC86rSYpSM=.047755ca-8a08-45cc-8d4c-5e8f4d245e1e@github.com>
Message-ID: <NYxoilKPVtD-_Rzdvrf-rHeCy2qs9LseRYY3gBpKNbA=.57cd391f-37f2-4f76-98b4-02a4cec299aa@github.com>

On Thu, 2 Oct 2025 07:58:08 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> but promoting the field to a long value might be too disruptive. It's a value users are likely to extract programmatically.

If the data size is important than showing "N/A", I think we can set "0" for number of cores as I proposed [at first](https://openjdk.github.io/cr/?repo=jdk&pr=27080&range=00). But you said before that it should not be a problem to change to type long: https://github.com/openjdk/jdk/pull/27080#issuecomment-3270024207

Which is better? I think it is better not to change data size rather than showing "N/A" for compatibility. I think it is whether it feels natural for JFR that "0" means "N/A".

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

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

From egahlin at openjdk.org  Thu Oct  2 09:34:49 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 2 Oct 2025 09:34:49 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <d7VOExVqYIvQxdu7NX5kzUWq1pZd_F6ymrTiKXeRQn8=.cf87afd1-b931-4bc9-803e-494938ef99e0@github.com>

On Tue, 9 Sep 2025 13:47:45 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 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

>  But you said before that it should not be a problem to change to type long: [#27080 (comment)](https://github.com/openjdk/jdk/pull/27080#issuecomment-3270024207)

I looked at it from a file format perspective (varint encoding), but from an API perspective, as you showed, both getInt("cores") and getValue("cores") may throw an exception. This could impact users who have no problem with hybrid cores today. Also, their code may work on a development or test machine but then break on production hardware.

jcmd is meant for humans to read, so a change there has less impact.

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

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

From ysuenaga at openjdk.org  Thu Oct  2 11:15:49 2025
From: ysuenaga at openjdk.org (Yasumasa Suenaga)
Date: Thu, 2 Oct 2025 11:15:49 GMT
Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU
 [v3]
In-Reply-To: <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>
 <M_gyTfzOIrK7AeGgKLQxkjclqVFDStKk6BLDw3v2OVU=.debc4942-905e-4bc9-96b2-d5678cd658e4@github.com>
Message-ID: <6yCL5Daetce0mtR_jN3O2y-qvJ5hSGPODW0-7HhO9SE=.b1eef5ad-ef9f-4472-baed-69538e836ea9@github.com>

On Tue, 9 Sep 2025 13:47:45 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 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

So should I revert the change to original? I think it is better not to change data type. Compatibility should prefer than user friendly message ("N/A") in this case.

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

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

From mgronlun at openjdk.org  Thu Oct  2 11:21:47 2025
From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=)
Date: Thu, 2 Oct 2025 11:21:47 GMT
Subject: RFR: 8368670: Deadlock in JFR on event register + class load
In-Reply-To: <pGN17Uuhpz7g-hew3uW2LH8ASmnmkmS1_vxiSaagxOs=.f91eabd5-285a-46d3-9e87-99a704d0d27b@github.com>
References: <pGN17Uuhpz7g-hew3uW2LH8ASmnmkmS1_vxiSaagxOs=.f91eabd5-285a-46d3-9e87-99a704d0d27b@github.com>
Message-ID: <2CG_eXs_33cwn0XFBbXHPZ2I5H_LdZSNwK-aArT0p9w=.723238c4-39b8-459b-b40f-85800dc288da@github.com>

On Wed, 1 Oct 2025 16:56:53 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review a PR that prevents a deadlock? The MetadataRepository::isEnabled check is an optimization that allows JFR to instrument disabled event classes lazily.
> 
> The available settings object is never modified after it has been created, so it is sufficient to publish it using a volatile.
> 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

Nice.

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

Marked as reviewed by mgronlun (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27592#pullrequestreview-3294066759

From egahlin at openjdk.org  Thu Oct  2 15:54:56 2025
From: egahlin at openjdk.org (Erik Gahlin)
Date: Thu, 2 Oct 2025 15:54:56 GMT
Subject: Integrated: 8368670: Deadlock in JFR on event register + class load
In-Reply-To: <pGN17Uuhpz7g-hew3uW2LH8ASmnmkmS1_vxiSaagxOs=.f91eabd5-285a-46d3-9e87-99a704d0d27b@github.com>
References: <pGN17Uuhpz7g-hew3uW2LH8ASmnmkmS1_vxiSaagxOs=.f91eabd5-285a-46d3-9e87-99a704d0d27b@github.com>
Message-ID: <TloyjyfdIqDohbJJLacWHr4m9sC172Lr9vBc61lPfA8=.87658be6-bb3d-46ae-bdc3-82d913171689@github.com>

On Wed, 1 Oct 2025 16:56:53 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

> Could I have a review a PR that prevents a deadlock? The MetadataRepository::isEnabled check is an optimization that allows JFR to instrument disabled event classes lazily.
> 
> The available settings object is never modified after it has been created, so it is sufficient to publish it using a volatile.
> 
> 
> Testing: jdk/jdk/jfr
> 
> Thanks
> Erik

This pull request has now been integrated.

Changeset: 5fccabff
Author:    Erik Gahlin <egahlin at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5fccabff15ae8bcc3d03156fa331bbc0fefb0cbe
Stats:     2 lines in 2 files changed: 0 ins; 0 del; 2 mod

8368670: Deadlock in JFR on event register + class load

Reviewed-by: mgronlun

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

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