August 2024 - hotspot-jfr-dev

JFR ChunkInputStream uses single byte read()
by David Schlosnagle 13 Aug '24

13 Aug '24

Hi JFR dev, I would like to contribute an improvement to reading JFR recordings via `InputStream` by implementing `InputStream#read(byte[], int, int)` in `ChunkInputStream` to support bulk reads and avoid many expensive single byte `read()`. PR: https://github.com/openjdk/jdk/pull/20534 Testing: `test/jdk/jdk/jfr/api/consumer/TestChunkInputStreamBulkRead.java` While looking through some JFRs recently, I noticed some significant time spent in `java.io.BufferedInputStream#getBufIfOpen()` that traced back to transferring (via `InputStream#transferTo(OutputStream)` JFR profile recording being read via `InputStream` returned by `jdk.jfr.Recording#getStream(Instant , Instant)`. What caught my eye were calls to single byte `jdk.jfr.internal.ChunkInputStream#read()` rather than `read(byte[], int, int)` as seen in the stacktrace from JFR. Thanks!

1 0

RFR: 8338062: JFR: Remove TestStartDuration.java and TestStartName.java from ProblemList.txt
by Erik Gahlin 09 Aug '24

09 Aug '24

Could I have a review of a change that removes two tests from ProblemList.txt. The parsing of startup parameters was rewritten in Java for JDK 17 as part of [JDK-8265271](https://bugs.openjdk.org/browse/JDK-8265271) and I have run the tests several thousand times without a failure. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/20511/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20511&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8338062 Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20511.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20511/head:pull/20511 PR: https://git.openjdk.org/jdk/pull/20511

2 2

RFR: 8334780: Crash: assert(h_array_list.not_null()) failed: invariant
by Markus Grönlund 08 Aug '24

08 Aug '24

Greetings, this change adjusts an incorrect assert, as new_java_util_arraylist() has CHECK_NULL constructs on exceptions. Testing: jdk_jfr Cheers Markus ------------- Commit messages: - 8334780 Changes: https://git.openjdk.org/jdk/pull/20512/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20512&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8334780 Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20512.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20512/head:pull/20512 PR: https://git.openjdk.org/jdk/pull/20512

3 4

RFR: 8337994: [REDO] Native memory leak when not recording any events
by Markus Grönlund 08 Aug '24

08 Aug '24

Greetings, This provides the proper fix for JDK-8335121, which was backed out because it caused a problem running with —ea and — esa. The problem arises from the situation where the typeset system serializes primitive types but does not serialize their class loader (i.e. bootloader). Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8337994 Changes: https://git.openjdk.org/jdk/pull/20501/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20501&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337994 Stats: 14 lines in 2 files changed: 9 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20501.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20501/head:pull/20501 PR: https://git.openjdk.org/jdk/pull/20501

2 2

RFR: 8225209: jdk/jfr/event/compiler/TestCodeSweeper.java fails
by Erik Gahlin 08 Aug '24

08 Aug '24

Could I have a review of a PR that prevents intermittent test failures? The test has been changed to use a RecordingStream instead of a Recording. Before the change, the test failed 4 times out of 800 runs. After the change, no failures have been observed after 5000+ test runs. One might think the reason the test succeeds is because provokeEvents() is called again if no event arrives in the stream. This is not the case. I have verified this by removing the call to provokeEvents() in the ProvocationEvent handler. Another possible reason is that a flush happens every second, giving more time for the CodeCacheFull or CompilationFailure events to arrive compared to an immediate call to Recording::stop(). This is also not the case. Events in the stream are sorted by their end time, so CodeCacheFull or CompilationFailure must arrive before ProvocationEvent is committed. Otherwise, the stream would not close, and the test would timeout. I don't know why it works, but the test seems stable now. The bug was initially filed for a test timeout, but I have only seen events not arriving in the recording, so I updated the title. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/20473/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20473&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8225209 Stats: 42 lines in 2 files changed: 24 ins; 3 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/20473.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20473/head:pull/20473 PR: https://git.openjdk.org/jdk/pull/20473

2 2

RFR: 8337975: [BACKOUT] Native memory leak when not recording any events
by Markus Grönlund 07 Aug '24

07 Aug '24

Greetings, Fix for [JDK-8335121](https://bugs.openjdk.org/browse/JDK-8335121) introduced regressions when running with -ea and -esa. Change needs to be backed out during troubleshooting. Thanks Markus ------------- Commit messages: - Revert "8335121: Native memory leak when not recording any events" Changes: https://git.openjdk.org/jdk/pull/20490/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20490&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337975 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20490.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20490/head:pull/20490 PR: https://git.openjdk.org/jdk/pull/20490

3 4

RFR: 8335121: Native memory leak when not recording any events
by Markus Grönlund 07 Aug '24

07 Aug '24

Greetings, This minor adjustment prevents thread metadata memory from growing continuously when JFR does not record any events. A recording is running, meaning new threads will register their metadata. However, since no events are generated, metadata processing, including deallocation, is skipped. This is an old optimization that is no longer valid and is, therefore, removed. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8335121 Changes: https://git.openjdk.org/jdk/pull/20434/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20434&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8335121 Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20434.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20434/head:pull/20434 PR: https://git.openjdk.org/jdk/pull/20434

5 6

RFR: 8337798: JFR: Remove jdk/jfr/api/consumer/recordingstream/TestOnEvent.java from ProblemList.txt
by Erik Gahlin 06 Aug '24

06 Aug '24

Could I have a review of a change that removes a test from ProblemList.txt? We want to determine if the issue still exists, in which case more time needs to be spent fixing it. The theory is that the EventProducer used in the test may provoke a chunk rotation under stress, which could lead to the parser getting stuck due to timing issues, fixed by JDK-8304732 / JDK-8334886: Testing: I can't reproduce the failure after running the test more than 800 times on Linux (50% on aarch64 and 50% x86_64). Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/20463/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20463&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337798 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20463.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20463/head:pull/20463 PR: https://git.openjdk.org/jdk/pull/20463

2 2

RFR: 8337779: test/jdk/jdk/jfr/jvm/TestHiddenWait.java is a bit fragile
by Erik Gahlin 05 Aug '24

05 Aug '24

Could I have a review of a test fix that allows for other threads than the test or JFR threads to emit events during the test, i.e. events from the "Common-Cleaner" thread. Testing: jdk/jdk/jfr/jvm/TestHiddenWait.java Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/20459/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20459&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337779 Stats: 9 lines in 1 file changed: 9 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/20459.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20459/head:pull/20459 PR: https://git.openjdk.org/jdk/pull/20459

2 2

RFR: 8337676: JFR: Change the label of the throttle setting
by Erik Gahlin 02 Aug '24

02 Aug '24

Could I have a review of a change that makes the throttle label more consistent with the labels of other settings? - "Threshold" - "Period" - "Stack Trace" - "Enabled" - "Cutoff" - "Level" - "Event Emission Throttle" -> "Throttle" Testing: jdk/jdk/jfr ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/20426/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20426&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8337676 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/20426.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/20426/head:pull/20426 PR: https://git.openjdk.org/jdk/pull/20426

2 2