November 2024 - hotspot-jfr-dev

RFR: 8310996: Add JFR event for connect operations
by Tim Prinzing 17 Feb '25

17 Feb '25

Adds a JFR event for socket connect operations. Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events. ------------- Commit messages: - fix default settings - fix merge - Merge branch 'master' into JDK-8310996 - added tests and support for sockets. - 8310996: Add JFR event for connect operations Changes: https://git.openjdk.org/jdk/pull/21528/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21528&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8310996 Stats: 247 lines in 12 files changed: 236 ins; 3 del; 8 mod Patch: https://git.openjdk.org/jdk/pull/21528.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528 PR: https://git.openjdk.org/jdk/pull/21528

6 42

RFR: 8344191: Build code should not have classpath exception
by Magnus Ihse Bursie 15 Jan '25

15 Jan '25

In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data. The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception. This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience) ------------- Commit messages: - Update build tools, data and IDE support - Update makefiles, autoconf, shell scripts, properties files and configuration files Changes: https://git.openjdk.org/jdk/pull/22104/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344191 Stats: 2054 lines in 555 files changed: 0 ins; 1118 del; 936 mod Patch: https://git.openjdk.org/jdk/pull/22104.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104 PR: https://git.openjdk.org/jdk/pull/22104

6 7

RFR: 8344080: Return type mismatch for jfr_unregister_stack_filter
by Markus Grönlund 31 Dec '24

31 Dec '24

Greetings, Tiny adjustment to function declaration. Test: jdk_jfr Thanks Markus ------------- Commit messages: - 8344080 Changes: https://git.openjdk.org/jdk/pull/22068/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22068&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344080 Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/22068.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22068/head:pull/22068 PR: https://git.openjdk.org/jdk/pull/22068

4 6

RFR: 8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless
by Leonid Mesnik 06 Dec '24

06 Dec '24

Test jdk/jfr/startupargs/TestStartDuration.java checks duration, the time might be too small for stress options like Xcomp. So it makes sense to mark it as flaglesss. ------------- Commit messages: - 8340969: jdk/jfr/startupargs/TestStartDuration.java should be marked as flagless Changes: https://git.openjdk.org/jdk/pull/21237/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21237&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8340969 Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod Patch: https://git.openjdk.org/jdk/pull/21237.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21237/head:pull/21237 PR: https://git.openjdk.org/jdk/pull/21237

3 3

RFR: 8343780: Add since checker tests to the Tools area modules and add missing @since to jdk.jfr.Recording
by Nizar Benalla 03 Dec '24

03 Dec '24

Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers. The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK. Notes: - I have also added an `@since` tag that was missing. - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test) TIA ------------- Commit messages: - remove backticks - 8343780 Changes: https://git.openjdk.org/jdk/pull/21982/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343780 Stats: 16 lines in 6 files changed: 1 ins; 0 del; 15 mod Patch: https://git.openjdk.org/jdk/pull/21982.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21982/head:pull/21982 PR: https://git.openjdk.org/jdk/pull/21982

3 12

RFR: 8336041: Doccheck: the jfr command doesn't show the correct command-line options
by Nizar Benalla 29 Nov '24

29 Nov '24

