egahlin left a comment References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

<3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com> Message-ID: On Tue, 7 Oct 2025 04:44:24 GMT, David Holmes wrote: >> Agree! HT flag is set even though it is E-core (do not have HT), and also we cannot get number of physical cores, hence cores-per-cpu is always incorrect as you said. > > Can we not check for "Intel Hybrid Information" CPUID leaf (0x1A) that reports the type of each core and use that to get an accurate core count? So that: > > int cores_per_cpu() { > if (is_hybrid()) { > if (hyper_threaded() ) { > return _no_of_threads - _no_of_e_cores; > } else { > return _no_of_threads; > } > } else { > return _no_of_threads / threads_per_core(); > } > } I think it is difficult for the following reasons: 1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c 2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2409430996 From dholmes at openjdk.org Tue Oct 7 07:10:49 2025 From: dholmes at openjdk.org (David Holmes) Date: Tue, 7 Oct 2025 07:10:49 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v3] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

<3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>

<3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>

Message-ID: On Tue, 7 Oct 2025 07:07:51 GMT, David Holmes wrote: >> I think it is difficult for the following reasons: >> >> 1. We need to set affinity & issue `CPUID` leaf 1Ah on all of cores. See example: https://github.com/YaSuenag/garakuta/blob/master/check-hybrid-cores/hy-core-check.c >> 2. E-core does not have HT for now, but we don't know this architecture (P core has HT, both E core and LP E core do not have HT) keeps in future. > > Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query. > > I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway. > > So where does this leave us? > - `cores_per_cpu` is an approximation > - anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation Based on the comments that I'm reading in this PR, it seems like the existing logic presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing (AMP) or is the AMP support in a different place in the code. A very long time ago, Solaris SPARC servers could be provisioned with differing processors with different core counts and speed ratings. I don't know if we supported those AMP servers in Java or not, but there was definitely support in Solaris itself. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2411598511 From ysuenaga at openjdk.org Wed Oct 8 00:13:42 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 8 Oct 2025 00:13:42 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v5] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

<3uYc5vP8m6zRthfgWuBy59ooA3xqNKAu_v-SPrm7RXU=.a739b7eb-5135-43c8-ae33-c746d8187a79@github.com>

Message-ID: On Tue, 7 Oct 2025 18:56:11 GMT, Daniel D. Daugherty wrote: >> Oh that is awful - I did not realize that, I assumed we got some kind of bit vector we could query. >> >> I'm less concerned about them adding HT to E-cores in the future as we will likely have to expand the code to deal with specific chips anyway. >> >> So where does this leave us? >> - `cores_per_cpu` is an approximation >> - anything reporting the `cores_per_cpu` value needs to include some text (if it is a hybrid) to indicate it is an approximation > > Based on the comments that I'm reading in this PR, it seems like the existing logic > presumes Symmetric Multi-Processing (SMP) instead of Asymmetric Multi-Processing > (AMP) or is the AMP support in a different place in the code. > > A very long time ago, Solaris SPARC servers could be provisioned with differing processors > with different core counts and speed ratings. I don't know if we supported those AMP > servers in Java or not, but there was definitely support in Solaris itself. @dcubed-ojdk my recollection is that the "symmetry" in SMP related to memory accesses - but there are differing definitions. There is also a presumption that all "logical processors" behave effectively the same, and for multi-socket systems all CPU's are the same. That is still true-enough with these Hybrid chips, they just don't have the same internal topology so we can't coarsely assume we can calculate things like "number of cores" by knowing number-of-threads and whether hyper-threading is enabled. Unfortunately you also cannot easily get the exact details of that topology. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412394944 From dholmes at openjdk.org Wed Oct 8 03:34:05 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 03:34:05 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v5] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Tue, 7 Oct 2025 14:04:46 GMT, Yasumasa Suenaga 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: (0x6), Model: (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: > > Fix build error src/hotspot/cpu/x86/vm_version_x86.cpp line 2579: > 2577: if (threads_per_package == 0) { > 2578: // Fallback code to avoid div by zero in subsequent code. > 2579: // CPUID 0Bh (ECX = 1) might return 0 on older AMD processor (EPYC 7763 at least) Can we assert that this is not a hybrid CPU? src/hotspot/share/jfr/metadata/metadata.xml line 855: > 853: > 854: 855: description="Characteristics and descriptions of the processor(s) the JVM is running on. Note that "cores" field would be incorrect on hybrid CPU." Perhaps better stated on the cores field: ? But really this is for JFR folk to decide. Do these labels get used for GUI tools like JMC? BTW I assume that "hwThreads" is the number of logical processors - right? ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412407479 PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412412315 From ysuenaga at openjdk.org Wed Oct 8 06:17:06 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 8 Oct 2025 06:17:06 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v5] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

Message-ID: On Wed, 8 Oct 2025 06:14:03 GMT, Yasumasa Suenaga wrote: >> src/hotspot/share/jfr/metadata/metadata.xml line 855: >> >>> 853: >>> 854: >> 855: description="Characteristics and descriptions of the processor(s) the JVM is running on. Note that "cores" field would be incorrect on hybrid CPU." >> >> Perhaps better stated on the cores field: >> >> >> >> ? But really this is for JFR folk to decide. Do these labels get used for GUI tools like JMC? >> >> BTW I assume that "hwThreads" is the number of logical processors - right? > >> BTW I assume that "hwThreads" is the number of logical processors - right? > > Yes > Perhaps better stated on the cores field: Thanks for your comment! I added that sentence to `description` attribute in `Field` element. After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip) $ jfr metadata --events jdk.CPUInformation /tmp/test.jfr @Name("jdk.CPUInformation") @Category({"Operating System", "Processor"}) @Label("CPU Information") @Description("Characteristics and descriptions of the processor(s) the JVM is running on") class CPUInformation extends jdk.jfr.Event { @Label("Start Time") @Timestamp("TICKS") long startTime; @Label("Type") String cpu; @Label("Description") String description; @Unsigned @Label("Sockets") int sockets; @Unsigned @Label("Cores") @Description("Approximation on a hybrid CPU") int cores; @Unsigned @Label("Hardware Threads") int hwThreads; } ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412763021 From egahlin at openjdk.org Wed Oct 8 07:53:13 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 8 Oct 2025 07:53:13 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v5] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

