March 2025 - hotspot-jfr-dev

RFR: 8352738: JFR: Implementation of JFR Method Timing and Tracing
by Erik Gahlin 19 May '25

19 May '25

Could I have a review of this enhancement that will add tracing capabilities to JFR? There are opportunities for performance improvements in the implementation, but I would rather add them later and separately. Testing: tier 1-3, test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/24205/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24205&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352738 Stats: 6510 lines in 103 files changed: 6060 ins; 362 del; 88 mod Patch: https://git.openjdk.org/jdk/pull/24205.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24205/head:pull/24205 PR: https://git.openjdk.org/jdk/pull/24205

2 2

RFR: 8345500: Timeout in jdk.jfr.api.consumer.streaming.TestJVMCrash
by Gerard Ziemski 09 May '25

09 May '25

In this fix we add 1 second delay after we create a process. On macOS we seem to be creating a process so quickly, that other threads need time to see it. ------------- Commit messages: - allow process to be visible by other threads Changes: https://git.openjdk.org/jdk/pull/23163/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23163&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8345500 Stats: 11 lines in 1 file changed: 11 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/23163.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23163/head:pull/23163 PR: https://git.openjdk.org/jdk/pull/23163

3 3

Re: RFR: 8352251: Implement Cooperative JFR Sampling
by Aleksey Shipilev 07 Apr '25

07 Apr '25

On Fri, 28 Mar 2025 15:38:59 GMT, Markus Grönlund <mgronlun(a)openjdk.org> wrote: > Greetings, > > This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338). > > Implementations in this change set are provided and have been tested on the following platforms: > > - windows-x64 > - windows-x64-debug > - linux-x64 > - linux-x64-debug > - macosx-x64 > - macosx-x64-debug > - linux-aarch64 > - linux-aarch64-debug > - macosx-aarch64 > - macosx-aarch64-debug > > Testing: tier1-6, jdk_jfr, stress testing. > > Platform porters note: > Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes: > > - src/hotspot/cpu/x86/frame_x86.cpp > - src/hotspot/cpu/x86/interp_masm_x86.cpp > - src/hotspot/cpu/x86/interp_masm_x86.hpp > - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp > - src/hotspot/cpu/x86/macroAssembler_x86.cpp > - src/hotspot/cpu/x86/macroAssembler_x86.hpp > - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp > - src/hotspot/cpu/x86/templateTable_x86.cpp > - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp > > Thanks > Markus A drive-by comment, since I am cleaning up some of x86 code after x86_32 removals: src/hotspot/cpu/x86/interp_masm_x86.cpp line 791: > 789: > 790: // Thread argument > 791: mov(c_rarg0, r15_thread); `movptr`, I'd think? src/hotspot/cpu/x86/interp_masm_x86.cpp line 796: > 794: Label L_ljf, L_valid_rbp; > 795: testptr(rbp, rbp); > 796: jcc(Assembler::notZero, L_valid_rbp); Little trivia about x86: "normal" jumps are fairly long (6 bytes, IIRC), but you can have a "short jump" (about 3 bytes, IIRC) if the offset is small. This is normally handled by assembler itself, when it knows where the branch target is. That is known for _backward_ branches. For _forward_ branches like this, we unfortunately often need to claim the jump is short ahead of time. See `jccb` (note `b`). Basically, if you are sure the branch target is within 128 bytes (or, more likely, a few instructions) away, use `jccb`. Same thing with `jmp` -> `jmpb`. src/hotspot/cpu/x86/interp_masm_x86.cpp line 1045: > 1043: Label slow_path; > 1044: Label fast_path; > 1045: safepoint_poll(slow_path, rthread, current_fp, true /* at_return */, false /* in_nmethod */); A little heads-up: I am going to propose a little cleanup soon to drop `rthread` from x86 safepoint_pool (we can trust it is `r15_thread` always). That would probably yield a minor merge conflict here. ------------- PR Review: https://git.openjdk.org/jdk/pull/24296#pullrequestreview-2726620088 PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2019283641 PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2019283404 PR Review Comment: https://git.openjdk.org/jdk/pull/24296#discussion_r2019285766

1 1

Re: RFR: 8352251: Implement Cooperative JFR Sampling [v3]
by Markus Grönlund 07 Apr '25

07 Apr '25

