October 2023 - hotspot-jfr-dev

RFR: 8310978: JFR events SocketReadEvent/SocketWriteEvent for Socket adaptor ops
by Tim Prinzing 30 Oct '23

30 Oct '23

Added jar event support to socket adapters. Added the test jdk/jfr/event/io/TestSocketAdapterEvents.java ------------- Commit messages: - add missing return - socket adapter changes to build with merged master - Merge branch 'master' into JDK-8310978 - fix copyright date - 8310978: JFR events SocektReadEvent and SocketWriteEvent for Socket adaptor ops Changes: https://git.openjdk.org/jdk/pull/16251/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16251&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310978 Stats: 168 lines in 2 files changed: 158 ins; 8 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16251.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16251/head:pull/16251 PR: https://git.openjdk.org/jdk/pull/16251

4 16

RFR: 8316437: JFR: assert(!tl->has_java_buffer()) failed: invariant
by Markus Grönlund 26 Oct '23

26 Oct '23

Greetings, Please help review this tiny adjustment that removes an overly restrictive assert—reasoning in the JIRA issue. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8316437 Changes: https://git.openjdk.org/jdk/pull/16364/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16364&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316437 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16364.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16364/head:pull/16364 PR: https://git.openjdk.org/jdk/pull/16364

2 2

Integrated: 8317360: Missing null checks in JfrCheckpointManager and JfrStringPool initialization routines
by Markus Grönlund 25 Oct '23

25 Oct '23

Greetings, Adding missing null checks for initialization routines. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8317360 Changes: https://git.openjdk.org/jdk/pull/16310/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16310&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317360 Stats: 6 lines in 2 files changed: 6 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16310.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16310/head:pull/16310 PR: https://git.openjdk.org/jdk/pull/16310

3 4

RFR: 8318701: Fix copyright year
by Leo Korinth 24 Oct '23

24 Oct '23

Fix copyright year to 2023 ------------- Commit messages: - 8318701: Fix copyright year Changes: https://git.openjdk.org/jdk/pull/16338/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16338&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318701 Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/16338.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16338/head:pull/16338 PR: https://git.openjdk.org/jdk/pull/16338

2 4

RFR: 8318124: JFR: Rewrite instrumentation to use Class-File API
by Erik Gahlin 23 Oct '23

23 Oct '23

Hi, Could I have a review of an enhancement that replaces the use of ASM with the new Class-File API. This change only deals with bytecode that writes event data into buffers. Bytecode transformations carried out by classes in jdk.jfr.internal.intrument package are kept as is. Plan is to try to replace those with events in java.base. To simplify the review process, I have tried to keep the code in the classes EventInstrumentation and EventClassBuilder similar to what existed before. Further refactorizations may happen at a later stage. Testing: tier1-3 + jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/16195/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16195&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318124 Stats: 1174 lines in 12 files changed: 427 ins; 394 del; 353 mod Patch: https://git.openjdk.org/jdk/pull/16195.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16195/head:pull/16195 PR: https://git.openjdk.org/jdk/pull/16195

4 13

RFR: 8318109: Writing JFR records while a CHT has taken its lock asserts in rank checking
by Thomas Schatzl 23 Oct '23

23 Oct '23

