June 2022 - 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

Re: RFR: 8280844: Epoch shift synchronization point for Compiler threads is inadequate [v2]
by Markus Grönlund 28 Feb '23

28 Feb '23

> Greetings, > > [JDK-8233111](https://bugs.openjdk.java.net/browse/JDK-8233111) attempted to address artefact tagging for Compiler threads, letting threads run _thread_in_native to avoid the transition. Unfortunately, that attempt proved inadequate. > > The epoch race is avoided only by performing the transition to _thread_in_vm. > > Testing: jdk_jfr > > Thanks > Markus Markus Grönlund has updated the pull request incrementally with one additional commit since the last revision: delegate assertion ------------- Changes: - all: https://git.openjdk.java.net/jdk/pull/8724/files - new: https://git.openjdk.java.net/jdk/pull/8724/files/9ce10130..b4e59b72 Webrevs: - full: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=01 - incr: https://webrevs.openjdk.java.net/?repo=jdk&pr=8724&range=00-01 Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8724.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8724/head:pull/8724 PR: https://git.openjdk.java.net/jdk/pull/8724

3 2

RFR: 8288783: JFR: Error messages are confusing when options conflict in -XX:StartFlightRecording
by Chihiro Ito 09 Feb '23

09 Feb '23

Could I have a review of PR that fixes incorrect error messages regarding of recording. The current message is very confusing. If a user types jcmd <pid> JFR.start name=abc name=def or java --XX:StartFlightRecording=name=abc,name=def, the error message says "Duplicates in diagnostic command arguments", but doesn't know what options are duplicated. Furthermore, if a user specifies two or three duplicate parameters, the same logs will be output. It should say follows, Option name can only be specified once with starting flight recording Options name and disk can only be specified once with starting flight recording Options name, disk and maxage can only be specified once with starting flight recording This problem affects --XX:StartFlightRecording, jcmd JFR.start, JFR.stop, JFR.dump, JFR.check, and MBean. For other than start, the output is as follows, (example of dump) Option name can only be specified once with dumping flight recording Testing: jdk/jdk/jfr Thanks Chihiro ------------- Commit messages: - modify whitespace from windows to linux - modify copyright - Modify log message and test case - JDK-8288783 Initial Changes: https://git.openjdk.org/jdk/pull/9302/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9302&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288783 Stats: 442 lines in 10 files changed: 431 ins; 2 del; 9 mod Patch: https://git.openjdk.org/jdk/pull/9302.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9302/head:pull/9302 PR: https://git.openjdk.org/jdk/pull/9302

5 16

RFR: 8244681: Add a warning for possibly lossy conversion in compound assignments
by Adam Sotona 15 Sep '22

15 Sep '22

Please review this patch adding new lint option, **lossy-conversions**, to javac to warn about type casts in compound assignments with possible lossy conversions. The new lint warning is shown if the type of the right-hand operand of a compound assignment is not assignment compatible with the type of the variable. The implementation of the warning is based on similar check performed to emit "possible lossy conversion" compilation error for simple assignments. Proposed patch also include complex matrix-style test with positive and negative test cases of lossy conversions in compound assignments. Proposed patch also disables this new lint option in all affected JDK modules and libraries to allow smooth JDK build. Individual cases to address possibly lossy conversions warnings in JDK are already addressed in a separate umbrella issue and its sub-tasks. Thanks for your review, Adam ------------- Commit messages: - Merge branch 'openjdk:master' into JDK-8244681 - 8244681: Add a warning for possibly lossy conversion in compound assignments - 8244681: Add a warning for possibly lossy conversion in compound assignments Changes: https://git.openjdk.java.net/jdk/pull/8599/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8599&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8244681 Stats: 449 lines in 26 files changed: 444 ins; 0 del; 5 mod Patch: https://git.openjdk.java.net/jdk/pull/8599.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8599/head:pull/8599 PR: https://git.openjdk.java.net/jdk/pull/8599

9 31

RFR: 8286706: JFR: 'jfr scrub' should overwrite output
by Erik Gahlin 10 Aug '22

10 Aug '22

Could I have a review of a change that makes the 'jfr scrub' overwrite the output file if it already exists. Testing: /test/jdk/jdk/jfr/tool (Mac, Linux, Windows) Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.java.net/jdk/pull/8728/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8728&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8286706 Stats: 35 lines in 2 files changed: 34 ins; 0 del; 1 mod Patch: https://git.openjdk.java.net/jdk/pull/8728.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8728/head:pull/8728 PR: https://git.openjdk.java.net/jdk/pull/8728

4 6

RFR: 8282420: JFR: Remove event handlers
by Erik Gahlin 07 Jul '22

07 Jul '22

Hi, Could I have a review of a fix that removes event handler classes for JFR. Bytecode for event instrumentation is now only added to the event class. Benefits are: - No class memory leak in the boot class loader. - Reduce overhead from class loading during startup, which is important with additional JDK events that are coming (VirtualThreadStart etc.) - One less frame to traverse when recording a Java stack trace. Future benefits are: - Simplify creating instrumentation at build step. See https://bugs.openjdk.java.net/browse/JDK-8279354 - Simplify implementation of Event Metrics. See https://bugs.openjdk.java.net/browse/JDK-8224749 When the Security Manager is removed, much of the code being added for security reasons can be deleted. There are few JFR hooks when code is being linked. Plan is to also use these for other events later. Testing: tier 1-4, jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Test cleanup - Test fixes - Fix whitespaces - Use EventWriterFactory - Initial Changes: https://git.openjdk.java.net/jdk/pull/8383/files Webrev: https://webrevs.openjdk.java.net/?repo=jdk&pr=8383&range=00 Issue: https://bugs.openjdk.java.net/browse/JDK-8282420 Stats: 4016 lines in 79 files changed: 2412 ins; 1010 del; 594 mod Patch: https://git.openjdk.java.net/jdk/pull/8383.diff Fetch: git fetch https://git.openjdk.java.net/jdk pull/8383/head:pull/8383 PR: https://git.openjdk.java.net/jdk/pull/8383

6 18

[jdk19] RFR: 8289183: jdk.jfr.consumer.RecordedThread.getId references Thread::getId, should be Thread::threadId
by Erik Gahlin 03 Jul '22

03 Jul '22

Could I have a review of PR that changes documentation from the now deprecated method Thread.getId() to the new Thread.threadId(). I also fixed a typo, where it said "The Java thread". Should be "the OS thread". Testing: 'make docs' and inspect the result Thanks Erik ------------- Commit messages: - Change from 'The' to 'the' - Initial Changes: https://git.openjdk.org/jdk19/pull/93/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=93&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8289183 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk19/pull/93.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/93/head:pull/93 PR: https://git.openjdk.org/jdk19/pull/93

2 9

RFR: 8268398: 15% increase in JFR footprint in Noop-Base
by Erik Gahlin 27 Jun '22

27 Jun '22

Hi, Could I have review of a PR that skips bytecode instrumentation for container events and initialisation of Container.metrics() if the JVM is isn't running in a container, or to be precise, if container support is not available. If a user specifies -XX:-UseContainerSupport, events are not emitted. This was the case before this PR, and maybe it should be fixed, but it's an enhancement and outside the scope of this bug. Testing: - jdk/jdk/jfr - Manual testing in a container. I tried to run test/hotspot/jtreg/containers/docker/TestJFREvents.java, but the test is broken (image can't be built, so test is skipped). This fix may not be sufficient to reduce footprint introduced by the container events, but [JDK-8282420: JFR: Remove event handlers](https://bugs.openjdk.org/browse/JDK-8282420) also reduced number of loaded classes which should reduce footprint in JDK 19. There are an ongoing enhancement work to generate bytecode and metadata at build time, which will help, but it will be integrated in JDK 20. Thanks Erik ------------- Commit messages: - Initial Changes: https://git.openjdk.org/jdk19/pull/31/files Webrev: https://webrevs.openjdk.org/?repo=jdk19&pr=31&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8268398 Stats: 55 lines in 8 files changed: 40 ins; 5 del; 10 mod Patch: https://git.openjdk.org/jdk19/pull/31.diff Fetch: git fetch https://git.openjdk.org/jdk19 pull/31/head:pull/31 PR: https://git.openjdk.org/jdk19/pull/31

3 6

RFR: Merge jdk19
by Jesper Wilhelmsson 22 Jun '22

22 Jun '22

Forwardport JDK 19 -> JDK 20 ------------- Commit messages: - Merge - 8288988: ProblemList serviceability/jvmti/vthread/ContStackDepthTest/ContStackDepthTest.java in -Xcomp mode - 8288846: misc tests fail "assert(ms < 1000) failed: Un-interruptable sleep, short time use only" - 8288840: StructureViolationException should not link to fork method - 8287982: Concurrent implicit attach from native threads crashes VM - 8288529: broken link in java.xml The webrevs contain the adjustments done while merging with regards to each parent branch: - master: https://webrevs.openjdk.org/?repo=jdk&pr=9251&range=00.0 - jdk19: https://webrevs.openjdk.org/?repo=jdk&pr=9251&range=00.1 Changes: https://git.openjdk.org/jdk/pull/9251/files Stats: 434 lines in 12 files changed: 379 ins; 22 del; 33 mod Patch: https://git.openjdk.org/jdk/pull/9251.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9251/head:pull/9251 PR: https://git.openjdk.org/jdk/pull/9251

1 1

RFR: 8288982: JFR: Log event streaming actions
by Erik Gahlin 22 Jun '22

22 Jun '22

Could I have a review of a change that log event actions for an EventStream. Purpose is to find cause of intermittent failure of TestOnEvent. See https://bugs.openjdk.org/browse/JDK-8255404 Testing: test/jdk/jdk/jfr Thanks Erik ------------- Commit messages: - Fix formatting - Initial Changes: https://git.openjdk.org/jdk/pull/9244/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9244&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8288982 Stats: 17 lines in 3 files changed: 16 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9244.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9244/head:pull/9244 PR: https://git.openjdk.org/jdk/pull/9244

2 2