October 2025 - hotspot-jfr-dev

RFR: 8365606: Container code should not be using jlong/julong
by Severin Gehwolf 18 Nov '25

18 Nov '25

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? ------------- Commit messages: - 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: https://git.openjdk.org/jdk/pull/27743/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27743&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8365606 Stats: 1247 lines in 16 files changed: 477 ins; 111 del; 659 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

7 54

Re: RFR: 8037914: Add JFR event for string deduplication
by Erik Gahlin 06 Nov '25

06 Nov '25

On Tue, 28 Oct 2025 10:09:58 GMT, Francesco Andreuzzi <fandreuzzi(a)openjdk.org> wrote: > In this PR I introduce two new JFR events: > - `jdk.StringDeduplicationStatistics` > - `jdk.StringDeduplicationTimes` > > The events are emitted every time a deduplication cycle happens, and they contain information about that cycle only. > > Passes tier1 and tier2 (fastdebug). Why do you need two events instead of one? ------------- PR Comment: https://git.openjdk.org/jdk/pull/28015#issuecomment-3458838597

2 11

RFR: 8370260: Test jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java timed out
by Yasumasa Suenaga 03 Nov '25

03 Nov '25

The test failure was reported at jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java due to minidump timeout. `TestEmergencyDumpAtOOM` does not need minidump, so we can add `-XX:-CreateCoredumpOnCrash` to the test process. This change works on Windows 11 Pro 25H2 and Fedora 42. ------------- Commit messages: - 8370260: jdk/jfr/event/oldobject/TestEmergencyDumpAtOOM.java timed out Changes: https://git.openjdk.org/jdk/pull/27993/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27993&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8370260 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/27993.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/27993/head:pull/27993 PR: https://git.openjdk.org/jdk/pull/27993

3 4

Re: RFR: 8037914: Add JFR event for string deduplication [v3]
by Francesco Andreuzzi 29 Oct '25

29 Oct '25

> In this PR I introduce two new JFR events: > - `jdk.StringDeduplicationStatistics` > - `jdk.StringDeduplicationTimes` > > The events are emitted every time a deduplication cycle happens, and they contain information about that cycle only. > > Passes tier1 and tier2 (fastdebug). Francesco Andreuzzi has updated the pull request incrementally with two additional commits since the last revision: - disable - revert ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28015/files - new: https://git.openjdk.org/jdk/pull/28015/files/bff0fd30..c3c9a8db Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=01-02 Stats: 3 lines in 2 files changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28015/head:pull/28015 PR: https://git.openjdk.org/jdk/pull/28015

1 0

Re: RFR: 8037914: Add JFR event for string deduplication [v2]
by Francesco Andreuzzi 29 Oct '25

29 Oct '25

> In this PR I introduce two new JFR events: > - `jdk.StringDeduplicationStatistics` > - `jdk.StringDeduplicationTimes` > > The events are emitted every time a deduplication cycle happens, and they contain information about that cycle only. > > Passes tier1 and tier2 (fastdebug). Francesco Andreuzzi has updated the pull request incrementally with one additional commit since the last revision: one event ------------- Changes: - all: https://git.openjdk.org/jdk/pull/28015/files - new: https://git.openjdk.org/jdk/pull/28015/files/1cb7d996..bff0fd30 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=01 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28015&range=00-01 Stats: 61 lines in 8 files changed: 8 ins; 52 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/28015.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/28015/head:pull/28015 PR: https://git.openjdk.org/jdk/pull/28015

1 0

Integrated: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val))
by Anton Seoane Ampudia 29 Oct '25

29 Oct '25

On Tue, 21 Oct 2025 09:19:22 GMT, Anton Seoane Ampudia <aseoane(a)openjdk.org> 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 This pull request has now been integrated. Changeset: 8457f38f Author: Anton Seoane Ampudia <aseoane(a)openjdk.org> Committer: Roberto Castañeda Lozano <rcastanedalo(a)openjdk.org> URL: https://git.openjdk.org/jdk/commit/8457f38f14182e2a55ff5d243cdacb06c9003c49 Stats: 76 lines in 3 files changed: 74 ins; 0 del; 2 mod 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) Reviewed-by: dlong, rcastanedalo, mgronlun ------------- PR: https://git.openjdk.org/jdk/pull/27913

1 0

Re: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v12]
by Anton Seoane Ampudia 29 Oct '25

29 Oct '25

> 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: Final renaming touches ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27913/files - new: https://git.openjdk.org/jdk/pull/27913/files/80f572a2..72202ad6 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=11 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=10-11 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

3 3

Re: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v11]
by Anton Seoane Ampudia 28 Oct '25

28 Oct '25

> 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: Rename class ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27913/files - new: https://git.openjdk.org/jdk/pull/27913/files/1f922569..80f572a2 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=10 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=09-10 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

2 2

Re: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v10]
by Anton Seoane Ampudia 28 Oct '25

28 Oct '25

> 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: Rename test and update comments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27913/files - new: https://git.openjdk.org/jdk/pull/27913/files/aa09c1bb..1f922569 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=09 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=08-09 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

1 0

Re: RFR: 8347463: jdk/jfr/threading/TestManyVirtualThreads.java crashes with assert(oopDesc::is_oop_or_null(val)) [v9]
by Anton Seoane Ampudia 28 Oct '25

28 Oct '25

> 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: Adjust comment ------------- Changes: - all: https://git.openjdk.org/jdk/pull/27913/files - new: https://git.openjdk.org/jdk/pull/27913/files/9ff84e73..aa09c1bb Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=08 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27913&range=07-08 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

3 4