Message-ID: On Wed, 8 Oct 2025 06:50:27 GMT, Yasumasa Suenaga wrote: >>> BTW I assume that "hwThreads" is the number of logical processors - right? >> >> Yes > >> Perhaps better stated on the cores field: > > Thanks for your comment! I added that sentence to `description` attribute in `Field` element. > After this change, flight record contains following metadata. I believe it would be parsed in some tools like JMC (JMC shows the description as a tooltip) > > > $ jfr metadata --events jdk.CPUInformation /tmp/test.jfr > @Name("jdk.CPUInformation") > @Category({"Operating System", "Processor"}) > @Label("CPU Information") > @Description("Characteristics and descriptions of the processor(s) the JVM is running on") > class CPUInformation extends jdk.jfr.Event { > @Label("Start Time") > @Timestamp("TICKS") > long startTime; > > @Label("Type") > String cpu; > > @Label("Description") > String description; > > @Unsigned > @Label("Sockets") > int sockets; > > @Unsigned > @Label("Cores") > @Description("Approximation on a hybrid CPU") > int cores; > > @Unsigned > @Label("Hardware Threads") > int hwThreads; > } Metadata looks good ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27080#discussion_r2412915309 From dholmes at openjdk.org Wed Oct 8 08:05:28 2025 From: dholmes at openjdk.org (David Holmes) Date: Wed, 8 Oct 2025 08:05:28 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v7] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com> Message-ID: On Wed, 8 Oct 2025 06:53:26 GMT, Yasumasa Suenaga 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: (0x6), Model: (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: > > Add description attribute to Field If @egahlin is happy with the JFR side then nothing further from me. Thanks ------------- Marked as reviewed by dholmes (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27080#pullrequestreview-3313499645 From jbechberger at openjdk.org Wed Oct 8 08:07:00 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Wed, 8 Oct 2025 08:07:00 GMT Subject: Integrated: 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: <9lF5MKUxf3lTZV9yUPqQx47DRn6zZCEnWSGy6Ld2uyo=.1d778c1e-44ae-405a-9395-d4cc93edb072@github.com> On Mon, 15 Sep 2025 12:17:13 GMT, Johannes Bechberger wrote: > This change hopefully fixes the test failures by making the test cases more resilient. This pull request has now been integrated. Changeset: d27649fe Author: Johannes Bechberger URL: https://git.openjdk.org/jdk/commit/d27649fe22a5bed9db72ac6c2595ac91f1fa28f8 Stats: 138 lines in 6 files changed: 47 ins; 46 del; 45 mod 8367302: New test jdk/jfr/event/profiling/TestCPUTimeSampleQueueAutoSizes.java from JDK-8366082 is failing Reviewed-by: dholmes, apangin ------------- PR: https://git.openjdk.org/jdk/pull/27293 From ysuenaga at openjdk.org Wed Oct 8 09:50:27 2025 From: ysuenaga at openjdk.org (Yasumasa Suenaga) Date: Wed, 8 Oct 2025 09:50:27 GMT Subject: RFR: 8366847: JFR reports incorrect number of cores on hybrid CPU [v5] In-Reply-To: References: <9ILw1TZZxnRFUkbaN-RBptc1hThJtSYS9ht6AA-6xss=.453edc4d-7efd-4b86-8ef3-c5ad4f3d3611@github.com>