> Greetings, > > This is the implementation of JEP [JDK-8350338 Cooperative JFR Sampling](https://bugs.openjdk.org/browse/JDK-8350338). > > Implementations in this change set are provided and have been tested on the following platforms: > > - windows-x64 > - windows-x64-debug > - linux-x64 > - linux-x64-debug > - macosx-x64 > - macosx-x64-debug > - linux-aarch64 > - linux-aarch64-debug > - macosx-aarch64 > - macosx-aarch64-debug > > Testing: tier1-6, jdk_jfr, stress testing. > > Platform porters note: > Some platform-specific code needs to be provided, mainly in the interpreter. Take a look at the following files for changes: > > - src/hotspot/cpu/x86/frame_x86.cpp > - src/hotspot/cpu/x86/interp_masm_x86.cpp > - src/hotspot/cpu/x86/interp_masm_x86.hpp > - src/hotspot/cpu/x86/javaFrameAnchor_x86.hpp > - src/hotspot/cpu/x86/macroAssembler_x86.cpp > - src/hotspot/cpu/x86/macroAssembler_x86.hpp > - src/hotspot/cpu/x86/templateInterpreterGenerator_x86.cpp > - src/hotspot/cpu/x86/templateTable_x86.cpp > - src/hotspot/os_cpu/linux_x86/javaThread_linux_x86.hpp > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with two additional commits since the last revision: - align params - adjustments ------------- Changes: - all: https://git.openjdk.org/jdk/pull/24296/files - new: https://git.openjdk.org/jdk/pull/24296/files/7998b7c1..1015a8c1 Webrevs: - full: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=02 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=24296&range=01-02 Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/24296.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24296/head:pull/24296 PR: https://git.openjdk.org/jdk/pull/24296

1 1

RFR: 8351925: JFR: Microsecond time format precision for JFR tool
by Aleksey Shipilev 07 Apr '25

07 Apr '25

Currently, JFR tool formats the times with millisecond precision: jdk.ThreadSleep { startTime = 10:48:56.668 (2025-03-13) duration = 100 ms time = 100 ms eventThread = "main" (javaThreadId = 3) stackTrace = [...] } In modern world, a lot can happen within a millisecond. So it would be better to default to microsecond precision. Both timesources supported by JFR (RDTSC and os::elapsed_counter()) have enough enough precision to satisfy microsecond output, so microseconds are meaningful. After the patch: jdk.ThreadSleep { startTime = 11:23:32.314580 (2025-03-13) duration = 100 ms time = 100 ms eventThread = "main" (javaThreadId = 3) stackTrace = [...] } I think durations should also be more precise -- for example to compute the endTime precisely from (startTime+duration), but that is a more controversial/style question, so I would like to handle it separately. ------------- Commit messages: - Fix Changes: https://git.openjdk.org/jdk/pull/24029/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24029&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8351925 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/24029.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24029/head:pull/24029 PR: https://git.openjdk.org/jdk/pull/24029

2 8

RFR: 8353227: JFR: Prepare tests for strong parser validation
by Markus Grönlund 01 Apr '25

01 Apr '25

Greetings, Tests: - jdk/jfr/jvm/TestDumpOnCrash.java - jdk/jfr/event/runtime/TestShutdownEvent.java Cannot run with -esa in combination with [JDK-8351698](https://bugs.openjdk.org/browse/JDK-8351698), because parser invariants are not guaranteed for emergency dumps, which are provided on a best-effort basis only. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8353227 Changes: https://git.openjdk.org/jdk/pull/24317/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24317&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353227 Stats: 38 lines in 2 files changed: 38 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24317.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24317/head:pull/24317 PR: https://git.openjdk.org/jdk/pull/24317

2 4

RFR: 8353226: JFR: emit old object samples must be transitive closure complete for segment
by Markus Grönlund 01 Apr '25

01 Apr '25

Greetings, EventEmitter::write_events() only serializes blobified stack traces as part of old object checkpoint serialization. Still, it categorically writes a stack trace id as part of the event, even for non-blobified stack traces. As a result, the segment is incomplete. Stack traces must be serialized directly from the leak profiler repository to ensure closure. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8353226 Changes: https://git.openjdk.org/jdk/pull/24316/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24316&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353226 Stats: 63 lines in 5 files changed: 59 ins; 2 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/24316.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24316/head:pull/24316 PR: https://git.openjdk.org/jdk/pull/24316

2 3

RFR: 8350386: Test TestCodeCacheFull.java fails with option -XX:-UseCodeCacheFlushing
by SendaoYan 01 Apr '25

01 Apr '25

Hi all, Test jdk/jfr/event/compiler/TestCodeCacheFull.java fails with option `-XX:-UseCodeCacheFlushing`, because this test is incompatible with `-XX:-UseCodeCacheFlushing` when `-XX:+SegmentedCodeCache` is enable, the detail analyze has been recorded by [JDK-8350386](https://bugs.openjdk.org/browse/JDK-8350386). This PR add `-XX:+UseCodeCacheFlushing` JVM option to test header make this test run passes whenever test receive `-XX:-UseCodeCacheFlushing` from outside or not. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8350386: Test TestCodeCacheFull.java fails with option -XX:-UseCodeCacheFlushing Changes: https://git.openjdk.org/jdk/pull/23721/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=23721&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8350386 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/23721.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/23721/head:pull/23721 PR: https://git.openjdk.org/jdk/pull/23721

2 8

RFR: 8353235: Test jdk/jfr/api/metadata/annotations/TestPeriod.java fails with IllegalArgumentException
by SendaoYan 31 Mar '25

31 Mar '25

Hi all, In test jdk/jfr/api/metadata/annotations/TestPeriod.java, the tested class `PeriodicEvent` extends `Event`, bug `Event` has three event types `enabled/stackTrace/threshold` by default. So we need to add `period` event type before test manually. Change has been verified locally, test-fix only, no risk. ------------- Commit messages: - 8353235: Test jdk/jfr/api/metadata/annotations/TestPeriod.java fails with IllegalArgumentException Changes: https://git.openjdk.org/jdk/pull/24320/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24320&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8353235 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/24320.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24320/head:pull/24320 PR: https://git.openjdk.org/jdk/pull/24320

2 3

RFR: 8352879: TestPeriod.java and TestGetContentType.java run wrong test class
by Zihao Lin 31 Mar '25

31 Mar '25

Fix TestPeriod.java and TestGetContentType.java run wrong test class. ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8352879 - fix tests Changes: https://git.openjdk.org/jdk/pull/24312/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=24312&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8352879 Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/24312.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/24312/head:pull/24312 PR: https://git.openjdk.org/jdk/pull/24312

5 6