After [JDK-8344056](https://bugs.openjdk.org/browse/JDK-8344056), we can now easily fix these typos that caused errors when rendering the HTML. While I didn't find anything in the markdown spec mentioning escaping angle brackets, this [stackoverflow answer](https://meta.stackoverflow.com/questions/288707/how-do-you-show-wor… says that we should use HTML entities for angle brackets. Otherwise the content inside `<>` is not shown. Doing so seems to fix the bug in the generated HTML. The output of the man pages is also broken (you can verify on your local machines as this bug exists exists in older JDKs) jfr metadata subcommand Use jfr metadata to display information about events, such as event names, categories and field layout within a flight recording file. The syntax is: jfr metadata [--categories ] [--events ] [] Before: <img width="750" alt="Screenshot 2024-11-19 at 17 13 58" src="https://github.com/user-attachments/assets/a94053a1-49f1-43c6-8116-fbc711c5…"> <img width="722" alt="Screenshot 2024-11-19 at 17 13 46" src="https://github.com/user-attachments/assets/2d6105d1-b55d-473f-8ba7-48c37d14…"> <img width="319" alt="Screenshot 2024-11-19 at 17 14 18" src="https://github.com/user-attachments/assets/c4ccc5e7-1f2f-4ce1-a1fc-e0436844…"> After: <img width="850" alt="Screenshot 2024-11-19 at 17 25 22" src="https://github.com/user-attachments/assets/a4b3f6ac-ffc4-4b73-9ffa-56219508…"> <img width="781" alt="Screenshot 2024-11-19 at 17 25 48" src="https://github.com/user-attachments/assets/76edc5cb-1be2-4c5b-bdc7-32c3ac6c…"> <img width="496" alt="Screenshot 2024-11-19 at 18 33 29" src="https://github.com/user-attachments/assets/647a68cc-5804-4e61-b4e2-de788e79…"> Here is the diff in the HTML after the change --- build/macosx-aarch64/images/docs/specs/man/jfr.html 2024-11-19 17:08:08 +++ build/macosx-aarch64/images/test/docs/specs/man/jfr.html 2024-11-19 17:04:30 @@ -225,8 +225,7 @@ Use <code>jfr configure</code> to configure a .jfc settings file. The syntax is: <code>jfr configure</code> [--interactive] [--verbose] [--input -<files>] [--output <file>] [option=value]* -[event-setting=value]* +<files>] [--output <file>] [option=value]* [event-setting=value]* <dl> <dt><a id="configure-option-interactive"><code>--interactive</code></a></dt> <dd> @@ -272,8 +271,8 @@ such as event names, categories and field layout within a flight recording file. The syntax is: -<code>jfr metadata</code> [--categories <filter>] [--events -<filter>] [<file>] +<code>jfr metadata</code> [--categories <filter>] [--events <filter>] +[<file>] <dl> <dt><a id="metadata-option-categories"><code>--categories</code> <filter></a></dt> @@ -292,8 +291,8 @@ Location of the recording file (.jfr) </dd> </dl> -If the <file> parameter is omitted, metadata from the JDK where -the 'jfr' tool is located will be used. +If the <file> parameter is omitted, metadata from the JDK where the +'jfr' tool is located will be used. <h4 id="jfr-summary-subcommand"><code>jfr summary</code> subcommand</h4> Use <code>jfr summary</code> to print statistics for a recording. For example, a summary can illustrate the number of recorded events and how Here is the diff between the two troff files 213,214c213,214 < \f[V]jfr configure\f[R] [--interactive] [--verbose] [--input ] [--output < ] [option=value]* [event-setting=value]* --- > \f[V]jfr configure\f[R] [--interactive] [--verbose] [--input <files>] > [--output <file>] [option=value]* [event-setting=value]* 255c255,256 < \f[V]jfr metadata\f[R] [--categories ] [--events ] [] --- > \f[V]jfr metadata\f[R] [--categories <filter>] [--events <filter>] > [<file>] 270c271 < If the parameter is omitted, metadata from the JDK where the --- > If the <file> parameter is omitted, metadata from the JDK where the ------------- Commit messages: - use < html entity Changes: https://git.openjdk.org/jdk/pull/22247/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22247&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8336041 Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22247.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22247/head:pull/22247 PR: https://git.openjdk.org/jdk/pull/22247

2 5

RFR: 8341427: JFR: Adjust object sampler span handling
by Stig Døssing 24 Nov '24

24 Nov '24

The span stored in each sample is not the calculated span, it's just the object's byte size (`allocated`). That means as soon as any object falls out of the queue, the spans in the queue no longer sum to cover the allocation timeline. This causes all future samples to be added to be unduly prioritized for adding to the queue, because they are given an artificially high span. In effect, future samples are weighted as if they cover both the interval between themselves and the older neighbor sample, plus all "missing spans" from nodes that have been discarded since the program started. Changed object samples to store the calculated span rather than the bytes allocated for the sampled object. When a sample is removed from the queue because a sample with a larger span is being added, the span of the removed node is not handed to the younger neighbor, this only happens when a sample is removed due to GC. This means that the span will be given to the next sample added to the queue. When the sample being removed is the youngest sample, this is fine, but when it's a sample that has a younger neighbor, the span should probably be given to that neighbor rather than the newcomer. Handing it to the newcomer gives the new sample a high weight it doesn't deserve. It ends up covering not just the span to the older neighbor, but also the span of the removed node, which is not what we want. When replacing a sample in the queue, give the span of the removed sample to the younger neighbor. If there is no such neighbor, because the youngest sample is being replaced, give the span to the node being added instead, as that will become the new youngest sample. ------------- Commit messages: - Adjust object sampler span handling Changes: https://git.openjdk.org/jdk/pull/19334/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19334&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8341427 Stats: 27 lines in 2 files changed: 21 ins; 4 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/19334.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/19334/head:pull/19334 PR: https://git.openjdk.org/jdk/pull/19334

5 14

RFR: 8343893: Test jdk/jfr/event/runtime/TestNativeMemoryUsageEvents.java failed: heap should have grown and NMT should show that: expected 0 > 0
by Johan Sjölen 22 Nov '24

22 Nov '24

# Background With the implementation of [JDK-8312132](https://bugs.openjdk.org/browse/JDK-8312132) we added the `MemoryFileTracker` (MFT). Unfortunately, this work failed to implement JFR integration. This, in turn, meant that (generational) ZGC has not correctly reported its heap usage via the NMT JFR events. We (as in Oracle) never saw this issue in testing, as we didn't run this test for all possible GC configurations. With an update of our test configurations this is no longer the case: We run this test for all possible GCs and the test now fails for generational ZGC. # The fix I implemented JFR events for the MFT by adding all of its reserved and committed memory into the JFR data, similarly to the `VirtualMemoryTracker`. I also added an explicit `run` using `ZGC` to the failing test, to ensure that any actual regressions are found. ------------- Commit messages: - Add MemoryFileTracker support to NMTUsage Changes: https://git.openjdk.org/jdk/pull/22204/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22204&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8343893 Stats: 40 lines in 5 files changed: 31 ins; 4 del; 5 mod Patch: https://git.openjdk.org/jdk/pull/22204.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22204/head:pull/22204 PR: https://git.openjdk.org/jdk/pull/22204

4 16

RFR: 8342285: Mark jdk/jfr/api/event/TestIsEnabledMultiple.java as intermittent
by SendaoYan 21 Nov '24

21 Nov '24

Hi all, The test `jdk/jfr/api/event/TestIsEnabledMultiple.java` has been observed intermittent failure several times. I think we should mark this test as intermittent failure. Trivial fix, no risk. ------------- Commit messages: - 8342285: Mark jdk/jfr/api/event/TestIsEnabledMultiple.java as intermittent Changes: https://git.openjdk.org/jdk/pull/21666/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21666&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8342285 Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod Patch: https://git.openjdk.org/jdk/pull/21666.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/21666/head:pull/21666 PR: https://git.openjdk.org/jdk/pull/21666

1 3

RFR: 8344056: Use markdown format for man pages
by Magnus Ihse Bursie 20 Nov '24

20 Nov '24

Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo. Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff. This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves. ------------- Commit messages: - Replace tabs with spaces - Remove logic for copying .1 man pages - Insert GPL header - Add missing Windows man pages for kerberos and accessibility - Replace generated troff man pages with markdown version Changes: https://git.openjdk.org/jdk/pull/22081/files Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00 Issue: https://bugs.openjdk.org/browse/JDK-8344056 Stats: 41443 lines in 65 files changed: 18943 ins; 22500 del; 0 mod Patch: https://git.openjdk.org/jdk/pull/22081.diff Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081 PR: https://git.openjdk.org/jdk/pull/22081

8 26