Hi all, please review this change to fix a lock rank issue after [JDK-8317440](https://bugs.openjdk.org/browse/JDK-8317440). The `JfrStacktrace_lock` rank needs to be adjusted because it may be used when gathering CHT statistics in generational ZGC (afaiu this operation may trigger a relocation which may trigger page allocation which may trigger a JFR event which may trigger JFR trace writing). The `JfrStacktrace_lock` code seems to be a lock only guarding I/O too, so moving it to the lowest rank seems safe after code inspection, but also tier1-7 testing and around 100 runs of the failed application did not make it fail (reproduction is like 2/100 runs without this change). Testing: tier1-7, ~100 runs of the failing application with no error Hth, Thomas ------------- Commit messages: - change jfrstacktrace_lock rank Changes: https://git.openjdk.org/jdk/pull/16242/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16242&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318109 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16242.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16242/head:pull/16242 PR: https://git.openjdk.org/jdk/pull/16242

3 4

RFR: 8318126: Refresh manpages
by David Holmes 17 Oct '23

17 Oct '23

The open nroff manpage files are out of sync with their closed markdown sources and need to be refreshed. The changes to apply are coming from: - [JDK-8288158](https://bugs.openjdk.org/browse/JDK-8288158): Add an anchor to each subcommand option on jfr html page - [JDK-8273131](https://bugs.openjdk.org/browse/JDK-8273131): Update the java manpage markdown source for JFR filename expansion - [JDK-8221633](https://bugs.openjdk.org/browse/JDK-8221633): StartFlightRecording: consider moving mention of multiple comma-separated parameters to the front - [JDK-8308662](https://bugs.openjdk.org/browse/JDK-8308662): Update the "java" tool specification for CompileOnly - [JDK-8317565](https://bugs.openjdk.org/browse/JDK-8317565): Update Manpage for obsoletion of UseSHM - [JDK-8310460](https://bugs.openjdk.org/browse/JDK-8310460): Remove jdeps -profile option There are also some simple line break changes, likely due to using different versions of the pandoc tool. Thanks ------------- Commit messages: - 8318126: Refresh manpages Changes: https://git.openjdk.org/jdk/pull/16196/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16196&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8318126 Stats: 115 lines in 4 files changed: 27 ins; 64 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/16196.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16196/head:pull/16196 PR: https://git.openjdk.org/jdk/pull/16196

4 6

Re: JFR integration
by Alan Bateman 17 Oct '23

17 Oct '23

On 22/03/2023 17:23, Jonathan Ross wrote: > Hi Alan, and thanks for the response. > > I would agree that naming virtual threads, particularly when using a > VirtualThreadPerTaskExecutor, would not be that useful. No, what I'm > actually asking is whether we could still fill in useful carrier > thread information in the JFR events, and whether we could name the > carrier threads. (I'm using the right term, I hope? The platform > threads on which the virtual threads are run?) > > Let me try to clarify the nameless thread bit. If I look at a flight > recording running a large number of jobs using a > VirtualThreadPerTaskExecutor, then the custom events I record that get > fired on virtual threads don't have any thread information. If I look > at the JMC threadview, I see all my custom events on a single row > without a thread name. If I browse the event list, I also don't see > any thread information. > > I just tried looking at the raw data I captured using the jfr tool > shipped with openjdk 20, but it fails: > > jfr print: unexpected internal error, Pool jdk.types.StackTrace must > contain at least one element > java.lang.InternalError: Pool jdk.types.StackTrace must contain at > least one element > at > jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.fillConstantPools(ChunkParser.java:347) > at > jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.<init>(ChunkParser.java:149) > at > jdk.jfr/jdk.jfr.internal.consumer.ChunkParser.nextChunkParser(ChunkParser.java:158) > at jdk.jfr/jdk.jfr.consumer.RecordingFile.findNext(RecordingFile.java:252) > at > jdk.jfr/jdk.jfr.consumer.RecordingFile.readEvent(RecordingFile.java:111) > at > jdk.jfr/jdk.jfr.internal.tool.EventPrintWriter.print(EventPrintWriter.java:75) > at jdk.jfr/jdk.jfr.internal.tool.Print.execute(Print.java:163) > at jdk.jfr/jdk.jfr.internal.tool.Main.main(Main.java:87) > > It looks like JMC isn't the only tool that gets confused by virtual > threads in flight recordings. > I'm not aware of any issues or if the parsing exception in your mail is related to virtual threads or not, maybe hotspot-jfr-dev may recognize this. As a quick test, I tried some custom events committed from virtual threads and the jfr tool parses the recording, e.g. jfr print --events *Foo* ... Foo { startTime = 17:50:05.595 (2023-03-22) duration = 0.00147 ms message = "A message from a virtual thread" eventThread = "" (javaThreadId = 35, virtual) stackTrace = [ Test.lambda$main$0() line: 21 java.util.concurrent.FutureTask.run() line: 317 java.lang.VirtualThread.run(Runnable) line: 314 ] } Note the eventThread line has the thread name (empty in this case), the thread ID, and it also indicates that it is a virtual thread. -Alan

3 4

RFR: 8316927: JFR: Move shouldCommit check earlier for socket events
by Erik Gahlin 17 Oct '23

17 Oct '23

Hi, The events for socket read and socket write retrieves the remote address even in cases where the event didn't exceed the threshold. By moving the shouldCommit check earlier, it can be avoided. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Socket write event - Initial Changes: https://git.openjdk.org/jdk/pull/15908/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15908&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316927 Stats: 47 lines in 4 files changed: 20 ins; 6 del; 21 mod Patch: https://git.openjdk.org/jdk/pull/15908.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15908/head:pull/15908 PR: https://git.openjdk.org/jdk/pull/15908

5 8

Withdrawn: 8313722: JFR: Avoid unnecessary calls to Events.from(Recording)
by duke 03 Oct '23

03 Oct '23

On Fri, 4 Aug 2023 02:33:48 GMT, Erik Gahlin <egahlin(a)openjdk.org> wrote: > Could I have a review of PR that removes unnecessary calls to Events.from(Recording). > > With each call a new dump file is created. A better approach is store the events in a List that can be reused, > > Testing: jdk/jdk/jfr > > Thanks > Erik This pull request has been closed without being integrated. ------------- PR: https://git.openjdk.org/jdk/pull/15147

1 0