April 2023 - hotspot-jfr-dev

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: 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

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: JDK-8300245: Replace NULL with nullptr in share/jfr/
by Johan Sjölen 10 May '23

10 May '23

Do the conversion in the share/jfr/ sub-directory and all of its files. ------------- Commit messages: - More manual fixes - Merge remote-tracking branch 'origin/master' into JDK-8300245 - Manual fixes - Replace NULL with nullptr in share/jfr/ Changes: https://git.openjdk.org/jdk/pull/12034/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12034&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8300245 Stats: 2079 lines in 126 files changed: 0 ins; 0 del; 2079 mod Patch: https://git.openjdk.org/jdk/pull/12034.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12034/head:pull/12034 PR: https://git.openjdk.org/jdk/pull/12034

3 20

RFR: 8257967: JFR: Event for loaded agents
by Markus Grönlund 17 Apr '23

17 Apr '23

Greetings, We are adding support to let JFR report on Agents. #### Design An Agent is a library that uses any instrumentation or profiling APIs. Most agents are started and initialized on the command line, but agents can also be loaded dynamically during runtime. Because command line agents initialize during the VM startup sequence, they add to the overall startup time latency in getting the VM ready. The events will report on the time the agent took to initialize. A JavaAgent is an agent written in the Java programming language, using the APIs in the package [[ava.lang.instrument](https://docs.oracle.com/en/java/javase/19/docs/api/jav… A JavaAgent is sometimes called a JPLIS agent, where the acronym JPLIS stands for Java Programming Language Instrumentation Services. To report on JavaAgents, JFR will add the new event type jdk.JavaAgent and events will look similar to these two examples: // Command line jdk.JavaAgent { startTime = 12:31:19.789 (2023-03-08) name = "JavaAgent.jar" options = "foo=bar" initialization = 12:31:15.574 (2023-03-08) initializationTime = 172 ms initializationMethod = "premain" } // Dynamic load jdk.JavaAgent { startTime = 12:31:31.158 (2023-03-08) name = "JavaAgent.jar" options = "bar=baz" initialization = 12:31:31.037 (2023-03-08) initializationTime = 64,1 ms initializationMethod = "agentmain" } The jdk.JavaAgent event type is a JFR periodic event that iterates over running Java agents. For a JavaAgent event, the agent's name will be the specific .jar file containing the instrumentation code. The options will be the specific options passed to the .jar file as part of launching the agent, for example, on the command line: -javaagent: JavaAgent.jar=foo=bar The event will also detail which initialization method was invoked by the JVM, "premain" for command line agents, and "agentmain" for agents loaded dynamically. "initialization" is the timestamp the JVM invoked the initialization method, and "initializationTime" is the duration of executing the initialization method. "startTime" represents the time the JFR framework issued the periodic event; hence "initialization" will be earlier than "startTime". An agent can also be written in a native programming language, using either the JVM Tools Interface (JVMTI) or JVM Profiling Interface (JVMPI). This kind of agent, sometimes called a native agent, is a platform-specific binary, sometimes referred to as a library, but here it means a .so or .dll file. JVMTI standard spec:ification is [here](https://docs.oracle.com/en/java/javase/19/docs/specs/jvmti.html) JVMPI is an older interface, not a standard and is considered superseded by JVMTI, but the support is still in the JVM for agents started on the command line: -XRunMyAgent.jar To report on native agents, JFR will add the new event type jdk.NativeAgent and events will look similar to this example: jdk.NativeAgent { startTime = 12:31:40.398 (2023-03-08) name = "jdwp" options = "transport=dt_socket,server=y,address=any,onjcmd=y" path = "c:\ade\github\openjdk\jdk\build\windows-x86_64-server-slowdebug\jdk\bin\jdwp.dll" dynamic = false initialization = 12:31:36.142 (2023-03-08) initializationTime = 0,00184 ms } The layout of the event type is very similar to the jdk.JavaAgent event, but here the path to the native library is reported, and there is also a denotation if the agent was loaded via the command line (dynamic = false) or dynamically (dynamic = true). The initialization of a native agent is performed by invoking an agent-specified callback routine which is not detailed in the event (for now). The "initialization" is the time the JVM sent or would have sent the JVMTI VMInit event to a specified callback. "initializationTime" is the duration to execute that specific callback. If no callback is specified for the JVMTI VMInit event, the "initializationTime" will be 0. #### Implementation There has not existed a reification of a JavaAgent directly in the JVM, as these are built on top of the JDK native library, "instrument", using a many-to-one mapping. At the level of the JVM, the only representation of agents after startup is through JvmtiEnv's, which agents request from the JVM during startup and initialization — as such, mapping which JvmtiEnv belongs to what JavaAgent was not possible before. Using implementation details of how the JDK native library "instrument" interacts with the JVM, we can build this mapping and use it to track what JvmtiEnv's "belong" to what JavaAgent. This mapping now lets us report the Java-relevant context (name, options) and measure the time it takes for the JavaAgent to initialize. In order to implement this capability, it was necessary to refactor the code used to represent agents, called AgentLibrary. The previous implementation was located primarily in arguments.cpp, and threads.cpp but also jvmtiExport.cpp. The refactoring isolates the relevant logic into two new modules, prims/agent.hpp and prims/agentList.hpp. Breaking out this code from their older places will help reduce the sizes of oversized arguments.cpp and threads.cpp. The previous lists used to maintain the agents (JVMTI) and libraries (JVMPI) is not thread-safe for concurrent iterations. A single list that allows for concurrent iterations is therefore introduced. Testing: jdk_jfr, tier 1 - 6 Thanks Markus ------------- Commit messages: - event_names - adjustment - 8257967 Changes: https://git.openjdk.org/jdk/pull/12923/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=12923&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8257967 Stats: 1862 lines in 22 files changed: 1353 ins; 485 del; 24 mod Patch: https://git.openjdk.org/jdk/pull/12923.diff Fetch: git fetch https://git.openjdk.org/jdk pull/12923/head:pull/12923 PR: https://git.openjdk.org/jdk/pull/12923

