March 2024 - hotspot-jfr-dev

RFR: 8310994: Add JFR event for selection operations
by Tim Prinzing 25 Jun '24

25 Jun '24

Added mirror event with static methods: jdk.internal.event.SelectionEvent that provides the duration of select calls and the count of how many keys are available. Emit the event from SelectorImpl::lockAndDoSelect Test at jdk.jfr.event.io.TestSelectionEvents ------------- Commit messages: - remove trailing whitespace - event logic outside of the lock, selector in try block - remove unused import - fix TestConfigure failure - add event defaults - Merge branch 'master' into JDK-8310994 - minor test cleanup - Merge branch 'master' into JDK-8310994 - 8310994: Add JFR event for selection operations Changes: https://git.openjdk.org/jdk/pull/16710/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16710&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310994 Stats: 265 lines in 9 files changed: 264 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16710.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16710/head:pull/16710 PR: https://git.openjdk.org/jdk/pull/16710

6 40

RFR: 8276125: RunThese24H.java SIGSEGV in JfrThreadGroup::thread_group_id
by Markus Grönlund 04 Jun '24

04 Jun '24

Greetings, please help review this changeset. Details are listed in the the JIRA issue. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8276125 Changes: https://git.openjdk.java.net/jdk/pull/6702/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=6702&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8276125 Stats: 6 lines in 1 file changed: 4 ins; 0 del; 2 mod Patch: https://git.openjdk.java.net/jdk/pull/6702.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/6702/head:pull/6702 PR: https://git.openjdk.java.net/jdk/pull/6702

5 6

RFR: 8326012: JFR: Event for safepoint timeout
by Denghui Dong 27 May '24

27 May '24

There are now some JFR events related to safepoint. When time-to-safepoint (aka ttsp) is too long, these events could not be very helpful since based on them we cannot know which threads cause it and what those threads are doing. Users can use `-XX:+SafepointTimeout -XX:SafepointTimeoutDelay=100` to see the threads that don't reach safepoint in time but without stack traces. Using `-XX:+ AbortVMOnSafepointTimeout` can capture the stack traces but it crashes the process, hence it's not sensible to enable the flag in production. This patch adds a new JFR event `EventSafepoint` to record the threads that causes ttsp too long. This event includes two fields: - safepointId: the relevant safepoint id - timeExceeded: the amount of time exceeding `SafepointTimeoutDelay` used by the thread to reach safepoint In the current version, this event records the stack of those problematic threads when they finally reach safepoint. Hence, there is a bias, but it's still helpful to deduce the root place. A better implementation is to record a more accurate stack, but this will increase complexity. At the same time, the native stack may also be important for this problem, but it is not currently supported by JFR. Any input would be greatly appreciated. ------------- Commit messages: - update - 8326012: JFR: Event for safepoint timeout Changes: https://git.openjdk.org/jdk/pull/17888/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17888&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8326012 Stats: 143 lines in 7 files changed: 136 ins; 0 del; 7 mod Patch: https://git.openjdk.org/jdk/pull/17888.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17888/head:pull/17888 PR: https://git.openjdk.org/jdk/pull/17888

3 24

RFR: 8294978: Convert 5 test/jdk/jdk/jfr tests from ASM library to Classfile API
by Chen Liang 03 May '24

03 May '24

Converted these tests to Classfile API and some of the constants to Constant API. InstrumentationCallback.callback wasn't changed to a record since I cannot figure out how to ship a nested record class with InstrumentationCallback in a jar. ------------- Commit messages: - Convert jdk.jfr tests to ASM Changes: https://git.openjdk.org/jdk/pull/13072/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13072&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8294978 Stats: 283 lines in 5 files changed: 75 ins; 108 del; 100 mod Patch: https://git.openjdk.org/jdk/pull/13072.diff Fetch: git fetch https://git.openjdk.org/jdk pull/13072/head:pull/13072 PR: https://git.openjdk.org/jdk/pull/13072

3 19

RFR: 8323058: Revisit j.l.classfile.CodeBuilder API surface
by Adam Sotona 02 May '24

02 May '24

