April 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: 8331153: JFR: Improve logging of jdk/jfr/api/consumer/filestream/TestOrdered.java
by Erik Gahlin 26 Apr '24

26 Apr '24

Could I have a review of a PR that improves logging of a test to be able to debug failures more easily. Fixes: Timestamps for all events are written with nanosecond precision Tests no longer abort before all events have been processed. Fixed typo of the word ordered Testing: jdk/jfr/api/consumer/filestream/TestOrdered.java Thanks ------------- Commit messages: - Print all timestamps - Initial Changes: https://git.openjdk.org/jdk/pull/18961/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18961&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8331153 Stats: 21 lines in 1 file changed: 15 ins; 1 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/18961.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18961/head:pull/18961 PR: https://git.openjdk.org/jdk/pull/18961

2 2

RFR: 8330734: JFR: Re-engineer mirror class mechanism
by Erik Gahlin 26 Apr '24

26 Apr '24

Could I have a review of a PR that changes how the mirror mechanism works. See issue for details. It reduces startup with 10-15 ms. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Unfix copyright - Initial Changes: https://git.openjdk.org/jdk/pull/18959/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=18959&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8330734 Stats: 200 lines in 26 files changed: 41 ins; 73 del; 86 mod Patch: https://git.openjdk.org/jdk/pull/18959.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/18959/head:pull/18959 PR: https://git.openjdk.org/jdk/pull/18959

2 2

Integrated: 8329995: Restricted access to `/proc` can cause JFR initialization to crash
by Jaroslav Bachorik 23 Apr '24

23 Apr '24

On Sun, 14 Apr 2024 08:53:05 GMT, Jaroslav Bachorik <jbachorik(a)openjdk.org> wrote: > Please, review this trivial change to make using `ProcessIterator` more robust in the presence of SELinux or a similar system. > > The call to `os::opendir("/proc")` may return `nulltptr` if the `/proc` is not accessible due to restrictions placed by the SELinux. In that case the `ProcessIterator` will SIGSEG because it assumes the `_dir`, which is the variable storing the result of the `os::opendir("/proc")` call to be non-null. > > The patch is missing regression test because it is very hard to simulate `/proc` not being accessible to the test process. This pull request has now been integrated. Changeset: a92ad039 Author: Jaroslav Bachorik <jbachorik(a)openjdk.org> URL: https://git.openjdk.org/jdk/commit/a92ad03946d296510c8c2ac18278608e8032b3f3 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod 8329995: Restricted access to `/proc` can cause JFR initialization to crash Reviewed-by: dholmes, egahlin ------------- PR: https://git.openjdk.org/jdk/pull/18775

1 0