Message-ID: On Fri, 17 Oct 2025 09:20:30 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> A tiny adjustment to the fix in https://bugs.openjdk.org/browse/JDK-8369255. >> >> A JavaThread must be in a safe safepoint state before taking an infinite nap; for convenience, it goes to _thread_in_native. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > comment Marked as reviewed by fandreuzzi (Author). ------------- PR Review: https://git.openjdk.org/jdk/pull/27862#pullrequestreview-3350449250 From mgronlun at openjdk.org Sun Oct 19 12:23:05 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Sun, 19 Oct 2025 12:23:05 GMT Subject: RFR: 8365400: enhance JFR to emit file and module metadata for class loading [v2] In-Reply-To: <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com> References: <2TCYpXA-OLJHgdSydEwnAyr4_dgJjrJHBAJQ-gKcmO0=.e6599df6-e9fe-4d43-ac6c-5cf2836c2cdb@github.com> Message-ID: On Thu, 16 Oct 2025 19:41:15 GMT, Larry Cable wrote: >> the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile. >> >> The location of the class file for a class defined can be of utility in both debugging and auditing. >> >> this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof > > Larry Cable has updated the pull request incrementally with one additional commit since the last revision: > > added package and module entries Package and Module information is implicitly included in the JFR model for a class (its transitive dependencies), so you do not need to include them explicitly. I prefer that the design address how the source information is to be included for the existing events (ClassLoad and ClassDefine). I am working on a symbol table implementation to help you out. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27738#issuecomment-3419623850 From duke at openjdk.org Mon Oct 20 17:25:14 2025 From: duke at openjdk.org (Larry Cable) Date: Mon, 20 Oct 2025 17:25:14 GMT Subject: Withdrawn: 8365400: enhance JFR to emit file and module metadata for class loading In-Reply-To: References: Message-ID: On Thu, 9 Oct 2025 21:04:41 GMT, Larry Cable wrote: > the existing` jdk.classDefine` and `jdk.ClassLoad` events do not include metadata regarding the location/source of the ClassFile. > > The location of the class file for a class defined can be of utility in both debugging and auditing. > > this addition introduces a new `jdk.ClassFileDefine` event which records the class defined and the location (path/url) of the class file that contained the implementation thereof This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/27738 From egahlin at openjdk.org Tue Oct 21 13:10:36 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Tue, 21 Oct 2025 13:10:36 GMT Subject: RFR: 8370242: JFR: Clear event reference eagerly when using EventStream Message-ID: Could I have review of a change that reduce the live set when using event streaming? Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Remove patch.txt - Initial Changes: https://git.openjdk.org/jdk/pull/27906/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27906&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370242 Stats: 11 lines in 2 files changed: 10 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/27906.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27906/head:pull/27906 PR: https://git.openjdk.org/jdk/pull/27906 From mgronlun at openjdk.org Tue Oct 21 16:28:59 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Tue, 21 Oct 2025 16:28:59 GMT Subject: RFR: 8370242: JFR: Clear event reference eagerly when using EventStream In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 20:50:41 GMT, Erik Gahlin wrote: > Could I have review of a change that reduce the live set when using event streaming? > > The EventDirectoryStream and EventFileStream classes may hold on to events longer than needed. If a burst of events occurs, the sorted cache is filled, but if fewer events are emitted later, old events still remain in the cache array. They should be cleared after they have been dispatched. > > This is effectively a memory leak, although it does not grow over time. > > Testing: jdk/jdk/jfr > > Thanks > Erik Looks good. ------------- Marked as reviewed by mgronlun (Reviewer). PR Review: https://git.openjdk.org/jdk/pull/27906#pullrequestreview-3361647146 From egahlin at openjdk.org Wed Oct 22 11:30:27 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 22 Oct 2025 11:30:27 GMT Subject: Integrated: 8370242: JFR: Clear event reference eagerly when using EventStream In-Reply-To: References: Message-ID: On Mon, 20 Oct 2025 20:50:41 GMT, Erik Gahlin wrote: > Could I have review of a change that reduce the live set when using event streaming? > > The EventDirectoryStream and EventFileStream classes may hold on to events longer than needed. If a burst of events occurs, the sorted cache is filled, but if fewer events are emitted later, old events still remain in the cache array. They should be cleared after they have been dispatched. > > This is effectively a memory leak, although it does not grow over time. > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has now been integrated. Changeset: 65b32394 Author: Erik Gahlin URL: https://git.openjdk.org/jdk/commit/65b32394187988abab99a8017eda39b1bd4a1782 Stats: 11 lines in 2 files changed: 10 ins; 1 del; 0 mod 8370242: JFR: Clear event reference eagerly when using EventStream Reviewed-by: mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/27906 From egahlin at openjdk.org Wed Oct 22 12:58:09 2025 From: egahlin at openjdk.org (Erik Gahlin) Date: Wed, 22 Oct 2025 12:58:09 GMT Subject: RFR: 8369991: Thread blocking during JFR emergency dump must be in safepoint safe state [v2] In-Reply-To: References:

Message-ID: On Fri, 17 Oct 2025 09:20:30 GMT, Markus Gr?nlund wrote: >> Greetings, >> >> A tiny adjustment to the fix in https://bugs.openjdk.org/browse/JDK-8369255. >> >> A JavaThread must be in a safe safepoint state before taking an infinite nap; for convenience, it goes to _thread_in_native. >> >> Testing: jdk_jfr >> >> Thanks >> Markus > > Markus Gr?nlund has updated the pull request incrementally with one additional commit since the last revision: > > comment Marked as reviewed by egahlin (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/27862#pullrequestreview-3365665374 From duke at openjdk.org Wed Oct 22 16:48:04 2025 From: duke at openjdk.org (duke) Date: Wed, 22 Oct 2025 16:48:04 GMT Subject: Withdrawn: 8356968: JFR: Compilation event should be enabled for all compilations by default In-Reply-To: References: Message-ID: On Thu, 15 May 2025 08:49:47 GMT, Aleksey Shipilev wrote: > In the field, we are using -XX:+PrintCompilation to track compiler performance. Alternatively, -Xlog:jit* prints the same. JFR has a the related jdk.Compilation event that gives us even richer diagnostics. Yet, that event is set at a very high threshold (1000ms), which skips almost all compilations! This threshold is set to such a high value from the beginning. > > It is fairly normal to have lots of compilations in 100+ ms range individually, and their sum impact is what we are after. Also, the compilations are normally quite rare, and there are a couple of thousands of compiles in most workloads, and they only happen sporadically. This means, the event count without any threshold is not high. > > Therefore, it would be convenient to make sure that basic Compilation event is enabled unconditionally, e.g. by dropping the default threshold to 0. > > See more logs in the bug itself. > > Additional testing: > - [x] Ad-hoc tests with printing compilation events > - [x] Linux x86_64 server fastdebug, `jdk_jfr` This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/25247 From mgronlun at openjdk.org Wed Oct 22 17:42:45 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Wed, 22 Oct 2025 17:42:45 GMT Subject: Integrated: 8369991: Thread blocking during JFR emergency dump must be in safepoint safe state In-Reply-To: References: Message-ID: On Fri, 17 Oct 2025 09:06:09 GMT, Markus Gr?nlund wrote: > Greetings, > > A tiny adjustment to the fix in https://bugs.openjdk.org/browse/JDK-8369255. > > A JavaThread must be in a safe safepoint state before taking an infinite nap; for convenience, it goes to _thread_in_native. > > Testing: jdk_jfr > > Thanks > Markus This pull request has now been integrated. Changeset: afba6368 Author: Markus Gr?nlund URL: https://git.openjdk.org/jdk/commit/afba636869bc297d0c9c29fbe7f2a1eb5929218b Stats: 10 lines in 1 file changed: 6 ins; 1 del; 3 mod 8369991: Thread blocking during JFR emergency dump must be in safepoint safe state Reviewed-by: fandreuzzi, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/27862 From sgehwolf at openjdk.org Fri Oct 24 08:23:04 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Oct 2025 08:23:04 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> Message-ID: <8RgpPnr9F8ltCUSxU81hfH-u7KgK7FQRIiKufU_Lg5o=.3aeb406d-c9c2-44fa-a707-8e59d7ce6652@github.com> On Fri, 10 Oct 2025 13:09:48 GMT, Severin Gehwolf wrote: > Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values. > > It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned. > > All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for. > > All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code. > > While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large. > > Testing (looking good): > - [x] GHA > - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below. > - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command. > > Thoughts? Opinions? Could anybody please help review this! Thank you. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3441752392 From jbachorik at openjdk.org Fri Oct 24 08:39:05 2025 From: jbachorik at openjdk.org (Jaroslav Bachorik) Date: Fri, 24 Oct 2025 08:39:05 GMT Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler [v4] In-Reply-To: References:

