October 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

RFR: 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump
by Taizo Kurashige 27 Feb '24

27 Feb '24

Hi, I fixed the typos for JFR.start and JFR.dump. Acconding to issue's description, there is some typo in JFR.stop documentation, but I couldn't find that. I confirmed that there is no such typo in this repository. So I thought there was no need to fix JFR.stop documentation. I confirmed that the fixes are reflected and that all of the jdk_jfr tests pass. Could someone please review it? ------------- Commit messages: - 8313710: jcmd: typo in the documentation of JFR.start and JFR.dump Changes: https://git.openjdk.org/jdk/pull/16413/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16413&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8313710 Stats: 114 lines in 3 files changed: 0 ins; 0 del; 114 mod Patch: https://git.openjdk.org/jdk/pull/16413.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16413/head:pull/16413 PR: https://git.openjdk.org/jdk/pull/16413

3 21

Priority redistribution in Old Object Sample event
by Galder Zamarreno 24 Jan '24

24 Jan '24

Hi, I've been porting over JFR Old Object Sample event to GraalVM and I had the following doubt about the code in HotSpot: I'm trying to understand the code in [1]: ``` // push span onto previous if (previous != NULL) { _priority_queue->remove(previous); previous->add_span(sample->span()); _priority_queue->push(previous); } ``` This code is related to old object sampling. When the queue is full, samples that have been GC'd are removed from the queue. To do so it takes its previous (from the list view) and adds the span of the removed dead object onto it. Basically, I'm wondering why this is done this way. My initial gut feeling when I first saw the code is that it does it so that the priority queue does not get too imbalanced (it uses a heap underneath) when removing objects, but that only makes sense to me if the previous is not the previous object sampled based on time, but the previous object sampled based on the order of the priority queue, so that's not what seems to happen. I'm wondering now if the fact that the list view is ordered by insertion time is relevant here. Is it maybe trying to give more importance (by increasing its span) to surviving objects that are near in time to those that have been garbage collected? Something that's probably related to this is how the span is initially calculated. This is done in [2], which you can find below: ``` _total_allocated += allocated; const size_t span = _total_allocated - _priority_queue->total(); ``` Again when I first looked at it, I thought: well that's just equivalent to: ``` const size_t span = allocated; ``` But clearly things are more nuanced than that. The only documentation I've found so far is in Marcus' blog post [3]: > If sampled objects are garbage collected, they are removed and the priority redistributed to the neighbours. The priority is called span, and is currently the size of the allocation, giving more weight to larger (therefore more severe) leaks. Unfortunately what is a neighbour is not explained, nor why the priority gets redistributed. Thanks Galder [1] https://github.com/openjdk/jdk17u-dev/blob/master/src/hotspot/share/jfr/lea… [2] https://github.com/openjdk/jdk17u-dev/blob/ef86ea2842b1a204834291d9d6665bfc… [3] https://hirt.se/blog/?p=1055

4 7

RFR: 8309871: jdk/jfr/api/consumer/recordingstream/TestSetEndTime.java timed out
by Erik Gahlin 03 Dec '23

03 Dec '23

Could I have review of a fix that adds -XX:-UseFastUnorderedTimeStamps to a test. An argument can be made that we should test features same way as they are used in the product, and I generally agree, but it's hard to fix this issue without a performance impact. Also, I'm not 100% certain that different clock sources are the underlying problem. By running with -XX:-UseFastUnorderedTimeStamps we will gain additional information on this intermittent test failure. Putting the test on the problem list might hide other issue. Testing: jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/14975/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14975&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8309871 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/14975.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/14975/head:pull/14975 PR: https://git.openjdk.org/jdk/pull/14975

3 3

RFR: 8317562: [JFR] Compilation queue statistics
by Mat Carter 13 Nov '23

13 Nov '23

Adding a new periodic jfr event to monitor and output statistics for the compiler queues. You will see one event per compiler queue (c1 and c2) Passes tier1 on linux (x86) and mac (aarch64) ------------- Commit messages: - jfr profiles - added requirement that java test is not run with interperter only - Addressed feedback: fix coding style and replaces int with uint - Replaced magic numbers - Update src/hotspot/share/jfr/metadata/metadata.xml - Update src/hotspot/share/jfr/periodic/jfrCompilerQueueUtilization.cpp - Update src/hotspot/share/jfr/periodic/jfrCompilerQueueUtilization.cpp - Update src/hotspot/share/jfr/periodic/jfrCompilerQueueUtilization.cpp - Add periodic jfr CompilerQueueUtilization event Changes: https://git.openjdk.org/jdk/pull/16211/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16211&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317562 Stats: 248 lines in 10 files changed: 248 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16211.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16211/head:pull/16211 PR: https://git.openjdk.org/jdk/pull/16211