`java.lang.classfile.CodeBuilder` contains more than 230 API methods. Existing ClassFile API use cases proved the concept one big CodeBuilder is comfortable. However there are some redundancies, glitches in the naming conventions, some frequently used methods are hard to find and some methods have low practical use. This patch revisits the `CodeBuilder` API methods and introduces some changes. For more details, please, visit the [CSR ](https://bugs.openjdk.org/browse/JDK-8323067) Please review. Thank you, Adam ------------- Commit messages: - Merge branch 'master' into JDK-8323058-CodeBuilder - extended CodeBuilder::conversion functionality - removed CodeBuilder::newPrimitiveArray, newReferenceArray, newMultidimensionalArray and operator methods - fixed tests - fixed jdk/classfile tests - fixed benchmarks - fixed jdk.jfr and jdk.jlink - fixed java.base - 8323058: Revisit j.l.classfile.CodeBuilder API surface Changes: https://git.openjdk.org/jdk/pull/17282/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=17282&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8323058 Stats: 876 lines in 43 files changed: 41 ins; 188 del; 647 mod Patch: https://git.openjdk.org/jdk/pull/17282.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/17282/head:pull/17282 PR: https://git.openjdk.org/jdk/pull/17282

5 13

RFR: 8329138: Convert JFR FileForceEvent to static mirror event
by Tim Prinzing 30 Apr '24

30 Apr '24

Currently the JFR event FileForceEvent is generated by instrumenting the sun.nio.ch.FileChannelImpl class. This needs to be changed to use the newer mirror events with static methods. Added the event at jdk.internal.event.FileForceEvent, and changed jdk.jfr.events.FileForceEvent to be a mirror event. Updated FileChannelImpl to use the jdk internal event static methods, and removed the force() method from FileChannelImplInstrumentor. Uses the existing tests. ------------- Commit messages: - javadoc fixup - remove mirrors from JDKEvents - 8329138: Convert JFR FileForceEvent to static mirror event Changes: https://git.openjdk.org/jdk/pull/18542/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18542&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8329138 Stats: 159 lines in 7 files changed: 123 ins; 30 del; 6 mod Patch: https://git.openjdk.org/jdk/pull/18542.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18542/head:pull/18542 PR: https://git.openjdk.org/jdk/pull/18542

4 27

RFR: JDK-8303689: javac -Xlint could/should report on "dangling" doc comments
by Jonathan Gibbons 26 Apr '24

26 Apr '24

Please review the updates to support a proposed new `-Xlint:dangling-doc-comments` option. The work can be thought of as in 3 parts: 1. An update to the `javac` internal class `DeferredLintHandler` so that it is possible to specify the appropriately configured `Lint` object when it is time to consider whether to generate the diagnostic or not. 2. Updates to the `javac` front end to record "dangling docs comments" found near the beginning of a declaration, and to report them using an instance of `DeferredLintHandler`. This allows the warnings to be enabled or disabled using the standard mechanisms for `-Xlint` and `@SuppressWarnings`. The procedure for handling dangling doc comments is described in this comment in `JavacParser`. * Dangling documentation comments are handled as follows. * 1. {@code Scanner} adds all doc comments to a queue of * recent doc comments. The queue is flushed whenever * it is known that the recent doc comments should be * ignored and should not cause any warnings. * 2. The primary documentation comment is the one obtained * from the first token of any declaration. * (using {@code token.getDocComment()}. * 3. At the end of the "signature" of the declaration * (that is, before any initialization or body for the * declaration) any other "recent" comments are saved * in a map using the primary comment as a key, * using this method, {@code saveDanglingComments}. * 4. When the tree node for the declaration is finally * available, and the primary comment, if any, * is "attached", (in {@link #attach}) any related * dangling comments are also attached to the tree node * by registering them using the {@link #deferredLintHandler}. * 5. (Later) Warnings may be genereated for the dangling * comments, subject to the {@code -Xlint} and * {@code @SuppressWarnings}. 3. Updates to the make files to disable the warnings in modules for which the warning is generated. This is often because of the confusing use of `/**` to create box or other standout comments. ------------- Commit messages: - JDK-8303689: javac -Xlint could/should report on "dangling" doc comments Changes: https://git.openjdk.org/jdk/pull/18527/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18527&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303689 Stats: 477 lines in 60 files changed: 368 ins; 5 del; 104 mod Patch: https://git.openjdk.org/jdk/pull/18527.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18527/head:pull/18527 PR: https://git.openjdk.org/jdk/pull/18527

5 19

RFR: JDK-8327474 Review use of java.io.tmpdir in jdk tests
by Bill Huang 03 Apr '24

03 Apr '24

This task addresses an essential aspect of our testing infrastructure: the proper handling and cleanup of temporary files and socket files created during test execution. The motivation behind these changes is to prevent the accumulation of unnecessary files in the default temporary directory, which can affect the system's storage and potentially influence subsequent test runs. Our review identified that several tests create temporary files or socket files without ensuring their removal post-execution. - Direct calls to java.io.File.createTempFile and java.nio.file.Files.createTempFile without adequate cleanup. - Tests using NIO socket channels with StandardProtocolFamily.UNIX, not explicitly removing socket files post-use. ------------- Commit messages: - Clean up temporary files after tests complete. Changes: https://git.openjdk.org/jdk/pull/18352/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18352&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327474 Stats: 42 lines in 11 files changed: 20 ins; 1 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/18352.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18352/head:pull/18352 PR: https://git.openjdk.org/jdk/pull/18352

7 18

jfr view: Regarding adding "Allocated" column to the allocation related 3 views
by Long Yang 24 Mar '24

24 Mar '24

hi all jfr view has three predefined views regarding allocation: allocation-by-thread, allocation-by-class, allocation-by-site. Currently, these three views only show percentages. Usually, we will first look at the absolute value of memory application (total number of allocated bytes). When the absolute value is larger enough, the items with larger proportions are more meaningful. I don’t know if I can add Allocated column to these three views, similar to the thread-allocation view. Allocation by Class Object Type Allocated Allocation Pressure --------------------------------------------- ---------------- ------------------- byte[] 11.7 GB 99.82% Best Regards

2 3

RFR: 8327990: [macosx-aarch64] JFR enters VM without WXWrite
by Richard Reingruber 21 Mar '24

21 Mar '24

This pr changes `JfrJvmtiAgent::retransform_classes()` and `jfr_set_enabled` to switch to `WXWrite` before transitioning to the vm. Testing: make test TEST=jdk/jfr/event/runtime/TestClassLoadEvent.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync make test TEST=compiler/intrinsics/klass/CastNullCheckDroppingsTest.java TEST_VM_OPTS=-XX:+AssertWXAtThreadSync More tests are pending. ------------- Commit messages: - Switch to WXWrite before entering the vm Changes: https://git.openjdk.org/jdk/pull/18238/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18238&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8327990 Stats: 5 lines in 2 files changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/18238.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18238/head:pull/18238 PR: https://git.openjdk.org/jdk/pull/18238

7 33