Message-ID: <8TRs1C7c58rgQICbL_-ArygqQIZm6D5WnXKSbZU3kN8=.28cae14d-ded9-4def-bb54-efae076f0b1c@github.com> On Tue, 14 Oct 2025 07:29:41 GMT, Johannes Bechberger wrote: >> 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 five commits: > > - Merge branch 'master' of https://git.openjdk.org/jdk into parttimenerd_reduce_synchronization > - Merge branch 'master' into parttimenerd_reduce_synchronization > - Extend comment > - Remove unnecessary line > - Remove redundant synchronization Marked as reviewed by jbachorik (Reviewer). ------------- PR Review: https://git.openjdk.org/jdk/pull/26960#pullrequestreview-3375130649 From jbechberger at openjdk.org Fri Oct 24 08:58:22 2025 From: jbechberger at openjdk.org (Johannes Bechberger) Date: Fri, 24 Oct 2025 08:58:22 GMT Subject: Integrated: 8366240: Improve memory ordering in new CPU Time Profiler In-Reply-To: References: Message-ID: <3FBp8jUWmSes6DBh-sb1jfUBv6jAICRXl6vigE7KXqM=.779396fe-62fe-48ec-b05f-0ecbc9d444e1@github.com> On Wed, 27 Aug 2025 12:50:13 GMT, Johannes Bechberger wrote: > Remove acq-rel semantics where it isn't needed. This pull request has now been integrated. Changeset: b7a4c9ce Author: Johannes Bechberger URL: https://git.openjdk.org/jdk/commit/b7a4c9ced82717434e43b3f3a0a57083f4005f32 Stats: 41 lines in 2 files changed: 12 ins; 12 del; 17 mod 8366240: Improve memory ordering in new CPU Time Profiler Reviewed-by: jbachorik, krk, zgu ------------- PR: https://git.openjdk.org/jdk/pull/26960 From aph at openjdk.org Fri Oct 24 09:39:02 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 24 Oct 2025 09:39:02 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> Message-ID: On Fri, 10 Oct 2025 13:09:48 GMT, Severin Gehwolf wrote: > Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values. > > It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned. > > All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for. > > All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code. > > While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large. > > Testing (looking good): > - [x] GHA > - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below. > - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command. > > Thoughts? Opinions? I'm not surprised about the lack of reviews because it's long and the result is rather ugly. (Sorry, but I had to say it.) This is less jarring to read: struct Result { const int _value; const bool _ok; Result(int value, bool ok) : _value(value), _ok(ok) {} }; ... Result CgroupSubsystem::active_processor_count() { ... cpu_count = os::Linux::active_processor_count(); if (!CgroupUtil::processor_count(contrl->controller(), cpu_count, value)) { return Result(value, false); } assert(value > 0 && value <= cpu_count, "must be"); // Update cached metric to avoid re-reading container settings too often cpu_limit->set_value(value, OSCONTAINER_CACHE_TIMEOUT); return Result(value, true); } called as: auto [result, ok] = cgroup_subsystem->active_processor_count(); if (ok) ... ------------- PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442136772 From sgehwolf at openjdk.org Fri Oct 24 09:45:25 2025 From: sgehwolf at openjdk.org (Severin Gehwolf) Date: Fri, 24 Oct 2025 09:45:25 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong [v2] In-Reply-To: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> Message-ID: <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com> > Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values. > > It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned. > > All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for. > > All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code. > > While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large. > > Testing (looking good): > - [x] GHA > - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below. > - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command. > > Thoughts? Opinions? Severin Gehwolf 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 jdk-8365606-jlong-julong-refactor - Fix print_container_info output - whitespace clean-ups and other small fixes - Fix log format in container macro and scanf format - Fix duplicate include in osContainer_linux - 8365606: Container code should not be using jlong/julong ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27743/files - new: https://git.openjdk.org/jdk/pull/27743/files/e906490e..917a51c6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27743&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27743&range=00-01 Stats: 39117 lines in 885 files changed: 23412 ins; 10970 del; 4735 mod Patch: https://git.openjdk.org/jdk/pull/27743.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27743/head:pull/27743 PR: https://git.openjdk.org/jdk/pull/27743 From cnorrbin at openjdk.org Fri Oct 24 10:50:03 2025 From: cnorrbin at openjdk.org (Casper Norrbin) Date: Fri, 24 Oct 2025 10:50:03 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong [v2] In-Reply-To: <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com> References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com> Message-ID: On Fri, 24 Oct 2025 09:45:25 GMT, Severin Gehwolf wrote: >> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values. >> >> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned. >> >> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for. >> >> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code. >> >> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large. >> >> Testing (looking good): >> - [x] GHA >> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below. >> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command. >> >> Thoughts? Opinions? > > Severin Gehwolf 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 jdk-8365606-jlong-julong-refactor > - Fix print_container_info output > - whitespace clean-ups and other small fixes > - Fix log format in container macro and scanf format > - Fix duplicate include in osContainer_linux > - 8365606: Container code should not be using jlong/julong I'm currently looking at this, just as a quick FYI. I'm fine with the proposed interface as it is (boolean return + passed reference). Since the adjacent `os` functions recently changed to use this interface, and the disproportionate (to me) amount of bikeshedding it took to reach a consensus on that, introducing yet another interface here, for what's essentially a subcomponent, doesn't make much sense. It's clearer if the whole `os` stack sticks to the same interface. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442470839 From stuefe at openjdk.org Fri Oct 24 11:27:04 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Oct 2025 11:27:04 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong [v2] In-Reply-To: References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com> Message-ID: On Fri, 24 Oct 2025 10:46:52 GMT, Casper Norrbin wrote: > I'm currently looking at this, just as a quick FYI. > > I'm fine with the proposed interface as it is (boolean return + passed reference). Since the adjacent `os` functions recently changed to use this interface, and the disproportionate (to me) amount of bikeshedding it took to reach a consensus on that, introducing yet another interface here, for what's essentially a subcomponent, doesn't make much sense. It's clearer if the whole `os` stack sticks to the same interface. I agree. Its not pretty, but consistent with what we did elsewhere. Nobody wants to do that discussion again. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442620964 From stuefe at openjdk.org Fri Oct 24 11:31:07 2025 From: stuefe at openjdk.org (Thomas Stuefe) Date: Fri, 24 Oct 2025 11:31:07 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong [v2] In-Reply-To: <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com> References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com> Message-ID: On Fri, 24 Oct 2025 09:45:25 GMT, Severin Gehwolf wrote: >> Please review this revised version of getting rid of `jlong` and `julong` in internal HotSpot code. The single remaining usage is using `os::elapsed_counter()` which I think is still ok. This refactoring is for the container detection code to (mostly) do away with negative return values. >> >> It gets rid of the trifold-use of return value: 1.) error, 2) unlimited values 3) actual numbers/values/limits. Instead, all container related values are now being read from the interface files as `uint64_t` and afterwards interpreted in the way that make sense for the API implementations. For example, `cpu` values will essentially be treated as `int`s as before, potentially returning a negative value `-1` for unlimited. For memory sizes the type `physical_memory_size_type` has been chosen. When there is no limit for a specific memory size a value `value_unlimited` is being returned. >> >> All error cases have been changed to returning `false` in the API functions (and no value is being set in the passed in reference for the value). The effect of this is that all container related functions now return a `bool` and require a reference to be passed in for the `value` that is being asked for. >> >> All usages of the API have been changed to use the revised API. There is no more usages for `OSCONTAINER_ERROR` (`-2) in HotSpot code. >> >> While working on this, I've noticed that there are still some calls deep in the cgroup subsystem code to query "machine" info (e.g. `os::Linux::active_processor_count()`). I've filed [JDK-8369503](https://bugs.openjdk.org/browse/JDK-8369503) to get this cleaned-up as this patch was already getting large. >> >> Testing (looking good): >> - [x] GHA >> - [x] All container tests (including problem listed ones) on Linux x86_64 with cg v1 and cg v2. See [this comment](https://github.com/openjdk/jdk/pull/27743#issuecomment-3390060127) below. >> - [x] Some ad-hoc manual testing in containers using JFR (`jdk.SwapSpace` event) and `VM.info` diagnostic command. >> >> Thoughts? Opinions? > > Severin Gehwolf 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 jdk-8365606-jlong-julong-refactor > - Fix print_container_info output > - whitespace clean-ups and other small fixes > - Fix log format in container macro and scanf format > - Fix duplicate include in osContainer_linux > - 8365606: Container code should not be using jlong/julong Mostly looks good to me. Some remnants of raw UINT64_FORMAT are left. I did not see any type clashes. I hold off the final review until it is clear that the interfaces are agreed upon. src/hotspot/os/linux/cgroupSubsystem_linux.cpp line 638: > 636: bool CgroupSubsystem::active_processor_count(int& value) { > 637: int cpu_count; > 638: int result = -1; Why not get rid of result and use `value` throughout like you did in the cached case? src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 80: > 78: return false; \ > 79: } \ > 80: log_trace(os, container)(log_string " is: " UINT64_FORMAT, retval); \ Here and in other places: don't use raw UINT64_FORMAT; use `PHYS_MEM_TYPE_FORMAT` instead. src/hotspot/os/linux/cgroupSubsystem_linux.hpp line 105: > 103: is_ok = controller->read_string(filename, retval, buf_size); \ > 104: if (!is_ok) { \ > 105: log_trace(os, container)(log_string " failed: -2"); \ Why this change? Did the constant value change? ------------- PR Review: https://git.openjdk.org/jdk/pull/27743#pullrequestreview-3375466876 PR Review Comment: https://git.openjdk.org/jdk/pull/27743#discussion_r2459590069 PR Review Comment: https://git.openjdk.org/jdk/pull/27743#discussion_r2459894453 PR Review Comment: https://git.openjdk.org/jdk/pull/27743#discussion_r2459898806 From aph at openjdk.org Fri Oct 24 12:28:16 2025 From: aph at openjdk.org (Andrew Haley) Date: Fri, 24 Oct 2025 12:28:16 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong [v2] In-Reply-To: References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>