8 27

RFR: 8315364: Assert thread state invariant for JFR stack trace capture
by Markus Grönlund 02 Nov '23

02 Nov '23

Greetings, A JavaThread running in state _thread_in_native cannot capture a JFR stack trace because tagging of artefacts (klasses, methods, etc.) is a function of an epoch, which evolves during safepoints. Asserting this invariant would have helped prevent the issue detailed in [JDK-8315220](https://bugs.openjdk.org/browse/JDK-8315220). Testing: jdk_jfr Thanks Markus ------------- Commit messages: - 8315364 Changes: https://git.openjdk.org/jdk/pull/15491/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15491&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8315364 Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/15491.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15491/head:pull/15491 PR: https://git.openjdk.org/jdk/pull/15491

2 4

RFR: 8239508 JFR: @RemoveFields
by Erik Gahlin 31 Oct '23

31 Oct '23

This enhancement introduces an annotation that controls the presence of implicit fields for an event. For native events, the metadata.xml file controls the existence of the fields "eventThread" "duration” and "stackTrace”. For Java events, there is nothing similar. This outage has been known since the inception of the jdk.jfr API. At that time, we decided to ignore it and write 0 for “eventThread”, “stackTrace”, and ”duration”. The gain was a simplified programming model with one annotation, i.e. StackTrace, instead of two, i.e. StackTrace and HasStackTrace, to determine if a value should be recorded. With the removal of event handlers ([JDK-8282420](https://bugs.openjdk.org/browse/JDK-8282420) ) and use of the new Class-File API ([JDK-8318124](https://bugs.openjdk.org/browse/JDK-8318124) this capability can be added to Java events at a lower implementation cost. Also, we are considering adding other fields, such as allocation, cpuTime, or socketRead/Write, that can occur between a call to Event::begin() and Event::end(). There is still uncertainty about the design of the annotation, so it is currently only accessible to JDK events. Instead of a separate annotation per field, i.e. HasStackTrace, HasEventThread, and HasDuration, there is one annotation, RemoveFields, that provides a list of fields that should be dropped. This allows for a corresponding annotation, AddFields, to be included in the future, for example, to add the field cpuTime. The benefits of the change are: - a more compact recording file - less overhead - no mismatch between contents of .jfc files and what the API provides - consistency with native events - less noise when events are visualized Testing: test/jdk/jdk/jfr/ tier1 + tier2 ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/16411/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16411&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8239508 Stats: 611 lines in 43 files changed: 392 ins; 120 del; 99 mod Patch: https://git.openjdk.org/jdk/pull/16411.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16411/head:pull/16411 PR: https://git.openjdk.org/jdk/pull/16411

2 2

RFR: 8317951: Refactor loading of zip library to help resolve JDK-8315220
by Markus Grönlund 31 Oct '23

31 Oct '23

Greetings, This refactorization resolves the problem associated with JDK-8315220 and, subsequently, JDK-8315892. Testing: jdk_jfr, tier1-9, stress testing Thanks Markus ------------- Commit messages: - newlines - remove Zip_lock - 83179512 Changes: https://git.openjdk.org/jdk/pull/16149/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16149&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8317951 Stats: 384 lines in 10 files changed: 247 ins; 126 del; 11 mod Patch: https://git.openjdk.org/jdk/pull/16149.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16149/head:pull/16149 PR: https://git.openjdk.org/jdk/pull/16149

3 35

RFR: 8316271: JfrJvmtiAgent::retransformClasses failed: JVMTI_ERROR_FAILS_VERIFICATION
by Markus Grönlund 30 Oct '23

30 Oct '23

Greetings, sometimes when running JFR with -Xverify:all, the bytecode retransform would fail with an JVMTI_ERROR_FAILS_VERIFICATION. I say sometimes because it depends on if event classes that are located in java.base are loaded before JFR is started. If so, for those event classes, the type of the static field eventConfiguration is untyped, i.e. java.lang.Object, because of the java.base module cannot use types in module jdk.jfr. As part of the instrumentation of commit(), when issuing invokevirtual instructions for this receiver, a proper downcast must be performed using checkcast. Testing: jdk_jfr Thanks Markus ------------- Commit messages: - whitespace - 8316271 Changes: https://git.openjdk.org/jdk/pull/16379/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16379&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8316271 Stats: 63 lines in 2 files changed: 62 ins; 1 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/16379.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16379/head:pull/16379 PR: https://git.openjdk.org/jdk/pull/16379

2 2