November 2023 - 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: 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: 8320959: jdk/jfr/event/runtime/TestShutdownEvent.java crash with CONF=fastdebug -Xcomp
by SUN Guoyun 08 Dec '23

08 Dec '23

Run `make test CONF=fastdebug TEST=jdk/jfr/event/runtime/TestShutdownEvent.java JTREG="VM_OPTIONS=-Xcomp"`, can occur SIGSEGV. <pre> # Internal Error (/home/sunguoyun/jdk-ls/src/hotspot/share/jfr/support/jfrNativeLibraryLoadEvent.cpp:107), pid=13214, tid=13215 # assert(jt->thread_state() == _thread_in_native) failed: invariant # # JRE version: OpenJDK Runtime Environment (22.0) (fastdebug build 22-internal-adhoc.sunguoyun.jdk-ls) # Java VM: OpenJDK 64-Bit Server VM (fastdebug 22-internal-adhoc.sunguoyun.jdk-ls, compiled mode, sharing, compressed oops, compressed class ptrs, g1 gc, linux-amd64) # Problematic frame: # V [libjvm.so+0xe9404a] NativeLibraryLoadEvent::~NativeLibraryLoadEvent()+0xd1a # # CreateCoredumpOnCrash turned off, no core file dumped # </pre> Because current thread state is '_thread_in_Java'. I had make a fix, please review it , thanks. Testing: GHA testing tier1-3 for loongarch64 ------------- Commit messages: - 8320959: jdk/jfr/event/runtime/TestShutdownEvent.java crash with CONF=fastdebug -Xcomp Changes: https://git.openjdk.org/jdk/pull/16894/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16894&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8320959 Stats: 5 lines in 1 file changed: 4 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/16894.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16894/head:pull/16894 PR: https://git.openjdk.org/jdk/pull/16894

2 4

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: 8314905: jdk/jfr/tool/TestView.java fails with RuntimeException 'Invoked Concurrent' missing from stdout/stderr
by Erik Gahlin 02 Dec '23

02 Dec '23

Could I have a review of a test fix? The test now uses a more predictable event than the SystemGC event. Testing: jdk/jfr/tool/TestView.java Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/15513/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15513&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314905 Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod Patch: https://git.openjdk.org/jdk/pull/15513.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/15513/head:pull/15513 PR: https://git.openjdk.org/jdk/pull/15513

2 2

RFR: 8314745: JFR: @StackFilter
by Erik Gahlin 22 Nov '23

22 Nov '23

Could I have a review of change that allows stack frames to be filtered out. For now, that mechanism is only available for JDK events, but plan is to make the annotation public once we feel confident the API is correct. Testing: tier1 + tier2 + jdk/jdk/jfr/ Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk/pull/16726/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=16726&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8314745 Stats: 916 lines in 28 files changed: 892 ins; 1 del; 23 mod Patch: https://git.openjdk.org/jdk/pull/16726.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/16726/head:pull/16726 PR: https://git.openjdk.org/jdk/pull/16726

4 7

RFD: Throttling Support for Java-Level JFR Events
by Denghui Dong 20 Nov '23

20 Nov '23

Hi team, We have observed increased adoption of JFR for information collection within our internal applications and frameworks. However, we've encountered situations where critical events occur frequently, prompting us to explore the possibility of introducing a throttling mechanism for Java-level events. Currently, my understanding is that throttling is exclusively supported for native event ObjectAllocationSample. Should we consider extending this feature to Java-level events? Thanks, Denghui Dong

2 3