Message-ID: On Fri, 24 Oct 2025 11:24:48 GMT, Thomas Stuefe wrote: > > I agree. Its not pretty, but consistent with what we did elsewhere. Nobody wants to do that discussion again. Sorry, I was unaware of any previous discussion. I was suggesting a less impactful way to make the change, taking advantage of the recent adoption of C++17, which allows for cleaner code. But I won't stand in the way of consensus. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3442865789 From syan at openjdk.org Sat Oct 25 01:11:24 2025 From: syan at openjdk.org (SendaoYan) Date: Sat, 25 Oct 2025 01:11:24 GMT Subject: RFR: 8366240: Improve memory ordering in new CPU Time Profiler [v4] In-Reply-To: References:

Message-ID: <9uVKpiWCXvxcxhyg6V1seeSxyLm14lHEdOL_I07uVQs=.de1b0ed8-d006-49d5-a982-27556759415e@github.com> On Fri, 24 Oct 2025 12:25:36 GMT, Andrew Haley wrote: > > I agree. Its not pretty, but consistent with what we did elsewhere. Nobody wants to do that discussion again. > > Sorry, I was unaware of any previous discussion. I was suggesting a less impactful way to make the change, taking advantage of the recent adoption of C++17, which allows for cleaner code. But I won't stand in the way of consensus. FWIW, I'd be interested in seeing a small example of what that would look like with C++17. There were a lot of discussion about the style, but it wasn't because we wanted to figure out the color of the bike shed but rather how to write safer code that makes it less likely to accidentally introduce bugs because of type conflation. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3450057392 From aph at openjdk.org Mon Oct 27 09:20:10 2025 From: aph at openjdk.org (Andrew Haley) Date: Mon, 27 Oct 2025 09:20:10 GMT Subject: RFR: 8365606: Container code should not be using jlong/julong [v2] In-Reply-To: <9uVKpiWCXvxcxhyg6V1seeSxyLm14lHEdOL_I07uVQs=.de1b0ed8-d006-49d5-a982-27556759415e@github.com> References: <-8aFRr9Hv0gxOufHCTreBgrkFSatpHjQytEVDQ-v8mY=.7ab7d7b7-09a0-4ae4-b084-e8bf285491bb@github.com> <0IQ106BTnoNfWulWJ30t9uWy5OH2EF4Y0kC_jZlgU6g=.84583e9b-1d06-440c-8c34-670ebfc7940f@github.com>

