August 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: 8291753: Add JFR event for GC CPU Time
by Sangheon Kim 08 Sep '22

08 Sep '22

Hi all, Could I have reviews to add new JFR event for GC CPU time? Currently only log message is available for CPU time (user, system, real). As there is already GCTraceCPUTime class which is used for a log message, I added GCTracer to deliver the event. The log message of CPU time is printed after GC is completed and tried to keep same. For G1, manually checked there is not difference. For test, I had to add an exception as GCCpuTime will be generated after GC end. Testing: tier 1 ~ 3 Thanks, Sangheon ------------- Commit messages: - Split G1FullGCMark - Add JFR event of GCCpuTime. Changes: https://git.openjdk.org/jdk/pull/9760/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9760&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8291753 Stats: 181 lines in 20 files changed: 136 ins; 11 del; 34 mod Patch: https://git.openjdk.org/jdk/pull/9760.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9760/head:pull/9760 PR: https://git.openjdk.org/jdk/pull/9760

4 16

RFR: 8292592: JFR test TestNative is not reliable due to low rate of sampling.
by Robbin Ehn 19 Aug '22

19 Aug '22

Split TestNative into two different test, so native sampling can have a high frequency. ------------- Commit messages: - JFR test fixes Changes: https://git.openjdk.org/jdk/pull/9915/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9915&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292592 Stats: 210 lines in 3 files changed: 136 ins; 74 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/9915.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9915/head:pull/9915 PR: https://git.openjdk.org/jdk/pull/9915

3 8

RFR: 8292488: Incorrect comment in ActiveRecordingEvent
by chigiriki 18 Aug '22

18 Aug '22

please review this change. I checked the build succecfully just in case. No error occured. ------------- Commit messages: - 8292488: Incorrect comment in ActiveRecordingEvent Changes: https://git.openjdk.org/jdk/pull/9897/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=9897&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8292488 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/9897.diff Fetch: git fetch https://git.openjdk.org/jdk pull/9897/head:pull/9897 PR: https://git.openjdk.org/jdk/pull/9897

2 2

typo at ActiveRecordingEvent comment
by suematsu.shinya＠fujitsu.com 17 Aug '22

17 Aug '22

Hi, I’ｍ new to jdk project. I found trivial typo at ActiveRecordingEvent comment. Does anyone create an issue? // commit(... , long, String, String, String, long, long, long, long, long) String should be 2 times. Thanks

2 2

Re: RFR: 8291753: Add JFR event for GC CPU Time
by Erik Gahlin 15 Aug '22

15 Aug '22

On Fri, 12 Aug 2022 10:07:01 GMT, Sangheon Kim <sangheon.kim(a)oracle.com> wrote: > No. This event is provided via GCTraceCPUTime class with GCTracer. And both ZGC and Shenanadoah are not using it. If you are suggesting to support all GCs, it is out of scope. It may be address as a separate enhancement. > Thanks for the information. Do you see any issues adding the event for those GCs (as a separate enhancement)? There are no limitation in the information the OS can provide (per thread) or how the GCs are implemented. The reason I am asking is because we want the design of the event to be future proof, so we don't end up with multiple GC CPU events. Users are likely to complain if the event is missing for some GCs. It seems like a very useful event, so I think the demand will be high for other GCs as well. Could you write in the event description which GCs that are supported? An alternative would be to write the CPU usage as a percentage, similar to the CPULoad and ThreadCPU event. It would be a periodic event emitted every second and tools could display a graph of where the system is spending time. It could perhaps be complemented with a Compiler CPU event, as a separate enhancement. ------------- PR: https://git.openjdk.org/jdk/pull/9760

2 1

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