5 83

RFR: 8305944: assert(is_aligned(ref, HeapWordSize)) failed: invariant
by SUN Guoyun 14 Apr '23

14 Apr '23

For narrowOop, the alignment should be sizeof(narrowOop) instead of HeapWordSize. ------------- Commit messages: - 8305944: assert(is_aligned(ref, HeapWordSize)) failed: invariant Changes: https://git.openjdk.org/jdk/pull/13471/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13471&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305944 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/13471.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13471/head:pull/13471 PR: https://git.openjdk.org/jdk/pull/13471

3 3

Proposal: Expand Filesystem JFR Events
by Marius Volkhart 05 Apr '23

05 Apr '23

Hi devs, OpenJDK already has built-in JFR events for file reads and write. However, there are a variety of additional file system interactions that are not instrumented, despite their potential impact on application performance. I would like to contribute changes that expand the built-in instrumentation to cover these interactions. I am in search of a sponsor and folks interested who might have opinions or use cases they can share. Examples of these interactions include checking if the file exists, creating a directory, creating a symlink, and reading file attributes. One of the design questions for something like this is, which Event to use? For example, reading and writing file attributes could be reported as a jdk.FileRead and jdk.FileWrite. However, this might muddy the waters, especially as we get to interactions like creating a directory or symlink. Here, the byte count is unknown. Alternatively, a new event could be created. This event might report only that a file interaction occurred, but not go into further details about data count. This is likely still enough information for developers to act upon. A concrete example comes from my day job. The desktop application in question works with user files, and customers of this app are very IO-sensitive, due to frequently using network shares and virtualized desktops. A recent dependency update caused a jump in IOPS. This was caught pre-release by Windows OS tooling, but JFR didn’t show any immediate problems. However, digging into the changes revealed that the new dependency versions was calling Files.exists(Path), Files.isRegularFile(Path), and getting file attributes far more often than the previous version. I’ve done a bit of prototyping and research on the JFR code. At a high level, I think these changes include - Instrumenting various subclasses of sun.nio.fs.AbstractFileSystemProvider - Instrumenting various subclasses of java.io.FileSystem - Modifying JFR instrumentation code to handle the differences between these types and previously instrumented types. Differences include platform-specific implementation classes, and leaf-classes that don’t define all the methods being instrumented. I have OpenJDK building and have used jtreg before, but this would be only my second contribution, so I am very much still a beginner on OpenJDK tooling and process. Still if folks show interest and a sponsor presents themselves, I’m happy to break down this admittedly large-scoped proposal into smaller chunks with more details and concrete questions/decisions. Cheers, Marius Volkhart

2 3

RFR: 8305242: Remove non-invariant assert(EventThreadDump::is_enabled())
by Markus Grönlund 04 Apr '23

04 Apr '23

Greetings, removing a non-invariant assert for EventThreadDump::is_enabled()). Thanks Markus ------------- Commit messages: - 8305242 Changes: https://git.openjdk.org/jdk/pull/13243/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13243&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8305242 Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/13243.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13243/head:pull/13243 PR: https://git.openjdk.org/jdk/pull/13243

2 2

RFR: 8303229: JFR: Preserve disk repository after exit
by Erik Gahlin 03 Apr '23

03 Apr '23

Hi, Could I have a review of an enhancement that adds the option preserve-repository=true/false to -XX:FlightRecorderOptions and jcmd JFR.configure. When set to true, chunk files in the repository will not be removed by the JVM at exit. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Fix whitespace - Initial - Initial Changes: https://git.openjdk.org/jdk/pull/13111/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=13111&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8303229 Stats: 198 lines in 8 files changed: 157 ins; 1 del; 40 mod Patch: https://git.openjdk.org/jdk/pull/13111.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/13111/head:pull/13111 PR: https://git.openjdk.org/jdk/pull/13111

4 18