<9uVKpiWCXvxcxhyg6V1seeSxyLm14lHEdOL_I07uVQs=.de1b0ed8-d006-49d5-a982-27556759415e@github.com> Message-ID: On Mon, 27 Oct 2025 08:33:22 GMT, Stefan Karlsson wrote: > it wasn't because we wanted to figure out the color of the bike shed but rather how to write safer code that makes it less likely to accidentally introduce bugs because of type conflation. This. A function that returns its value as a side effect on a reference parameter is (at best) a code smell. ------------- PR Comment: https://git.openjdk.org/jdk/pull/27743#issuecomment-3450229373 From rcastanedalo at openjdk.org Mon Oct 27 09:20:18 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 27 Oct 2025 09:20:18 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v2] In-Reply-To: References:

Message-ID: On Mon, 27 Oct 2025 09:01:08 GMT, Roberto Casta?eda Lozano wrote: >> Anton Seoane Ampudia 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 seven additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8347463 >> - Merge branch 'JDK-8347463' of github.com:anton-seoane/jdk into JDK-8347463 >> - Merge branch 'openjdk:master' into JDK-8347463 >> - Documentation for future similar cases >> - Test for JDK-8347463 >> - Change to a more specific type >> - Runtime call had void type but actually returned an object > > test/hotspot/jtreg/compiler/intrinsics/TestReturnsOopSetForJFRWriteCheckpoint.java line 29: > >> 27: >> 28: import jdk.jfr.Event; >> 29: import jdk.jfr.Name; > > Unused, please remove. I think you mean just line 29? AFAIK we need the header and importing the basics for testing (line 29 is unused, yes) ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27913#discussion_r2464973697 From aseoane at openjdk.org Mon Oct 27 09:41:24 2025 From: aseoane at openjdk.org (Anton Seoane Ampudia) Date: Mon, 27 Oct 2025 09:41:24 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v4] In-Reply-To: References: Message-ID: > This PR introduces a fix for a intermittent assert crash due to a non-oop found in the stack when deoptimizing. > > The `inline_native_GetEventWriter` JFR intrinsic performs a call into the runtime, which can safepoint, to write a checkpoint for the vthread. This call returns a global handle (`jobject`) that then gets resolved to a raw oop. > > However, the corresponding `jfr_write_checkpoint_Type` does not set any return, modelling the call as `void`. If a safepoint hits in the small window after the stub returns but before the writer oop is used, and the GC moves the object in that window, the deoptimization path cannot resolve a handle that it never recorded, leading to the subsequent crash. > > An IR Framework test is introduced to exercise the error explicitly. Additionally, related documentation in form of comments in the appropriate file (`runtime.hpp`) is added to hopefully prevent similar cases in the future. > > **Testing:** passes tiers 1-5 Anton Seoane Ampudia has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/compiler/intrinsics/TestReturnsOopSetForJFRWriteCheckpoint.java Co-authored-by: Roberto Casta?eda Lozano ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27913/files - new: https://git.openjdk.org/jdk/pull/27913/files/51fb388b..e91cd483 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=03 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=02-03 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27913/head:pull/27913 PR: https://git.openjdk.org/jdk/pull/27913 From rcastanedalo at openjdk.org Mon Oct 27 09:41:27 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 27 Oct 2025 09:41:27 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v2] In-Reply-To: References:

Message-ID: On Mon, 27 Oct 2025 09:32:31 GMT, Anton Seoane Ampudia wrote: >> test/hotspot/jtreg/compiler/intrinsics/TestReturnsOopSetForJFRWriteCheckpoint.java line 29: >> >>> 27: >>> 28: import jdk.jfr.Event; >>> 29: import jdk.jfr.Name; >> >> Unused, please remove. > > I think you mean just line 29? AFAIK we need the header and importing the basics for testing (line 29 is unused, yes) Right, just line 29. >> test/hotspot/jtreg/compiler/intrinsics/TestReturnsOopSetForJFRWriteCheckpoint.java line 38: >> >>> 36: * @requires vm.hasJFR & vm.continuations >>> 37: * @library /test/lib / >>> 38: * @modules jdk.jfr/jdk.jfr.internal >> >> Do we need this? > > We don't. Removed as well! (Referring to line 38 only). ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27913#discussion_r2464990761 PR Review Comment: https://git.openjdk.org/jdk/pull/27913#discussion_r2464991906 From aseoane at openjdk.org Mon Oct 27 09:41:30 2025 From: aseoane at openjdk.org (Anton Seoane Ampudia) Date: Mon, 27 Oct 2025 09:41:30 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v2] In-Reply-To: References:

Message-ID: On Mon, 27 Oct 2025 09:07:49 GMT, Roberto Casta?eda Lozano wrote: >> Anton Seoane Ampudia 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 seven additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8347463 >> - Merge branch 'JDK-8347463' of github.com:anton-seoane/jdk into JDK-8347463 >> - Merge branch 'openjdk:master' into JDK-8347463 >> - Documentation for future similar cases >> - Test for JDK-8347463 >> - Change to a more specific type >> - Runtime call had void type but actually returned an object > > test/hotspot/jtreg/compiler/intrinsics/TestReturnsOopSetForJFRWriteCheckpoint.java line 36: > >> 34: * @summary Tests that the getEventWriter call to write_checkpoint correctly >> 35: * reports returning an oop >> 36: * @requires vm.hasJFR & vm.continuations > > Do we need `vm.continuations`? We don't. Removed the requirement > test/hotspot/jtreg/compiler/intrinsics/TestReturnsOopSetForJFRWriteCheckpoint.java line 38: > >> 36: * @requires vm.hasJFR & vm.continuations >> 37: * @library /test/lib / >> 38: * @modules jdk.jfr/jdk.jfr.internal > > Do we need this? We don't. Removed as well! ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/27913#discussion_r2464983164 PR Review Comment: https://git.openjdk.org/jdk/pull/27913#discussion_r2464989996 From aseoane at openjdk.org Mon Oct 27 09:53:16 2025 From: aseoane at openjdk.org (Anton Seoane Ampudia) Date: Mon, 27 Oct 2025 09:53:16 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v5] In-Reply-To: References: Message-ID: <3Dnm4je4PJq-qCbRaaxg7slgI7i3Iz5Tn19_jnYk7I0=.18015b63-6ad6-46e5-ae52-808f94140839@github.com> > This PR introduces a fix for a intermittent assert crash due to a non-oop found in the stack when deoptimizing. > > The `inline_native_GetEventWriter` JFR intrinsic performs a call into the runtime, which can safepoint, to write a checkpoint for the vthread. This call returns a global handle (`jobject`) that then gets resolved to a raw oop. > > However, the corresponding `jfr_write_checkpoint_Type` does not set any return, modelling the call as `void`. If a safepoint hits in the small window after the stub returns but before the writer oop is used, and the GC moves the object in that window, the deoptimization path cannot resolve a handle that it never recorded, leading to the subsequent crash. > > An IR Framework test is introduced to exercise the error explicitly. Additionally, related documentation in form of comments in the appropriate file (`runtime.hpp`) is added to hopefully prevent similar cases in the future. > > **Testing:** passes tiers 1-5 Anton Seoane Ampudia has updated the pull request incrementally with one additional commit since the last revision: Apply review comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27913/files - new: https://git.openjdk.org/jdk/pull/27913/files/e91cd483..9191c3b3 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=04 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=03-04 Stats: 8 lines in 1 file changed: 1 ins; 5 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/27913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27913/head:pull/27913 PR: https://git.openjdk.org/jdk/pull/27913 From aseoane at openjdk.org Mon Oct 27 09:53:19 2025 From: aseoane at openjdk.org (Anton Seoane Ampudia) Date: Mon, 27 Oct 2025 09:53:19 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v2] In-Reply-To: References:

Message-ID: <_P2PY-zh8RX87bQtxQuZ-54vzcwK4uvdm15dauAwo7w=.7c17f75d-b8ae-463b-95b2-58e3ba8c8444@github.com> On Mon, 27 Oct 2025 09:17:29 GMT, Roberto Casta?eda Lozano wrote: >> Anton Seoane Ampudia 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 seven additional commits since the last revision: >> >> - Merge branch 'openjdk:master' into JDK-8347463 >> - Merge branch 'JDK-8347463' of github.com:anton-seoane/jdk into JDK-8347463 >> - Merge branch 'openjdk:master' into JDK-8347463 >> - Documentation for future similar cases >> - Test for JDK-8347463 >> - Change to a more specific type >> - Runtime call had void type but actually returned an object > > Thanks for getting to the bottom of this, Ant?n! The changeset looks good to me, modulo a few documentation and test comments. > It would be good if someone from the JFR team (@mgronlun or @egahlin?) could have a look at this change as well. Thanks for your review @robcasloz! I have updated the changeset according to your comments ------------- PR Comment: https://git.openjdk.org/jdk/pull/27913#issuecomment-3450399965 From mgronlun at openjdk.org Mon Oct 27 10:25:26 2025 From: mgronlun at openjdk.org (Markus =?UTF-8?B?R3LDtm5sdW5k?=) Date: Mon, 27 Oct 2025 10:25:26 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v5] In-Reply-To: <3Dnm4je4PJq-qCbRaaxg7slgI7i3Iz5Tn19_jnYk7I0=.18015b63-6ad6-46e5-ae52-808f94140839@github.com> References: <3Dnm4je4PJq-qCbRaaxg7slgI7i3Iz5Tn19_jnYk7I0=.18015b63-6ad6-46e5-ae52-808f94140839@github.com> Message-ID: On Mon, 27 Oct 2025 09:53:16 GMT, Anton Seoane Ampudia wrote: >> This PR introduces a fix for a intermittent assert crash due to a non-oop found in the stack when deoptimizing. >> >> The `inline_native_GetEventWriter` JFR intrinsic performs a call into the runtime, which can safepoint, to write a checkpoint for the vthread. This call returns a global handle (`jobject`) that then gets resolved to a raw oop. >> >> However, the corresponding `jfr_write_checkpoint_Type` does not set any return, modelling the call as `void`. If a safepoint hits in the small window after the stub returns but before the writer oop is used, and the GC moves the object in that window, the deoptimization path cannot resolve a handle that it never recorded, leading to the subsequent crash. >> >> An IR Framework test is introduced to exercise the error explicitly. Additionally, related documentation in form of comments in the appropriate file (`runtime.hpp`) is added to hopefully prevent similar cases in the future. >> >> **Testing:** passes tiers 1-5 > > Anton Seoane Ampudia has updated the pull request incrementally with one additional commit since the last revision: > > Apply review comments Marked as reviewed by mgronlun (Reviewer). Thanks for getting to the cause and fixing this. ------------- PR Review: https://git.openjdk.org/jdk/pull/27913#pullrequestreview-3382775048 PR Comment: https://git.openjdk.org/jdk/pull/27913#issuecomment-3450540758 From aseoane at openjdk.org Mon Oct 27 10:40:32 2025 From: aseoane at openjdk.org (Anton Seoane Ampudia) Date: Mon, 27 Oct 2025 10:40:32 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v6] In-Reply-To: References: Message-ID: > This PR introduces a fix for a intermittent assert crash due to a non-oop found in the stack when deoptimizing. > > The `inline_native_GetEventWriter` JFR intrinsic performs a call into the runtime, which can safepoint, to write a checkpoint for the vthread. This call returns a global handle (`jobject`) that then gets resolved to a raw oop. > > However, the corresponding `jfr_write_checkpoint_Type` does not set any return, modelling the call as `void`. If a safepoint hits in the small window after the stub returns but before the writer oop is used, and the GC moves the object in that window, the deoptimization path cannot resolve a handle that it never recorded, leading to the subsequent crash. > > An IR Framework test is introduced to exercise the error explicitly. Additionally, related documentation in form of comments in the appropriate file (`runtime.hpp`) is added to hopefully prevent similar cases in the future. > > **Testing:** passes tiers 1-5 Anton Seoane Ampudia has updated the pull request incrementally with one additional commit since the last revision: Update test/hotspot/jtreg/compiler/intrinsics/TestReturnsOopSetForJFRWriteCheckpoint.java Co-authored-by: Roberto Casta?eda Lozano ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27913/files - new: https://git.openjdk.org/jdk/pull/27913/files/9191c3b3..280141be Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=05 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=04-05 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27913.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27913/head:pull/27913 PR: https://git.openjdk.org/jdk/pull/27913 From rcastanedalo at openjdk.org Mon Oct 27 10:40:35 2025 From: rcastanedalo at openjdk.org (Roberto =?UTF-8?B?Q2FzdGHDsWVkYQ==?= Lozano) Date: Mon, 27 Oct 2025 10:40:35 GMT Subject: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v5] In-Reply-To: <3Dnm4je4PJq-qCbRaaxg7slgI7i3Iz5Tn19_jnYk7I0=.18015b63-6ad6-46e5-ae52-808f94140839@github.com> References: <3Dnm4je4PJq-qCbRaaxg7slgI7i3Iz5Tn19_jnYk7I0=.18015b63-6ad6-46e5-ae52-808f94140839@github.com> Message-ID: On Mon, 27 Oct 2025 09:53:16 GMT, Anton Seoane Ampudia