From alanb at openjdk.org  Wed Oct  1 12:39:48 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 1 Oct 2025 12:39:48 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
Message-ID: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>

On Tue, 30 Sep 2025 11:23:13 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?

I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 

> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?

"genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.

I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.

One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3356108097

From sherman at openjdk.org  Fri Oct  3 19:10:20 2025
From: sherman at openjdk.org (Xueming Shen)
Date: Fri, 3 Oct 2025 19:10:20 GMT
Subject: jmx-dev RFR: 8365675: Add String Unicode Case-Folding Support
Message-ID: <Yh0-Ch56i6KRhV2cx95VDcE_pIvt-0NGzc53fnXoQv8=.0870577e-cd94-41eb-bfe5-d5d72f69e179@github.com>

### Summary

Case folding is a key operation for case-insensitive matching (e.g., string equality, regex matching), where the goal is to eliminate case distinctions without applying locale or language specific conversions.

Currently, the JDK does not expose a direct API for Unicode-compliant case folding. Developers now rely on methods such as:

**String.equalsIgnoreCase(String)**

- Unicode-aware, locale-independent.
- Implementation uses Character.toLowerCase(Character.toUpperCase(int)) per code point.
- Limited: does not support 1:M mapping defined in Unicode case folding.

**Character.toLowerCase(int) / Character.toUpperCase(int)**

- Locale-independent, single code point only.
- No support for 1:M mappings.

**String.toLowerCase(Locale.ROOT) / String.toUpperCase(Locale.ROOT)**

- Based on Unicode SpecialCasing.txt, supports 1:M mappings.
- Intended primarily for presentation/display, not structural case-insensitive matching.
- Requires full string conversion before comparison, which is less efficient and not intended for structural matching.

**1:M mapping example, U+00DF (?)**

- String.toUpperCase(Locale.ROOT, "?") ? "SS"
- Case folding produces "ss", matching Unicode caseless comparison rules.


jshell> "\u00df".equalsIgnoreCase("ss")
$22 ==> false

jshell> "\u00df".toUpperCase(Locale.ROOT).toLowerCase(Locale.ROOT).equals("ss")
$24 ==> true


### Motivation & Direction

Add Unicode standard-compliant case-less comparison methods to the String class, enabling & improving reliable and efficient Unicode-aware/compliant case-insensitive matching.

- Unicode-compliant **full** case folding.
- Simpler, stable and more efficient case-less matching without workarounds.
- Brings Java's string comparison handling in line with other programming languages/libraries.

This PR proposes to introduce the following comparison methods in `String` class

- boolean equalsFoldCase(String anotherString)
- int compareToFoldCase(String anotherString)
- Comparator<String> UNICODE_CASEFOLD_ORDER

These methods are intended to be the preferred choice when Unicode-compliant case-less matching is required.

*Note: An early draft also proposed a String.toCaseFold() method returning a new case-folded string.
However, during review this was considered error-prone, as the resulting string could easily be mistaken for a general transformation like toLowerCase() and then passed into APIs where case-folding semantics are not appropriate.

### The New API


   /**
     * Compares this {@code String} to another {@code String} for equality,
     * using <em>Unicode case folding</em>. Two strings are considered equal
     * by this method if their case-folded forms are identical.
     * <p>
     * Case folding is defined by the Unicode Standard in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings. For example, {@code "Ma?e".equalsFoldCase("MASSE")}
     * returns {@code true}, since the character {@code U+00DF} (sharp s) folds
     * to {@code "ss"}.
     * <p>
     * Case folding is locale-independent and language-neutral, unlike
     * locale-sensitive transformations such as {@link #toLowerCase()} or
     * {@link #toUpperCase()}. It is intended for caseless matching,
     * searching, and indexing.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #equalsIgnoreCase(String)}. It implements full case folding as
     * defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code equalsIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * boolean equalsFoldCase = a.equalsFoldCase(b);       // returns true
     * boolean equalsIgnoreCase = a.equalsIgnoreCase(b);   // returns false
     * }</pre>
     *
     * @param  anotherString
     *         The {@code String} to compare this {@code String} against
     *
     * @return  {@code true} if the given object is not {@code null} and represents
     *          the same sequence of characters as this string under Unicode case
     *          folding; {@code false} otherwise.
     *
     * @see     #compareToFoldCase(String)
     * @see     #equalsIgnoreCase(String)
     * @since   26
     */
    public boolean equalsFoldCase(String anotherString)

    /**
     * Compares two strings lexicographically using <em>Unicode case folding</em>.
     * This method returns an integer whose sign is that of calling {@code compareTo}
     * on the Unicode case folded version of the strings. Unicode Case folding
     * eliminates differences in case according to the Unicode Standard, using the
     * mappings defined in
     * <a href="https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt">CaseFolding.txt</a>,
     * including 1:M mappings, such as {@code"?"} ? {@code }"ss"}.
     * <p>
     * Case folding is a locale-independent, language-neutral form of case mapping,
     * primarily intended for caseless matching. Unlike {@link #compareToIgnoreCase(String)},
     * which applies a simpler locale-insensitive uppercase mapping. This method
     * follows the Unicode <em>full</em> case folding, providing stable and
     * consistent results across all environments.
     * <p>
     * Note that this method does <em>not</em> take locale into account, and may
     * produce results that differ from locale-sensitive ordering. Use
     * {@link java.text.Collator} for locale-sensitive comparison.
     *
     * @apiNote
     * This method is the Unicode-compliant alternative to
     * {@link #compareToIgnoreCase(String)}. It implements the <em>full</em> case folding
     * as defined by the Unicode Standard, which may differ from the simpler
     * per-character mapping performed by {@code compareToIgnoreCase}.
     * For example:
     * <pre>{@snippet lang=java :
     * String a = "Ma?e";
     * String b = "MASSE";
     * int cmpFoldCase = a.compareToFoldCase(b);     // returns 0
     * int cmpIgnoreCase = a.compareToIgnoreCase(b); // returns > 0
     * }</pre>
     *
     * @param   str   the {@code String} to be compared.
     * @return  a negative integer, zero, or a positive integer as the specified
     *          String is greater than, equal to, or less than this String,
     *          ignoring case considerations by case folding.
     * @see     #equalsFoldCase(String)
     * @see     #compareToIgnoreCase(String)
     * @see     java.text.Collator
     * @since   26
     */
    public int compareToFoldCase(String str) 

    /**
     * A Comparator that orders {@code String} objects as by
     * {@link #compareToFoldCase(String) compareToFoldCase()}.
     *
     * @see     #compareToFoldCase(String)
     * @since   26
     */
    public static final Comparator<String> UNICODE_CASEFOLD_ORDER;



### Usage Examples

Sharp s (U+00DF) case-folds to "ss"


    "stra?e".equalsIgnoreCase("strasse");             // false
    "stra?e".compareToIgnoreCase("strasse");          // != 0
    "stra?e".equalsFoldCase("strasse");               // true



### Performance

The JMH microbenchmark StringCompareToIgnoreCase has been updated to compare performance of compareToFoldCase with the existing  compareToIgnoreCase().


Benchmark                                         Mode  Cnt   Score   Error  Units
StringCompareToIgnoreCase.asciiGreekLower         avgt   15  20.195 ? 0.300  ns/op
StringCompareToIgnoreCase.asciiGreekLowerCF       avgt   15  11.051 ? 0.254  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLower    avgt   15   6.035 ? 0.047  ns/op
StringCompareToIgnoreCase.asciiGreekUpperLowerCF  avgt   15  14.786 ? 0.382  ns/op
StringCompareToIgnoreCase.asciiLower              avgt   15  17.688 ? 1.396  ns/op
StringCompareToIgnoreCase.asciiLowerCF            avgt   15  44.552 ? 0.155  ns/op
StringCompareToIgnoreCase.asciiUpperLower         avgt   15  13.069 ? 0.487  ns/op
StringCompareToIgnoreCase.asciiUpperLowerCF       avgt   15  58.684 ? 0.274  ns/op
StringCompareToIgnoreCase.greekLower              avgt   15  20.642 ? 0.082  ns/op
StringCompareToIgnoreCase.greekLowerCF            avgt   15   7.255 ? 0.271  ns/op
StringCompareToIgnoreCase.greekUpperLower         avgt   15   5.737 ? 0.013  ns/op
StringCompareToIgnoreCase.greekUpperLowerCF       avgt   15  11.100 ? 1.147  ns/op
StringCompareToIgnoreCase.lower                   avgt   15  20.192 ? 0.044  ns/op
StringCompareToIgnoreCase.lowerrCF                avgt   15  11.257 ? 0.259  ns/op
StringCompareToIgnoreCase.supLower                avgt   15  54.801 ? 0.415  ns/op
StringCompareToIgnoreCase.supLowerCF              avgt   15  15.207 ? 0.418  ns/op
StringCompareToIgnoreCase.supUpperLower           avgt   15  14.431 ? 0.188  ns/op
StringCompareToIgnoreCase.supUpperLowerCF         avgt   15  19.149 ? 0.985  ns/op
StringCompareToIgnoreCase.upperLower              avgt   15   5.650 ? 0.051  ns/op
StringCompareToIgnoreCase.upperLowerCF            avgt   15  14.338 ? 0.352  ns/op
StringCompareToIgnoreCase.utf16SubLower           avgt   15  14.774 ? 0.200  ns/op
StringCompareToIgnoreCase.utf16SubLowerCF         avgt   15   2.669 ? 0.041  ns/op
StringCompareToIgnoreCase.utf16SupUpperLower      avgt   15  16.250 ? 0.099  ns/op
StringCompareToIgnoreCase.utf16SupUpperLowerCF    avgt   15  11.524 ? 0.327  ns/op



### Refs

[Unicode Standard 5.18.4 Caseless Matching](https://www.unicode.org/versions/latest/core-spec/chapter-5/#G21790)
[Unicode? Standard Annex #44: 5.6 Case and Case Mapping](https://www.unicode.org/reports/tr44/#Casemapping)
[Unicode Technical Standard #18:  Unicode Regular Expressions RL1.5: Simple Loose Matches](https://www.unicode.org/reports/tr18/#Simple_Loose_Matches)
[Unicode SpecialCasing.txt](https://www.unicode.org/Public/UCD/latest/ucd/SpecialCasing.txt)
[Unicode CaseFolding.txt](https://www.unicode.org/Public/UCD/latest/ucd/CaseFolding.txt)

### Other Languages

**Python string.casefold()**

The str.casefold() method in Python returns a casefolded version of a string. Casefolding is a more aggressive form of lowercasing, designed to remove all case distinctions in a string, particularly for the purpose of caseless string comparisons.

**Perl?s fc()**

Returns the casefolded version of EXPR. This is the internal function implementing the \F escape in double-quoted strings.
Casefolding is the process of mapping strings to a form where case differences are erased; comparing two strings in their casefolded form is effectively a way of asking if two strings are equal, regardless of case.
Perl only implements the full form of casefolding, but you can access the simple folds using "casefold()" in Unicode::UCD] ad "prop_invmap()" in Unicode::UCD]. 

**ICU4J UCharacter.foldCase (Java)** 

Purpose: Provides extensions to the standard Java Character class, including support for more Unicode properties and handling of supplementary characters (code points beyond U+FFFF).
Method Signature (String based): public static String foldCase(String str, int options)
Method Signature (CharSequence & Appendable based): public static <A extends Appendable> A foldCase(CharSequence src, A dest, int options, Edits edits)
Key Features:
Case Folding: Converts a string to its case-folded equivalent.
Locale Independent: Case folding in UCharacter.foldCase is generally not dependent on locale settings.
Context Insensitive: The mapping of a character is not affected by surrounding characters.
Turkic Option: An option exists to include or exclude special mappings for Turkish/Azerbaijani text.
Result Length: The resulting string can be longer or shorter than the original.
Edits Recording: Allows for recording of edits for index mapping, styled text, and getting only changes.

**u_strFoldCase (C/C++)**

A lower-level C API function for case folding a string.
Case Folding Options: Similar options as UCharacter.foldCase for controlling case folding behavior.
Availability: Found in the ustring.h and unistr.h headers in the ICU4C library.

-------------

Commit messages:
 - 8365675: Add String Unicode Case-Folding Support

Changes: https://git.openjdk.org/jdk/pull/26892/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=26892&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8365675
  Stats: 1279 lines in 12 files changed: 1116 ins; 137 del; 26 mod
  Patch: https://git.openjdk.org/jdk/pull/26892.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/26892/head:pull/26892

PR: https://git.openjdk.org/jdk/pull/26892

From duke at openjdk.org  Sun Oct  5 13:00:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:00:44 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Move from j.l.management to com.sun.management etc.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/ae29e031..64313101

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=00-01

  Stats: 345 lines in 13 files changed: 225 ins; 111 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Sun Oct  5 13:05:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:05:48 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
 <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
Message-ID: <4EoYAdS53Tor8IKojA3sXvzWPZOl7ENkvI7dvucgyj0=.12a455c1-03f7-490d-ac56-12e4fc63af19@github.com>

On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman
>> 
>>> The CSR is probably a bit premature ...
>> 
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
>> 
>>> Right now, the draft API spec makes it sounds very HotSpot VM specific.
>> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
>> 
>>> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.
>> 
>> Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).
>
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
> 
> I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 
> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
> 
> "genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.
> 
> I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.
> 
> One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

@AlanBateman if we agree on the new approach, I assume that a CSR would no longer be needed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369044318

From duke at openjdk.org  Sun Oct  5 13:05:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 5 Oct 2025 13:05:47 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <5dSkJW6Hrhm0M_3xFwlG4UwK1ITG2PvKhohIzQiDeA8=.cd29171f-1dae-486a-a525-beb13cb9ef2b@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

I introduced a JDK-specific MemoryMXBean in `com.sun.management` and added `getTotalGcCpuTime` there. I believe the Java idiomatic way to retrieve GC CPU time and process CPU time would be something like:


import java.lang.management.ManagementFactory;
import com.sun.management.MemoryMXBean;
import com.sun.management.OperatingSystemMXBean;

public class Main2 {
    public static void main(String[] args) {
        final MemoryMXBean mxMemoryBean = ManagementFactory.getPlatformMXBean(MemoryMXBean.class);
        final OperatingSystemMXBean mxOSBean = ManagementFactory.getPlatformMXBean(OperatingSystemMXBean.class);

        System.out.println("getTotalGcCpuTime: " + mxMemoryBean.getTotalGcCpuTime());
        System.out.println("getProcessCpuTime: " + mxOSBean.getProcessCpuTime());
    }
}


Given that `getTotalGcCpuTime` is most useful when you also sample process CPU time I like this symmetry, thanks for the suggestion.

I updated the language in the documentation:


    /**
     * Returns the CPU time used by garbage collection.
     *
     * <p> CPU time used by all garbage collection. In
     * general this includes time for all driver threads,
     * workers, VM operations on the VM thread and the string
     * deduplication thread (if enabled). May be non-zero even if no
     * GC cycle occurred. This method returns {@code -1} if the
     * platform does not support this operation or if called during
     * shutdown.
     *
     * @return the total accumulated CPU time for garbage collection
     * in nanoseconds.
     *
     * @since 26
     */


Since we include time om VM thread which strictly is not a garbage collection thread I think it is better to constrain it to "garbage collection" in general. Let me know what you think.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369043846

From alanb at openjdk.org  Sun Oct  5 13:20:47 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 5 Oct 2025 13:20:47 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time
In-Reply-To: <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <nnePb9arPNgCqeJ3E-SlEq9IP21yfpUzDR1Gx6quZi4=.20d707b9-32e5-4599-986b-0068aa07c58a@github.com>
 <RsgSJKKc_jNE0RlZbT_XsWY3pOjSIRnmv0_7jVt-ybA=.1369a0c7-df53-4aef-8c16-0a93e100676e@github.com>
 <7wmf-1DUhidWeIJX6_A412wvVsxod9U2KOS-fxCPBIk=.5570ef04-e73d-47e8-8f1e-ff9f221f9e93@github.com>
 <41FB-kOo62_PtOWdoYSos_6uzvXVZkcRO6kCRArEs2o=.c57dad90-c3a0-4371-9a50-1a2a56f424b1@github.com>
Message-ID: <XMa-r0ly3bAyMX-j6DVKHFSO2gSGgaOCt-d_9ppCCGs=.c2ebb81f-5072-4b79-9a1c-0652c8d987a3@github.com>

On Wed, 1 Oct 2025 12:36:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> @AlanBateman
>> 
>>> The CSR is probably a bit premature ...
>> 
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
>> 
>>> Right now, the draft API spec makes it sounds very HotSpot VM specific.
>> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
>> 
>>> If added to an existing interface then it will need to be a default method and specifies to have default behavior when not implemented.
>> 
>> Great point. Should have added a default behavior. Will include that in an updated PR (if we reach a consensus that we should add it to an existing interface).
>
>> Sorry if I broke protocol (first time I submit a PR requiring a CSR). Are you saying that I should had sent out this suggestion on a mailing list for a pre-discussion before actually submitting the CSR?
> 
> I don't think there are rules or a protocol around this. It's mostly just to avoid trying to get agreement on a direction in two places at the same time. 
> 
>> Could you elaborate on what makes this HotSpot VM specific? I think driver threads and workers are a generic concept but I do see your point that VM operations and string deduplication tends to be more HotSpot VM specific. Is that what you meant? I added these specific pointers in an effort to be helpful for a user to understand what parts the metric could include (but for actual details they would need to go to the VM implementation). To avoid being HotSpot VM specific I prefaced with "In general, ...". Should I remove these specialized pointers?
> 
> "genesis", "VM operations on the VM thread", ... are very implementation specific. The API docs, esp. the standard APIs, have to VM and independent of implementation. In some places you'll have usage of `@implNote` with details on of the implementation in the JDK.
> 
> I think the main question for the proposal is which management interface is appropriate. The j.l.management API was designed a long time ago (JSR-174, Java 5) and the abstractions it defines (memory, memory manager, memory pools) mean there isn't an obvious place for attributes and operations like the attribute proposed here. On the surface it might seem that "the" GarbageCollectorMXBean is the right place but it's not a singleton, instead there are 2, 3, or 4 management interfaces for each GC. I assume this is why the proposal is currently to add an read-only attribute to MemoryMXBean.
> 
> One idea to try is introducing a JDK-specific MemoryMXBean, meaning in com.sun.management with the other JDK-specific management interfaces. This would give you flexibility to introduce the notion of "GC threads" (the APIs don't know about non-Java threads), and reference OperatingSystemMXBean::getProcessCpuTime as this is also a JDK-specific management interfaces. Would you be able to try that out and see what issue come up?

> @AlanBateman if we agree on the new approach, I assume that a CSR would no longer be needed?

A JDK-specific management interface is a supported/documented interface so additions/changes will need a CSR. I would suggest ignoring for the CSR for a few days to give time for feedback here on the updated proposal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3369053361

From jkern at openjdk.org  Mon Oct  6 09:52:54 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Mon, 6 Oct 2025 09:52:54 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v7]
In-Reply-To: <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
Message-ID: <A04kbCJL5HCmPM1eR5uDG83Xe14ATHv3L7Vujf-lei8=.d185560b-6dcd-4adb-b59f-d05087f3ac43@github.com>

On Thu, 25 Sep 2025 14:35:51 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update UnixOperatingSystem.c
>   
>   change sequence

Now code looks good two me.

-------------

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3303645119

From mdoerr at openjdk.org  Mon Oct  6 11:04:53 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 11:04:53 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v7]
In-Reply-To: <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
Message-ID: <2onpGH0hXTL54MCYhiYFqL02uoTJXw4vQNLcBcI0ioA=.406b9108-dcea-420c-9770-d4c712640e59@github.com>

On Thu, 25 Sep 2025 14:35:51 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update UnixOperatingSystem.c
>   
>   change sequence

This looks good. Thanks for implementing it! A few minor nits.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 34:

> 32: #include <stdlib.h>
> 33: #include <libperfstat.h>
> 34: #include <pthread.h>

This is outside of hotspot, but I'd still sort includes (HotSpot style guide says "Keep the include lines sorted.").

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 36:

> 34: #include <pthread.h>
> 35: #include "com_sun_management_internal_OperatingSystemImpl.h"
> 36: #define HTIC2SEC(x) (((double)(x) * XINTFRAC) / 1000000000.0)

I'd prefer using `HTIC2NANOSEC(timebase_diff) / 1000000000.0` and removing this macro. It's only used at one place.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 91:

> 89:             load = 0.0;
> 90:         }
> 91:         else {

Coding style: We typically don't start a new line for `else`.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 128:

> 126:         counters.stats = curr_stats;
> 127:         counters.timebase = curr_timebase;
> 128:         if(delta_time == 0) {

Whitespace after `if`.

src/jdk.management/aix/native/libmanagement_ext/UnixOperatingSystem.c line 130:

> 128:         if(delta_time == 0) {
> 129:             cpu_load = 0.0;
> 130:         }

Same here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3303835839
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405682597
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405699968
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405708424
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405710898
PR Review Comment: https://git.openjdk.org/jdk/pull/25332#discussion_r2405710177

From alanb at openjdk.org  Mon Oct  6 11:48:50 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 6 Oct 2025 11:48:50 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

src/jdk.management/share/classes/com/sun/management/MemoryMXBean.java line 45:

> 43:      * GC cycle occurred. This method returns {@code -1} if the
> 44:      * platform does not support this operation or if called during
> 45:      * shutdown.

Now that the proposal is a JDK-specific management interface it means that this method can say something about how it relates to, or how it might be used with, OperatingSystemMXBean::getProcessCpuTime. 

I'm also wondering about ThreadMXBean::isThreadCpuTimeSupported. Is it possible for this to return false but getTotalGcCpuTime to return a value >= 0. The former concerns Java threads so it might not have any connection to this new method which concerns CPU usage by non-Java threads, but someone is bound to ask.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2405893440

From sroy at openjdk.org  Mon Oct  6 12:08:23 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 12:08:23 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v8]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:

 - Merge branch 'openjdk:master' into cpuprocessload
 - Update UnixOperatingSystem.c
   
   change sequence
 - Merge branch 'openjdk:master' into cpuprocessload
 - Thread safety,struct and perfInit()
 - Thread safety,struct and perfInit()
 - Update ProblemList.txt
 - Merge branch 'master' into cpuprocessload
 - Merge branch 'master' into cpuprocessload
 - Update UnixOperatingSystem.c
 - Merge branch 'openjdk:master' into cpuprocessload
 - ... and 4 more: https://git.openjdk.org/jdk/compare/2bfada3f...b31e68c9

-------------

Changes: https://git.openjdk.org/jdk/pull/25332/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=07
  Stats: 100 lines in 2 files changed: 94 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

PR: https://git.openjdk.org/jdk/pull/25332

From duke at openjdk.org  Mon Oct  6 12:22:48 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 6 Oct 2025 12:22:48 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <8oYDIDNvjjkyTMtvxKX9B9DN5Dcjx1HpmUKPECGAqDs=.7377c74c-93ee-4e15-a164-da28691cdd3e@github.com>
Message-ID: <JkqE79GvlPwCKJumq_ADRDzrm8poExa9abYAXgbcwWo=.e7d89796-16f1-49cb-8efa-694c6f859c59@github.com>

On Mon, 6 Oct 2025 11:46:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I'm also wondering about ThreadMXBean::isThreadCpuTimeSupported. Is it possible for this to return false but getTotalGcCpuTime to return a value >= 0.

`ThreadMXBean::isThreadCpuTimeSupported` uses the value from `os::is_thread_cpu_time_supported`:

https://github.com/openjdk/jdk/blob/6431310109a02ec5c34f877a1c690afb00193043/src/hotspot/share/services/management.cpp#L131-L137

I ensure to always return `-1` if thread cpu time is not supported as this is the contract that is promised by the documentation.

https://github.com/openjdk/jdk/blob/6431310109a02ec5c34f877a1c690afb00193043/src/hotspot/share/services/management.cpp#L894-L896

So, no this is not possible. However, `is_thread_cpu_time_enabled` is not being considered, but as you say, this method only concerns Java threads.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2405993712

From mdoerr at openjdk.org  Mon Oct  6 12:30:57 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 12:30:57 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v8]
In-Reply-To: <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
Message-ID: <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>

On Mon, 6 Oct 2025 12:08:23 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
> 
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>    
>    change sequence
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - Thread safety,struct and perfInit()
>  - Thread safety,struct and perfInit()
>  - Update ProblemList.txt
>  - Merge branch 'master' into cpuprocessload
>  - Merge branch 'master' into cpuprocessload
>  - Update UnixOperatingSystem.c
>  - Merge branch 'openjdk:master' into cpuprocessload
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2bfada3f...b31e68c9

Problem list needs an update, too. See error message above.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3371396115

From sroy at openjdk.org  Mon Oct  6 14:21:30 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 14:21:30 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v9]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:

  review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/b31e68c9..18897e90

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=07-08

  Stats: 11 lines in 1 file changed: 2 ins; 5 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

PR: https://git.openjdk.org/jdk/pull/25332

From sroy at openjdk.org  Mon Oct  6 14:21:32 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 14:21:32 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v8]
In-Reply-To: <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
 <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>
Message-ID: <LfO3Ro1Oipuvts4QRTviE-6vI3ywa7OSEgeHH1l3524=.6fa32de0-d920-4f79-928d-99cbcd04d12c@github.com>

On Mon, 6 Oct 2025 12:28:23 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> Problem list needs an update, too. See error message above.

Hi Martin 
which error are you referring to ? I am unable to view any particular error message.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3371912370

From mdoerr at openjdk.org  Mon Oct  6 15:35:25 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 15:35:25 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v8]
In-Reply-To: <LfO3Ro1Oipuvts4QRTviE-6vI3ywa7OSEgeHH1l3524=.6fa32de0-d920-4f79-928d-99cbcd04d12c@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ySxKfYKe1L3keLZR1qwgwx9KeVMdt2Q1tEQGJeX5V-A=.e6f05264-6720-4e78-83d9-f627a7f09ce9@github.com>
 <EC4v3SyRXDPZiPDv0jRgiCj3pcsg6_lmdE7m8P6kRhY=.d391c37a-2f7a-403f-b912-024552fec89b@github.com>
 <LfO3Ro1Oipuvts4QRTviE-6vI3ywa7OSEgeHH1l3524=.6fa32de0-d920-4f79-928d-99cbcd04d12c@github.com>
Message-ID: <XSI1PoLRusuwC95IMWXJHu1XbnTiN63oRog5jlrCuRw=.2ca43356-078c-4f87-a80d-bcb0fb2029de@github.com>

On Mon, 6 Oct 2025 14:16:00 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > Problem list needs an update, too. See error message above.
> 
> Hi Martin which error are you referring to ? I am unable to view any particular error message.

Error

 ?? 8030957 is used in problem lists: [test/jdk/ProblemList.txt]

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372328703

From mdoerr at openjdk.org  Mon Oct  6 15:39:29 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 15:39:29 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v9]
In-Reply-To: <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
Message-ID: <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>

On Mon, 6 Oct 2025 14:21:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

There is still "javax/management/MBeanServer/OldMBeanServerTest.java            8030957 aix-all". Does this test work as well, now?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372347450

From mdoerr at openjdk.org  Mon Oct  6 15:43:20 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 15:43:20 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <K2IvnMyjWTc_2ZFxJH5c_jB0IxCmbSNMVrIrmim2WEM=.decfe268-b3f4-493a-8001-fe378a694c43@github.com>
Message-ID: <9CUh04oikviQyZw5O7Rx1FnQHmOVZKvL2Dfp5ZG3Beo=.3b3fc738-35c5-44c9-8193-a08c892140bf@github.com>

On Tue, 8 Jul 2025 13:16:54 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> If we only address minimum AIX 7.2 we can probably simplify this approach or even go away from the current dynamic loading approach. See also https://bugs.openjdk.org/browse/JDK-8222719 where I did already some cleanup (but kept the AIX 7.1 vs. 7.2 ) .

Dynamic loading was originally implemented for as400/PASE support. The support has never made it into OpenJDK. So, yes, that could be cleaned up.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372369557

From sroy at openjdk.org  Mon Oct  6 16:01:42 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Mon, 6 Oct 2025 16:01:42 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v9]
In-Reply-To: <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
 <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>
Message-ID: <Eaiwo5UYja60gLAckWZnBqvJrfpqC18OD0bIjT1wpjU=.0901674d-6258-4f15-ab31-fdad8c9a5c0b@github.com>

On Mon, 6 Oct 2025 15:36:18 GMT, Martin Doerr <mdoerr at openjdk.org> wrote:

> javax/management/MBeanServer/OldMBeanServerTest.java

The test is getting skipped. Do we use a different bug id ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3372467771

From mdoerr at openjdk.org  Mon Oct  6 20:46:47 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Mon, 6 Oct 2025 20:46:47 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v9]
In-Reply-To: <Eaiwo5UYja60gLAckWZnBqvJrfpqC18OD0bIjT1wpjU=.0901674d-6258-4f15-ab31-fdad8c9a5c0b@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
 <Wnsc2B4nfqeavbo1sjIghuCQiH4sFMzLH-qkS8tsQGU=.ae1e11c6-68f1-4278-8041-69dd538c40f7@github.com>
 <Eaiwo5UYja60gLAckWZnBqvJrfpqC18OD0bIjT1wpjU=.0901674d-6258-4f15-ab31-fdad8c9a5c0b@github.com>
Message-ID: <R5didGqtb8kobJ3XBSZ1-Qk1mgeP_0sgrV_MsCMQHaU=.1e77b3ef-b0b9-44e5-b594-c587c90fe572@github.com>

On Mon, 6 Oct 2025 15:58:48 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> > javax/management/MBeanServer/OldMBeanServerTest.java
> 
> The test is getting skipped. Do we use a different bug id ?

It's getting skipped because it's in the ProblemList. I think you can simply remove it from the ProblemList.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3374020707

From mbaesken at openjdk.org  Tue Oct  7 07:14:52 2025
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 7 Oct 2025 07:14:52 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v9]
In-Reply-To: <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ocGisbPkvkBRJtakU3CDcFm7_O8_cQeLtyIGm5mmlH8=.98f5a061-7c1a-4be2-ae47-9fc52ad06fd0@github.com>
Message-ID: <Paco4omOj8wH8f5QqhCxA05iuR2Etgn5Y1Z_2_KcRP0=.e6f30b6b-6b6c-4f49-b6e5-79cfe8b71977@github.com>

On Mon, 6 Oct 2025 14:21:30 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   review comments

Looks okay  to me; but please handle the problemlist too (was pointed out already).

-------------

Marked as reviewed by mbaesken (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3308718969

From sroy at openjdk.org  Tue Oct  7 10:41:26 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 7 Oct 2025 10:41:26 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v10]
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:

 - problem list
 - problem list
 - problem list

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/25332/files
  - new: https://git.openjdk.org/jdk/pull/25332/files/18897e90..432022f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=25332&range=08-09

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/25332.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/25332/head:pull/25332

PR: https://git.openjdk.org/jdk/pull/25332

From mdoerr at openjdk.org  Tue Oct  7 10:59:50 2025
From: mdoerr at openjdk.org (Martin Doerr)
Date: Tue, 7 Oct 2025 10:59:50 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v10]
In-Reply-To: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
Message-ID: <JganxtcqKhfDMQrlOpeWiQXEm6LIETnqHVLxZD7tTkQ=.73d8ba6c-36fe-49ac-9288-e275297dfe15@github.com>

On Tue, 7 Oct 2025 10:41:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - problem list
>  - problem list
>  - problem list

Thanks for the update!

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3309573669

From sroy at openjdk.org  Tue Oct  7 13:01:57 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Tue, 7 Oct 2025 13:01:57 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v8]
In-Reply-To: <A04kbCJL5HCmPM1eR5uDG83Xe14ATHv3L7Vujf-lei8=.d185560b-6dcd-4adb-b59f-d05087f3ac43@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <Gk1QjmmJPvRl36tJZ2DQKBKQEA83iCx42mqn61Ez77g=.934394a6-999d-494e-833a-7e6d2c51ecbb@github.com>
 <A04kbCJL5HCmPM1eR5uDG83Xe14ATHv3L7Vujf-lei8=.d185560b-6dcd-4adb-b59f-d05087f3ac43@github.com>
Message-ID: <0m2jzwhOjmO9U7RQkZ3YSeRiF4zzfbzQXtpIpamUrbQ=.c9f408b1-38fb-4a9d-bdc0-e241a907254f@github.com>

On Mon, 6 Oct 2025 09:49:46 GMT, Joachim Kern <jkern at openjdk.org> wrote:

>> Suchismith Roy has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 14 commits:
>> 
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>    
>>    change sequence
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - Thread safety,struct and perfInit()
>>  - Thread safety,struct and perfInit()
>>  - Update ProblemList.txt
>>  - Merge branch 'master' into cpuprocessload
>>  - Merge branch 'master' into cpuprocessload
>>  - Update UnixOperatingSystem.c
>>  - Merge branch 'openjdk:master' into cpuprocessload
>>  - ... and 4 more: https://git.openjdk.org/jdk/compare/2bfada3f...b31e68c9
>
> Now code looks good two me.

Hi @JoKern65 and @MBaesken  , can you approve the changes if all looks ok, since new commit removed the old approvals.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3376784925

From jkern at openjdk.org  Wed Oct  8 09:02:08 2025
From: jkern at openjdk.org (Joachim Kern)
Date: Wed, 8 Oct 2025 09:02:08 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v10]
In-Reply-To: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
Message-ID: <QusPSE9PAYxX7YZbpRTDF52mEaxFEVkcHEry7SWzg-o=.7120d7ec-8033-4fa8-8869-1dd4121694a0@github.com>

On Tue, 7 Oct 2025 10:41:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - problem list
>  - problem list
>  - problem list

Still looks good to me

-------------

Marked as reviewed by jkern (Committer).

PR Review: https://git.openjdk.org/jdk/pull/25332#pullrequestreview-3313790272

From duke at openjdk.org  Wed Oct  8 09:07:42 2025
From: duke at openjdk.org (duke)
Date: Wed, 8 Oct 2025 09:07:42 GMT
Subject: jmx-dev RFR: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
 [v10]
In-Reply-To: <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
 <ZlB2G4Pxf3QXK7SCIE7zVRT0bKU0NlKH-f_uSJYPHVo=.5a8dcbe3-96fe-4fb4-86c6-fabe3160c1ab@github.com>
Message-ID: <cROUxy8luDkxUCfmUzJIhfAGx6Vy7eW196LsQLW2e_0=.4cfdf8ee-01b1-424b-9bfc-2afc8c18fc46@github.com>

On Tue, 7 Oct 2025 10:41:26 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

>> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
>> 
>> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
>> 
>> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
>> 
>> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
>> 
>> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
>> 
>> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
>> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all
>
> Suchismith Roy has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - problem list
>  - problem list
>  - problem list

@suchismith1993 
Your change (at version 432022f07def54a54b47d0302ecfa5974e6b43e9) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/25332#issuecomment-3380542958

From sroy at openjdk.org  Wed Oct  8 09:18:47 2025
From: sroy at openjdk.org (Suchismith Roy)
Date: Wed, 8 Oct 2025 09:18:47 GMT
Subject: jmx-dev Integrated: JDK-8030957 - AIX: Implement
 OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX
In-Reply-To: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
References: <yXCvgLfqR6njrThw64aiG0NOmEjQBxy44ihOj9eq2O0=.15d50acd-a7f5-4a25-9c97-1d68e2267f57@github.com>
Message-ID: <hstUyHhx082Ex0PLKbP6K6LypisAZ0Jgn6Lx_2Oh6pU=.ae1f94a0-edf9-4143-ae74-52c095b9c4ae@github.com>

On Tue, 20 May 2025 15:32:21 GMT, Suchismith Roy <sroy at openjdk.org> wrote:

> JBS Issue : [JDK-8030957](https://bugs.openjdk.org/browse/JDK-8030957)
> 
> These two methods should be implemented in src/aix/native/sun/management/AixOperatingSystem.c (which has to be created).
> 
> getProcessCpuLoad() can be probably implemented in the same way like on Solaris be reading /proc/self/psinfo
> 
> For getSystemCpuLoad() we'll probalby have to use 'perfstat_cpu_total()' from libperf (see http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.prftools/doc/prftools/prftools07.htm#wq407)
> 
> Once this issue has been resolved the below two excludes must be removed from jdk/test/ProblemList.txt:
> 
> com/sun/management/OperatingSystemMXBean/GetProcessCpuLoad.java aix-all
> com/sun/management/OperatingSystemMXBean/GetSystemCpuLoad.java aix-all

This pull request has now been integrated.

Changeset: d45e65ba
Author:    Suchismith Roy <sroy at openjdk.org>
Committer: Varada M <varadam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d45e65bab45f78f9f378cdc53837fe33190b7801
Stats:     98 lines in 2 files changed: 91 ins; 3 del; 4 mod

8030957: AIX: Implement OperatingSystemMXBean.getSystemCpuLoad() and .getProcessCpuLoad() on AIX

Reviewed-by: jkern, mdoerr, mbaesken

-------------

PR: https://git.openjdk.org/jdk/pull/25332

From duke at openjdk.org  Thu Oct  9 11:08:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Thu, 9 Oct 2025 11:08:04 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <oXzhqZKUqdw8fRdoRBOAZ74YGC2pZ0SX7UgqaPGz94g=.10b90d7e-ff79-42fc-9f89-b6a77f8f0490@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Thanks all for your suggestions. I have updated the CSR to align with the discussion in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3385342335

From kevinw at openjdk.org  Thu Oct  9 14:02:33 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 9 Oct 2025 14:02:33 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Questions that this change brings up to me:

Is there a general understanding or a statement of what it means to be standard or JDK-specific in this area?
If previous JSRs which specified JMX independently were the spec, and are these days part of the JDK Platform, what does it mean to be standard or JDK-specific?

How do we make it easy for somebody to add useful features in the right place...

Particularly on this method about GC time, I don't really follow the reasoning for not accepting the method in java.lang.MemoryMXBean.

The most generic Java API can admit that Java is Garbage-Collected, and that doing that work can take some CPU time.

The originally proposed JavaDoc had some HotSpot-specific terms in it, which maybe did not fit.  But they could still be valid if rephrased as a note of examples of the kinds of things that an implementation may need to do.

I'm wondering if the com.sun.management... interfaces made sense as a way to add features outside of an original JSR spec.  Maybe that was their intent.  But are we still in that world, do we still need to do that?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3386013198

From kevinw at openjdk.org  Fri Oct 10 16:17:32 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Fri, 10 Oct 2025 16:17:32 GMT
Subject: jmx-dev RFR: 8369574: Remove
 javax/management/remote/mandatory/connection/BrokenConnectionTest.java from
 ProblemList-Virtual.txt
Message-ID: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>

This test was probemlisted (JDK-8307369) like several tests that were occasionally hanging on Windows when used with virtual threads.

This test looks reliable now.  Key change may have been JDK-8282726.

Trivially remove from problem list.

-------------

Commit messages:
 - 8308035: Remove javax/management/remote/mandatory/connection/BrokenConnectionTest.java from ProblemList-Virtual.txt

Changes: https://git.openjdk.org/jdk/pull/27747/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=27747&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369574
  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27747.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27747/head:pull/27747

PR: https://git.openjdk.org/jdk/pull/27747

From ayang at openjdk.org  Fri Oct 10 20:02:01 2025
From: ayang at openjdk.org (Albert Mingkun Yang)
Date: Fri, 10 Oct 2025 20:02:01 GMT
Subject: jmx-dev RFR: 8369574: Remove
 javax/management/remote/mandatory/connection/BrokenConnectionTest.java from
 ProblemList-Virtual.txt
In-Reply-To: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
References: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
Message-ID: <fliguDS_eTZiTBhRgJQhRRUsyl3FLgUscf_waadc9Uk=.2c6b6726-b68b-43a6-93bf-b24ac504ab22@github.com>

On Fri, 10 Oct 2025 15:51:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted (JDK-8307369) like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now.  Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

Marked as reviewed by ayang (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/27747#pullrequestreview-3325753324

From kevinw at openjdk.org  Mon Oct 13 08:16:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 13 Oct 2025 08:16:28 GMT
Subject: jmx-dev RFR: 8369574: Remove
 javax/management/remote/mandatory/connection/BrokenConnectionTest.java from
 ProblemList-Virtual.txt
In-Reply-To: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
References: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
Message-ID: <poKon75o18VrQBi5onJBkfiZj-HzFZ5ok2kLnQgmxGE=.ee5ff166-9636-4145-9d70-021bb125d201@github.com>

On Fri, 10 Oct 2025 15:51:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted (JDK-8307369) like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now.  Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

Thanks Albert!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27747#issuecomment-3396350764

From kevinw at openjdk.org  Mon Oct 13 08:16:28 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 13 Oct 2025 08:16:28 GMT
Subject: jmx-dev Integrated: 8369574: Remove
 javax/management/remote/mandatory/connection/BrokenConnectionTest.java from
 ProblemList-Virtual.txt
In-Reply-To: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
References: <whhStmeWBEtflOHS83JGqL9YNL1SdGHlrYwA6NiV9PQ=.0078f6bf-da46-4154-a513-d6a247e00e76@github.com>
Message-ID: <Vo5fLaxqH-UKTPpHWMiWu5yyXlm7n44sWcmmwuvChCg=.d5b7467f-77f3-4e86-a0a5-6db895acf9a2@github.com>

On Fri, 10 Oct 2025 15:51:08 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> This test was probemlisted (JDK-8307369) like several tests that were occasionally hanging on Windows when used with virtual threads.
> 
> This test looks reliable now.  Key change may have been JDK-8282726.
> 
> Trivially remove from problem list.

This pull request has now been integrated.

Changeset: 1605e839
Author:    Kevin Walls <kevinw at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1605e8392e8efa972134a0bf3eecad0ed4f992fa
Stats:     3 lines in 1 file changed: 0 ins; 2 del; 1 mod

8369574: Remove javax/management/remote/mandatory/connection/BrokenConnectionTest.java from ProblemList-Virtual.txt

Reviewed-by: ayang

-------------

PR: https://git.openjdk.org/jdk/pull/27747

From alanb at openjdk.org  Mon Oct 13 09:51:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 13 Oct 2025 09:51:10 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <LR1PGdt1IN-HXt_CmPxqe8kYm0VfXPPXoeexU5sMGZA=.b7d50f5d-fa83-4d1d-80fb-563bc6276920@github.com>
Message-ID: <61w8E0BpN40jLzkmF8Yslw2ouRneaninNCWhr3b9SW8=.6562492c-345e-4bf5-a2f9-c9a4dec39097@github.com>

On Thu, 9 Oct 2025 13:59:05 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> Questions that this change brings up to me:
> 
> Is there a general understanding or a statement of what it means to be standard or JDK-specific in this area? If previous JSRs which specified JMX independently were the spec, and are these days part of the JDK Platform, what does it mean to be standard or JDK-specific?

It's similar to standard APIs vs. JDK-specific APIs. A management interface with HotSpot VM or JDK-specific attributes or operations would be a candidate for the jdk.management module rather than the java.management module. 

I wasn't directly involved in JSR-174 but there were three VM vendors in the EG at the time. The management interfaces that were defined had to be feasible to implement on all. There was interest in further management interfaces and the Sun JDK defined its extensions in com.sun.management. The word "extension" is significant here because asking the platform MBeanServer for a standard MXBean (either directly or via the standard object name) provides access to additional attributes/operations defined by the extension. It might seem a bit strange to see csm.ThreadMXBean extends jlm.ThreadMXBean, but that was the pattern established back in JDK 5. A lookup of say "java.lang:type=Threading" gives access to csm.ThreadMXBean with the additional attributes and operations defined in the subclass. It may be that some of the attributes or operations in these extensions could be proposed for the standard management interfaces, not clear if this is worth doing. TBH, I think the bigger issue is th
 at these management interfaces haven't evolved significantly, they pre-date fully concurrent GCs and other significant improvements.

Note that are some management interfaces that are clearly HotSpot VM or JDK-specific, e.g. csm.HotSpotDiagnosticMXBean and jdk.management.VirtualThreadSchedulerMXBean.

As regards the proposal here. I think the API docs will need work. The standard APIs don't know about non-Java threads. This is why it can't speak of "driver threads" and the "VM thread". It seems reasonable to introduce the notion that garbage collection consuming CPU cycle but anything about STW vs. concurrent GCs is more for an implNote. One of the goals, as I understand it, is to use it in conjunction with JDK-specific OperatingSystemMXBean "processCpuTime" attribute. It's possible to cross link in API docs but its relation to that attribute can't be normative if in a standard API. So I think focus on the specifying the attribute first. So far I think Jonas has demonstrated that it is feasible to implementation as either a standard or extension.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3396681608

From kevinw at openjdk.org  Wed Oct 15 10:08:23 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 10:08:23 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <MVJQcBy20VCW_1d6FPkMG_o4OnH_z5GpEio-LvSqfJk=.8c300a68-6295-411e-94a2-7b7188d3cafd@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

A possible more generic api doc:


    /**
     * Returns the CPU time used by garbage collection.
     *
     * <p> This is the CPU time used by all garbage collection activity, 
	 * including any overhead, which means the result may be non-zero 
	 * even if no GC has occurred. 
	 *
	 * This method may return {@code -1} if the
     * platform does not support this operation or the information is not available at any time.
	 *
     * @implNote Reported time will include relevant implementation-specific details such as
	 * driver threads, workers, VM Operations and string deduplication (if enabled). 
	 * This method will return -1 if called during shutdown.
     *
	 * @return the total accumulated CPU time for garbage collection
     * in nanoseconds, or -1
     * 
     * @since 26
     */
	 public long getTotalGcCpuTime();

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3405609355

From kevinw at openjdk.org  Wed Oct 15 10:17:35 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 15 Oct 2025 10:17:35 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
Message-ID: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>

On Sun, 5 Oct 2025 13:00:44 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move from j.l.management to com.sun.management etc.

Or:


     * @implNote Time calculation is implementation-specific, and may include details
	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3405648131

From duke at openjdk.org  Mon Oct 20 17:37:44 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:37:44 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v3]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <EBxwdE3akdiEKYckVZGX-VLdDBeGHkFYzvNkye4_XQw=.3fbaa8dc-3fde-423f-999c-ff2a15ede3c1@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with two additional commits since the last revision:

 - j.l.management with generic API docs
 - Revert "Move from j.l.management to com.sun.management etc."
   
   This reverts commit 6431310109a02ec5c34f877a1c690afb00193043.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/64313101..b03db63e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=01-02

  Stats: 186 lines in 11 files changed: 35 ins; 143 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Mon Oct 20 17:44:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:44:05 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v4]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <CdFU-mIZLpsyvo6OYlS8zoLHsZFcneghwBRJ7HhdniE=.636452d0-bcc8-414b-80f4-0ed381feabf7@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Remove tabs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/b03db63e..8d83dd97

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=02-03

  Stats: 5 lines in 1 file changed: 0 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Mon Oct 20 17:50:05 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Mon, 20 Oct 2025 17:50:05 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
Message-ID: <qg1Bn8Hwxdd_QQHbIeOzZPZijQUXI9vLX9Vl4mZBY8k=.4f536c8a-66ee-443a-8ff9-34a023708365@github.com>

On Wed, 15 Oct 2025 10:14:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move from j.l.management to com.sun.management etc.
>
> Or:
> 
> 
>      * @implNote Time calculation is implementation-specific, and may include details
> 	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
> 	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

Thanks for the suggested API docs @kevinjwalls! I pushed a proposal to use j.l.management, with the proposed generic API docs.

I dropped "may" and "any" from the paragraph about `-1` return value from @kevinjwalls original suggestion:

     * This method return {@code -1} if the platform does
     * not support this operation or the information is not
     * available.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3423134361

From duke at openjdk.org  Wed Oct 22 11:28:34 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 22 Oct 2025 11:28:34 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v5]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/8d83dd97..a188df0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Wed Oct 22 16:11:53 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 22 Oct 2025 16:11:53 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v2]
In-Reply-To: <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <zwCm9yLEZJ6wPeV-O6hzHSF9hl30IzMf-KNnim4iJm4=.b7d00b9a-b394-414a-afd6-5d010f422c57@github.com>
 <z-MZgwyMp0MIel9mYMDQF9nysM9VGPKGb-Ca9qsYoRc=.17b20e85-ee71-4da1-aa42-0bf1d3c919b5@github.com>
Message-ID: <1mJDNP4BPxU6lH_5D0Z7V_zssJMjfzT9VCC42c89r1Y=.dcc53858-9d25-475c-937c-1f7f3f956234@github.com>

On Wed, 15 Oct 2025 10:14:21 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Move from j.l.management to com.sun.management etc.
>
> Or:
> 
> 
>      * @implNote Time calculation is implementation-specific, and may include details
> 	 * such as CPU time for driver threads, workers, VM Operations and string deduplication. 
> 	 * The return value can be -1 if called when measurement is not possible, such as during shutdown.

@kevinjwalls 

> Particularly on this method about GC time, I don't really follow the reasoning for not accepting the method in java.lang.MemoryMXBean.
>
> The most generic Java API can admit that Java is Garbage-Collected, and that doing that work can take some CPU time.

I think I'm leaning towards jdk.lang/com.sun over java.lang since there are GC algorithms out there (which we don't have in HotSpot), that make this method sometimes less useful. A method in java.lang may need to consider the most generic situation. For instance, GCs that pushes out most of its work onto mutators. It may be hard to accurately measure this at mutator level and we don't want to force JDK implementors to do so. As such this should be categorized as a JDK-specific method. I understand we would prefer jdk.lang over com.sun for new additions?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3433172604

From alanb at openjdk.org  Thu Oct 23 11:29:11 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 23 Oct 2025 11:29:11 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v5]
In-Reply-To: <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BVAkU59FpdgRCxMMmwlP5irbf6zW_VMeSDi8fbEBtLE=.407b6ce5-4adb-465e-8755-cf63b3e1094f@github.com>
Message-ID: <wVDMkRhswMMdZj8pTn01HWxdYNsYZgKTEhnGjxikL5A=.70eb9e23-59d2-4585-8bdc-4cc7c683f0d9@github.com>

On Wed, 22 Oct 2025 11:28:34 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix typo

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 271:

> 269: 
> 270:     /**
> 271:      * Returns the CPU time used by garbage collection.

The latest wording is much better. For the first sentence, you might to consider expanding is a bit to something like "Returns the approximate accumulated time, in nanoseconds, spent in garbage collection."

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 285:

> 283:      * workers, VM Operations and string deduplication (if enabled).
> 284:      * The return value can be -1 if called when measurement is
> 285:      * not possible, such as during shutdown.

For the implNote then I think you are looking to say something HotSpot VM specific. That is possible with something like:  The specifics on what constitutes the time spent in garbage collection is highly implementation dependent. In the HotSpot Virtual Machine implementation, ... 

(If you are using the term "driver threads" then you will probably need to say more on what it means).

It is still the intention to use this in conjunction with OperatingSystemMXBean:: getProcessCpuTime ? If so, this could also be included here, or in an API note.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2454746445
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2454797793

From duke at openjdk.org  Fri Oct 24 12:19:52 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 12:19:52 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v6]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <zPwIZTo2vL1vSn_JuUqmxRCcC0KqvRpnwQdbz0JweDQ=.b98781e8-de09-4d2b-b81b-5fc36a8d4949@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Add default implementation and elaborate API docs

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/a188df0b..f8a9f7a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=04-05

  Stats: 20 lines in 1 file changed: 12 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Fri Oct 24 12:37:02 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 12:37:02 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v7]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix link for getProcessCpuTime

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/f8a9f7a3..08af7b51

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=05-06

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From alanb at openjdk.org  Fri Oct 24 15:32:33 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 24 Oct 2025 15:32:33 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v7]
In-Reply-To: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
Message-ID: <ZMiU3uHab3Jhk8YAuMkt2ukJpDzyo4xpkvfFUtduKEA=.45ea1821-d663-4dae-8139-682960aeb4a7@github.com>

On Fri, 24 Oct 2025 12:37:02 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link for getProcessCpuTime

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 274:

> 272:      * spent in garbage collection.
> 273:      *
> 274:      * <p> This is the CPU time used by all garbage collection

Starting this paragraph with "This is the CPU time ..." is a bit awkward. Can you try "The time spent in spent in garbage collection (GC) is the CPU time ...".

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 289:

> 287:      * in garbage collection is highly implementation dependent.
> 288:      * In the HotSpot Virtual Machine implementation reported
> 289:      * time will include relevant implementation-specific details such

"In the HotSpot Virtual Machine implementation reported time will include".  A suggestion to improve this is to change it to "In the HotSpot Virtual Machine, this time includes.."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2461014442
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2461027518

From duke at openjdk.org  Fri Oct 24 18:27:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 18:27:47 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v8]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Review fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/08af7b51..5d360f45

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=06-07

  Stats: 14 lines in 1 file changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Fri Oct 24 18:27:47 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Fri, 24 Oct 2025 18:27:47 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v7]
In-Reply-To: <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <BBWDllzYKsXxq1vMEiBw314DeHEpwCpyD0j6Udy0fKI=.53a7631b-9e13-40cf-9b24-e1c1146f2384@github.com>
Message-ID: <tmLI6jE_Wa1z0p5h5CYHSoOA1So-SR0Q4A6vD2n3Tvk=.e3d1e614-9d7f-42d7-9f89-9c55d3cc016f@github.com>

On Fri, 24 Oct 2025 12:37:02 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix link for getProcessCpuTime

Thanks for the feedback. I addressed the above and ensured consistent usage of GC throughout.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3444369903

From alanb at openjdk.org  Sun Oct 26 14:20:09 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 Oct 2025 14:20:09 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v8]
In-Reply-To: <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
Message-ID: <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>

On Fri, 24 Oct 2025 18:27:47 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review fixes

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 300:

> 298:      * nanoseconds, or {@code -1}.
> 299:      *
> 300:      * @since 26

The latest API docs is good, thanks for accepting all the comments/suggestions to get this right.

src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 305:

> 303:     default public long getTotalGcCpuTime() {
> 304:         return -1;
> 305:     };

No need for the semicolon after the closing brace. No need for `public` modifier either but okay to leave it as event the abstract methods in this interface have it, even if not explicitly needed as they are public anyway.

test/jdk/java/lang/management/MemoryMXBean/GetTotalGcCpuTime.java line 44:

> 42: import java.lang.management.ThreadMXBean;
> 43: 
> 44: public class GetTotalGcCpuTime {

This test will need re-work.

What is the reason for launching a sub-process? The child process starts 4 * ncores threads, the main thread in the child process then exits with status 0. It would be a lot simpler to have a single VM and verify that the GC time increases monotonically when there are busy mutators and/or explicit GC.

The API is designed to work in conjunction with OperatingSystemMXBean.getProcessCpuTime so you can test them together to ensure that GC cpu time is <= process cpu time.

The test can implement MemoryPoolMXBean, just the abstract methods, so you can test the default method.

Look at other tests to see how `@requires` is used in test selection, e.g. tests that uses -XX:+UseZGC will have `@requires vm.gc.Z` in the test description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463840541
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463839299
PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463846623

From duke at openjdk.org  Sun Oct 26 15:13:04 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 26 Oct 2025 15:13:04 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v8]
In-Reply-To: <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
 <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
Message-ID: <tpeUYz__7DhR5V9clMYBZVYjhLaG2S6ZZ3TEQM8cS1A=.72649b8e-9a66-400a-8b0b-1f0922513e33@github.com>

On Sun, 26 Oct 2025 14:17:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> This test will need re-work.

The end-goal of this test was to verify that the implementation correctly guarded against races during shutdown which it manged to test. So to that end I'm not sure this particular test needs re-work as it correctly manages to run Java code that races on this method during VM shutdown. However, if I understand your comment you are suggesting that we should (1) simplify how the test is invoked (2) add a test for checking that the value is monotonically increasing. For the latter I did not add such test as we in the end rely on`os::thread_cpu_time`.

> `GC cpu time is <= process cpu time`

I think we are at the mercy of how well the underlying OS update thread CPU time. I know that for extremely short-lived processes, the accounting for CPU time may be less reliable at least on Linux. In general, can Hotspot make any guarantee about CPU time for threads vs process CPU time?

> What is the reason for launching a sub-process? 

I looked at other tests how they launched tests for different GCs and that's the way I found to achieve that. If `@requires` is another way and is the preferred one I can change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463870835

From duke at openjdk.org  Sun Oct 26 15:16:07 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Sun, 26 Oct 2025 15:16:07 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v8]
In-Reply-To: <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
 <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
Message-ID: <CK-KQu0jjq-iTraiBmkVErHC2_AUvXZjjNSSKUJXT_M=.daf81ebe-6d0a-4e0a-933d-01159b795d0d@github.com>

On Sun, 26 Oct 2025 14:05:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review fixes
>
> src/java.management/share/classes/java/lang/management/MemoryMXBean.java line 300:
> 
>> 298:      * nanoseconds, or {@code -1}.
>> 299:      *
>> 300:      * @since 26
> 
> The latest API docs is good, thanks for accepting all the comments/suggestions to get this right.

I should say thank you all for the attention to detail :-) The API docs is indeed much better than the original suggestion.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463872264

From alanb at openjdk.org  Sun Oct 26 15:45:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 26 Oct 2025 15:45:04 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v8]
In-Reply-To: <tpeUYz__7DhR5V9clMYBZVYjhLaG2S6ZZ3TEQM8cS1A=.72649b8e-9a66-400a-8b0b-1f0922513e33@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <70OjWJ0iNWEzzSq4ZFLNNgEQon4D2sKNPsaYB4iiSj8=.455b3132-3b71-4ec3-89d9-bd93d6ef55a7@github.com>
 <Fr3jtOiyuaBSrbZWD7yVnKB-EN3eQ15vbXqFdq-c3XY=.06ff4be5-d21b-47a6-bca0-636436cac54d@github.com>
 <tpeUYz__7DhR5V9clMYBZVYjhLaG2S6ZZ3TEQM8cS1A=.72649b8e-9a66-400a-8b0b-1f0922513e33@github.com>
Message-ID: <nkpELhUfCwbqMVEoQ4F19RiFXw9qRAvWudeLsiQC7co=.7cd857e1-b65e-4531-b567-b9312a3aa02e@github.com>

On Sun, 26 Oct 2025 15:10:36 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

> The end-goal of this test was to verify that the implementation correctly guarded against races during shutdown which it manged to test. So to that end I'm not sure this particular test needs re-work as it correctly manages to run Java code that races on this method during VM shutdown. However, if I understand your comment you are suggesting that we should (1) simplify how the test is invoked (2) add a test for checking that the value is monotonically increasing. For the latter I did not add such test as we in the end rely on`os::thread_cpu_time`.

It would be good to create unit test for the API/feature. Future maintainers will thank you. The test in the PR is focused on the shutdown scenario and be renamed to reflect that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27537#discussion_r2463885768

From macarte at openjdk.org  Tue Oct 28 01:26:37 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 28 Oct 2025 01:26:37 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
Message-ID: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>

Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.

The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE

It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:

TRUE
FALSE

Passes tier1 on linux (x64) and windows (x64)

-------------

Depends on: https://git.openjdk.org/jdk/pull/27965

Commit messages:
 - Removed whitespace
 - Removed extra functionality
 - 8369736 - Adding HotSpotAOTCache MXBean

Changes: https://git.openjdk.org/jdk/pull/28010/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8369736
  Stats: 341 lines in 9 files changed: 338 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/28010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010

PR: https://git.openjdk.org/jdk/pull/28010

From alanb at openjdk.org  Tue Oct 28 09:55:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 09:55:15 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>

On Tue, 28 Oct 2025 01:17:57 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 107:

> 105:        *
> 106:        * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise.
> 107:        */

There are issues in the javadoc that will cause the docs target to fail, e.g. mismatched blockquote.  Can you fix these up so that we can generate the docs from the changes in the PR?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2468788614

From alanb at openjdk.org  Tue Oct 28 10:23:08 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 10:23:08 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <n6hngN3iwNPiTMlkWWk1CIHxruPxzaS1sEe_PYwrbQY=.a6ef8cb0-1602-4b33-8545-4df6880d3a87@github.com>

On Tue, 28 Oct 2025 01:17:57 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 29:

> 27: import java.lang.management.ManagementFactory;
> 28: import java.lang.management.PlatformManagedObject;
> 29: import java.util.concurrent.ForkJoinPool;

I assume there is no need to import ForkJoinPool.

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 36:

> 34:  * Management interface for the JDK's Ahead of Time (AOT) optimizations.
> 35:  *
> 36:  * Currently, {@code HotSpotAOTCacheMXBean} defines one operation at this time to end the AOT recording.

I think you drop "Currently, ", it will be a bit clearer without it.

test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 98:

> 96:     public static void main(String[] args) {
> 97:         System.out.println("Hello Leyden " + args[0]);
> 98:         var aotBean = ManagementFactory.getPlatformMXBean(HotSpotAOTCacheMXBean.class);

This uses MF.getPlatformMXBean in the child VM. A more complete test would repeat with:

        MBeanServer server = ManagementFactory.getPlatformMBeanServer();
        HotSpotAOTCacheMXBean bean = ManagementFactory.newPlatformMXBeanProxy(server,
                "jdk.management:type=HotSpotAOTCacheMXBean",
                HotSpotAOTCacheMXBean.class);


In any case, it might be simpler to test that the MXBean is registered in the test itself, it doesn't need to be in the child VM.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2468799292
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2468801255
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2468824691

From duke at openjdk.org  Tue Oct 28 12:53:59 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Tue, 28 Oct 2025 12:53:59 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v9]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <yet6NxQ9QA5r8KaRZdAm0jvwMCEj6oEgGoYMXsxVgXQ=.99e938f3-de87-4ac9-808d-0e9a8b1f00bf@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with three additional commits since the last revision:

 - Also stress-test Serial and Epsilon
 - Add basic test for MemoryMXBean.getTotalGcCpuTime
 - Change how test is invoked and fix review comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/5d360f45..f395e8d2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=07-08

  Stats: 308 lines in 4 files changed: 224 ins; 83 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From mdonovan at openjdk.org  Tue Oct 28 13:45:36 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 13:45:36 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <Fh8T3z8h0nSIy9d-KuCmNw277ReGv3tatAEFSdk5OGY=.a1364cb2-5e4b-432c-95a5-07e6472f1c3a@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

I'm still looking for a reviewer for this PR. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3456540544

From abarashev at openjdk.org  Tue Oct 28 13:57:48 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 13:57:48 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <PbS8cZVmSo5vuXgmIR6s-oIV3GC4CgDrM2-bMYKdLS0=.d0d683b9-27d2-417a-b101-bb3fe96244ca@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 100:

> 98:                         getServerDname(),
> 99:                         serverKeys.getPublic(), caKeys.getPublic(),
> 100:                         CertificateBuilder.KeyUsage.DIGITAL_SIGNATURE, CertificateBuilder.KeyUsage.NONREPUDIATION, CertificateBuilder.KeyUsage.KEY_ENCIPHERMENT)

Line length > 80 here and below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469675945

From abarashev at openjdk.org  Tue Oct 28 14:04:19 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 14:04:19 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

What about `javax/management/security/SecurityTest.java` unit test mentioned in the ticket?

test/jdk/javax/management/security/keystoreAgent line 1:

> 1: 0?

Why do we need this and other binary key stores if we generate certificates on the fly?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27342#issuecomment-3456634618
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469688660

From heidinga at openjdk.org  Tue Oct 28 14:37:45 2025
From: heidinga at openjdk.org (Dan Heidinga)
Date: Tue, 28 Oct 2025 14:37:45 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <M194dpZisEszV0lI8BHNNrihlDWm-FYY2418xbyQhlk=.275340ea-1f02-4e9f-9613-32b6868c5e1b@github.com>

On Tue, 28 Oct 2025 01:17:57 GMT, Mat Carter <macarte at openjdk.org> wrote:

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 34:

> 32: 
> 33: /**
> 34:  * Management interface for the JDK's Ahead of Time (AOT) optimizations.

I don't like the word "optimizations" here but don't have a better one.  Maybe "operation"?  Still not great

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 54:

> 52:        *
> 53:        * <p>The JVM will start recording AOT artifacts upon start-up if certain JVM options are
> 54:        *  given in the command-line. The recording will stop when the JVM exits, or when

Suggestion:

       *  supplied on the command-line. The recording will stop when the JVM exits, or when

src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 61:

> 59:        * <blockquote>
> 60:        *       The JVM will record optimization information about the current application
> 61:        *       into the AOT cache file app.aot. In a future execution of this application,

We don't strictly generate the info into `app.aot` - we record it and then do an assembly phase (either implicitly with AOTCacheOutput or explicitly with AOTMode=) to generate the cache:
Suggestion:

       *       The JVM will record optimization information about the current application
       *       that will be used to generate the AOT cache file app.aot. In a future execution of this application,

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2469810111
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2469813837
PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2469821133

From abarashev at openjdk.org  Tue Oct 28 14:34:34 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 14:34:34 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <Knhrf0qPwT11jA-3ssyRE-BvAP7VmfABoIpxpolXt88=.c7ca5ca9-ca2d-4f1b-8fbe-3738458fc11b@github.com>

On Wed, 17 Sep 2025 11:50:51 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 42:

> 40: 
> 41: /*
> 42:  * @test id=tls13

What's the reason for having 2 separate `@test id=tls12` and `@test id=tls13` JTREG instructions blocks?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2469814283

From adinn at openjdk.org  Tue Oct 28 16:18:19 2025
From: adinn at openjdk.org (Andrew Dinn)
Date: Tue, 28 Oct 2025 16:18:19 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
In-Reply-To: <M194dpZisEszV0lI8BHNNrihlDWm-FYY2418xbyQhlk=.275340ea-1f02-4e9f-9613-32b6868c5e1b@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <M194dpZisEszV0lI8BHNNrihlDWm-FYY2418xbyQhlk=.275340ea-1f02-4e9f-9613-32b6868c5e1b@github.com>
Message-ID: <8crR7rnvITcZT6XU_hedbk-bC8-BIYLXUyQsyptuKLc=.700f232c-bcc9-48b7-b89d-4888c86aff9d@github.com>

On Tue, 28 Oct 2025 14:30:42 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 34:
> 
>> 32: 
>> 33: /**
>> 34:  * Management interface for the JDK's Ahead of Time (AOT) optimizations.
> 
> I don't like the word "optimizations" here but don't have a better one.  Maybe "operation"?  Still not great

Well, one possible alternative is kind of implicit in the bean name:

  "Management interface for the JDK's Ahead of Time (AOT) Cache"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2470201352

From mdonovan at openjdk.org  Tue Oct 28 17:43:12 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 17:43:12 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v2]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <SreGhzKi-QWLcx0uQ1Z6yGUd0UAaJUswOlh4J1cm9Ns=.a860d13d-5f32-41df-bb77-8ab3fde048a9@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - fixed indents and copyright year
 - Merge branch 'master' into update-md5-certs
 - 8353738: Update TLS unit tests to not use certificates with MD5 signatures

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/affe0fc9..a1933313

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=00-01

  Stats: 213159 lines in 2786 files changed: 164071 ins; 31722 del; 17366 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

PR: https://git.openjdk.org/jdk/pull/27342

From mdonovan at openjdk.org  Tue Oct 28 17:43:16 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Tue, 28 Oct 2025 17:43:16 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v2]
In-Reply-To: <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>
Message-ID: <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com>

On Tue, 28 Oct 2025 13:58:44 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - fixed indents and copyright year
>>  - Merge branch 'master' into update-md5-certs
>>  - 8353738: Update TLS unit tests to not use certificates with MD5 signatures
>
> test/jdk/javax/management/security/keystoreAgent line 1:
> 
>> 1: 0?
> 
> Why do we need this and other binary key stores if we generate certificates on the fly?

This is related to your question about SecurityTest.java. 

SecurityTest.java has about 24 different @run instructions with different flags for each. Setting up keys and certificates programmatically looked like it would make the code more complicated and keeping the binary files seemed like the lesser of two evils.

> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 42:
> 
>> 40: 
>> 41: /*
>> 42:  * @test id=tls13
> 
> What's the reason for having 2 separate `@test id=tls12` and `@test id=tls13` JTREG instructions blocks?

I think it helps with organization and troubleshooting tests. Without it, you have to read fairly dense logs to see which @run command failed. With separate @test blocks, it's more obvious.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470468093
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470461925

From macarte at openjdk.org  Tue Oct 28 17:56:28 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 28 Oct 2025 17:56:28 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
In-Reply-To: <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
Message-ID: <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>

On Tue, 28 Oct 2025 09:51:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
>> 
>> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
>> 
>> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
>> 
>> TRUE
>> FALSE
>> 
>> Passes tier1 on linux (x64) and windows (x64)
>
> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 107:
> 
>> 105:        *
>> 106:        * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise.
>> 107:        */
> 
> There are issues in the javadoc that will cause the docs target to fail, e.g. mismatched blockquote.  Can you fix these up so that we can generate the docs from the changes in the PR?

Is there an easy way to test the correctness of the javadoc parts (I couldn't find an option for javadoc).  The </blockquote \>above is matched to a <blockquote\> on line 88, but there is a <pre\></pre\> pair in between, is that the issue you are referring to?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2470535787

From alanb at openjdk.org  Tue Oct 28 17:59:35 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 28 Oct 2025 17:59:35 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
In-Reply-To: <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
 <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>
Message-ID: <sy9UKQQZLzQzlExQXDPWBhAp1NMTE0tT1MpR2tZxfq8=.196df4d7-efc2-44f2-bfc6-ee7457bbb08e@github.com>

On Tue, 28 Oct 2025 17:53:31 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java line 107:
>> 
>>> 105:        *
>>> 106:        * @return {@code true} if a recording was in progress and has been ended successfully; {@code false} otherwise.
>>> 107:        */
>> 
>> There are issues in the javadoc that will cause the docs target to fail, e.g. mismatched blockquote.  Can you fix these up so that we can generate the docs from the changes in the PR?
>
> Is there an easy way to test the correctness of the javadoc parts (I couldn't find an option for javadoc).  The </blockquote \>above is matched to a <blockquote\> on line 88, but there is a <pre\></pre\> pair in between, is that the issue you are referring to?

`make docs`.  The second blockquote is matched with another blockquote, not `</blockquote>`. In the example, which can be converted to a snippet, then then braces not matched so the end brace for `{@code ... }` get mixed up.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2470543888

From abarashev at openjdk.org  Tue Oct 28 18:40:26 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Tue, 28 Oct 2025 18:40:26 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v2]
In-Reply-To: <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <qc56pPUfOmwW6R26o7kQoyJRxJ88RdxDjwZLfyiR4Yw=.f48b61db-fca4-4e52-8bb8-565e2a498055@github.com>
 <6ZbsYB6U-1wWQ-Zhp6F-6tjCNxnPS27vUIEKjdzunXc=.5ca48952-3f96-4239-9b2a-b426709542be@github.com>
Message-ID: <XzJpBFzVgu2ZhiThl6hjlOaux2Zst5dTATTLMqt6XAc=.56f7ea86-97b5-438b-8ebf-49ccbe899491@github.com>

On Tue, 28 Oct 2025 17:39:56 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/jdk/javax/management/security/keystoreAgent line 1:
>> 
>>> 1: 0?
>> 
>> Why do we need this and other binary key stores if we generate certificates on the fly?
>
> This is related to your question about SecurityTest.java. 
> 
> SecurityTest.java has about 24 different @run instructions with different flags for each. Setting up keys and certificates programmatically looked like it would make the code more complicated and keeping the binary files seemed like the lesser of two evils.

Oh, I see, it's a specific JMX test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2470662409

From macarte at openjdk.org  Tue Oct 28 18:55:02 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 28 Oct 2025 18:55:02 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation
In-Reply-To: <sy9UKQQZLzQzlExQXDPWBhAp1NMTE0tT1MpR2tZxfq8=.196df4d7-efc2-44f2-bfc6-ee7457bbb08e@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
 <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>
 <sy9UKQQZLzQzlExQXDPWBhAp1NMTE0tT1MpR2tZxfq8=.196df4d7-efc2-44f2-bfc6-ee7457bbb08e@github.com>
Message-ID: <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com>

On Tue, 28 Oct 2025 17:56:49 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Is there an easy way to test the correctness of the javadoc parts (I couldn't find an option for javadoc).  The </blockquote \>above is matched to a <blockquote\> on line 88, but there is a <pre\></pre\> pair in between, is that the issue you are referring to?
>
> `make docs`.  The second blockquote is matched with another blockquote, not `</blockquote>`. In the example, which can be converted to a snippet, then then braces not matched so the end brace for `{@code ... }` get mixed up.

I see that now - fixing ....

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2470709024

From macarte at openjdk.org  Tue Oct 28 19:00:40 2025
From: macarte at openjdk.org (Mat Carter)
Date: Tue, 28 Oct 2025 19:00:40 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v2]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <FH4roNJ40MkI1NU-AGeJe0Fv4TXj5Lw-x_y5mR82ZHk=.ffc04b27-bc85-439b-b0ad-8dfcddba5d4b@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with two additional commits since the last revision:

 - Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java
   
   Co-authored-by: Dan Heidinga <dan.heidinga at oracle.com>
 - Update src/jdk.management/share/classes/jdk/management/HotSpotAOTCacheMXBean.java
   
   Co-authored-by: Dan Heidinga <dan.heidinga at oracle.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/d58c5147..2285a683

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/28010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010

PR: https://git.openjdk.org/jdk/pull/28010

From lmesnik at openjdk.org  Tue Oct 28 23:38:41 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Tue, 28 Oct 2025 23:38:41 GMT
Subject: jmx-dev RFR: 8370851: Mark hotspot and jdk tests incompatible with
 test thread factory
Message-ID: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>

There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag.

Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads.

The tests that are incompatible with test thread factory are marked with
test.thread.factory == null
and the tests that are rather incompatible with virtual threads are makred
with
test.thread.factory != "Virtual"

-------------

Commit messages:
 - 8370851: Mark hotspot and jdk tests incompatible with test thread factory

Changes: https://git.openjdk.org/jdk/pull/28030/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8370851
  Stats: 32 lines in 14 files changed: 17 ins; 1 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/28030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030

PR: https://git.openjdk.org/jdk/pull/28030

From abarashev at openjdk.org  Wed Oct 29 02:00:06 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Wed, 29 Oct 2025 02:00:06 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v2]
In-Reply-To: <SreGhzKi-QWLcx0uQ1Z6yGUd0UAaJUswOlh4J1cm9Ns=.a860d13d-5f32-41df-bb77-8ab3fde048a9@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <SreGhzKi-QWLcx0uQ1Z6yGUd0UAaJUswOlh4J1cm9Ns=.a860d13d-5f32-41df-bb77-8ab3fde048a9@github.com>
Message-ID: <_Uj-IKCUyXk183vz3D8_3dfUKA8NwrFxm5dRGbsgmfQ=.25bcae37-6622-4ce6-86f5-54abd430f312@github.com>

On Tue, 28 Oct 2025 17:43:12 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - fixed indents and copyright year
>  - Merge branch 'master' into update-md5-certs
>  - 8353738: Update TLS unit tests to not use certificates with MD5 signatures

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 222:

> 220:                     "MD2, RSA keySize < 1024");
> 221:             Security.setProperty("jdk.tls.disabledAlgorithms",
> 222:                     "SSLv3, RC4, DH keySize < 768");

I think we should remove only `MD5`, here and in all other tests:

            // If MD5 is used in this test case, don't disable MD5 algorithm.
            SecurityUtils.removeFromDisabledTlsAlgs("MD5");
            SecurityUtils.removeFromDisabledAlgs(
                          "jdk.certpath.disabledAlgorithms", List.of("MD5"));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2471528938

From alanb at openjdk.org  Wed Oct 29 07:00:04 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 29 Oct 2025 07:00:04 GMT
Subject: jmx-dev RFR: 8370851: Mark hotspot and jdk tests incompatible
 with test thread factory
In-Reply-To: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
References: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
Message-ID: <KEqEP1jBizmwYEkfXhki9qBYcH6_ucnxmIZASBXUq00=.fbeae96b-9b38-440a-9d67-31a87aad63a6@github.com>

On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag.
> 
> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads.
> 
> The tests that are incompatible with test thread factory are marked with
> test.thread.factory == null
> and the tests that are rather incompatible with virtual threads are makred
> with
> test.thread.factory != "Virtual"

test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28:

> 26:  * @bug 8284161 8303242
> 27:  * @summary Test com.sun.management.ThreadMXBean with virtual threads
> 28:  * @requires test.thread.factory != "Virtual"

This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2471923090

From mdonovan at openjdk.org  Wed Oct 29 11:57:45 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Wed, 29 Oct 2025 11:57:45 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v3]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  changed tests to use SecurityUtils.removeDisabled*Algs methods

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/a1933313..4804c90d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=01-02

  Stats: 35 lines in 5 files changed: 10 ins; 8 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

PR: https://git.openjdk.org/jdk/pull/27342

From phh at openjdk.org  Wed Oct 29 16:56:08 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Wed, 29 Oct 2025 16:56:08 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v9]
In-Reply-To: <yet6NxQ9QA5r8KaRZdAm0jvwMCEj6oEgGoYMXsxVgXQ=.99e938f3-de87-4ac9-808d-0e9a8b1f00bf@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <yet6NxQ9QA5r8KaRZdAm0jvwMCEj6oEgGoYMXsxVgXQ=.99e938f3-de87-4ac9-808d-0e9a8b1f00bf@github.com>
Message-ID: <eofJ0rlWmsV34z4OGk0j5flx_JbLf9ehjhs1UX3qNLA=.0ce5d121-7049-4a8f-aa4d-e7195cd505fa@github.com>

On Tue, 28 Oct 2025 12:53:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also stress-test Serial and Epsilon
>  - Add basic test for MemoryMXBean.getTotalGcCpuTime
>  - Change how test is invoked and fix review comment

Couple of grammar nits in the getTotalGcCpuTime javadoc.

"in GC is highly implementation" => "in GC are highly implementation"

"The default implementation return {@code -1}" => "The default implementation returns {@code -1}"

-------------

PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3394838128

From duke at openjdk.org  Wed Oct 29 18:08:31 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 29 Oct 2025 18:08:31 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v10]
In-Reply-To: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
Message-ID: <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>

> Hi all,
> 
> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
> 
> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
> 
> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
> 
> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.

Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:

  Fix phohensee review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27537/files
  - new: https://git.openjdk.org/jdk/pull/27537/files/f395e8d2..44f5d864

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27537&range=08-09

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/27537.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27537/head:pull/27537

PR: https://git.openjdk.org/jdk/pull/27537

From duke at openjdk.org  Wed Oct 29 18:08:33 2025
From: duke at openjdk.org (Jonas Norlinder)
Date: Wed, 29 Oct 2025 18:08:33 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v9]
In-Reply-To: <yet6NxQ9QA5r8KaRZdAm0jvwMCEj6oEgGoYMXsxVgXQ=.99e938f3-de87-4ac9-808d-0e9a8b1f00bf@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <yet6NxQ9QA5r8KaRZdAm0jvwMCEj6oEgGoYMXsxVgXQ=.99e938f3-de87-4ac9-808d-0e9a8b1f00bf@github.com>
Message-ID: <YWrRZ9LWXuxFpgxKTXF-Yl5PIUe4fBXVpuhJ0LjlDCQ=.3bc4f0c2-f9ea-4c07-9422-cd439616be64@github.com>

On Tue, 28 Oct 2025 12:53:59 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Also stress-test Serial and Epsilon
>  - Add basic test for MemoryMXBean.getTotalGcCpuTime
>  - Change how test is invoked and fix review comment

Thanks for the review Paul. I pushed fixes reflecting your suggestions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3462916819

From macarte at openjdk.org  Wed Oct 29 18:51:45 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 29 Oct 2025 18:51:45 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v3]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <sihwtwl__4yHes7nY_57oGm8wupwW4UZ9pAieeLR3MQ=.c679a95e-55e4-4d2c-9e4c-83cc450fae62@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch 'JDK-8369736' of https://github.com/macarte/jdk into JDK-8369736
 - Wording and format changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/2285a683..abd6b0dd

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=01-02

  Stats: 7 lines in 1 file changed: 0 ins; 2 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/28010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010

PR: https://git.openjdk.org/jdk/pull/28010

From macarte at openjdk.org  Wed Oct 29 18:51:46 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 29 Oct 2025 18:51:46 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v3]
In-Reply-To: <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <Xc1cdsxJ2138ed1wpIouj0qlZrwfccgnJCnLPVS-M6c=.23b7534c-81ac-46d3-860c-d7d2d29c886a@github.com>
 <RCXK7yUbGaKrSm4yu-bo82y_cGbGnaK1AsxTCknP8fg=.efba2b02-cbf1-4200-9f8b-2e43b1f2bb4b@github.com>
 <sy9UKQQZLzQzlExQXDPWBhAp1NMTE0tT1MpR2tZxfq8=.196df4d7-efc2-44f2-bfc6-ee7457bbb08e@github.com>
 <3DZMFG5pUixBip4O18gylfQpcCOTFxcwwVTWahRMBYo=.c9cb089e-6031-4b77-bb4a-775ed6cac818@github.com>
Message-ID: <FvFvVFAL10Z13NMzVOWICfdAriP3g_FDASS1sjt6pIs=.f31d3133-8dfa-492f-ab04-377b2182489a@github.com>

On Tue, 28 Oct 2025 18:52:29 GMT, Mat Carter <macarte at openjdk.org> wrote:

>> `make docs`.  The second blockquote is matched with another blockquote, not `</blockquote>`. In the example, which can be converted to a snippet, then then braces not matched so the end brace for `{@code ... }` get mixed up.
>
> I see that now - fixing ....

I also removed the nested {@code ..} from within the <pre></pre> as that also caused an issue

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2474756884

From macarte at openjdk.org  Wed Oct 29 21:07:51 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 29 Oct 2025 21:07:51 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v4]
In-Reply-To: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
Message-ID: <dxHQuPISb6D86Ptd-vnIU_zjVDRCTZhIdM5mNKPzEIQ=.4908b214-cb5f-43dc-af09-fc9eed7b55c5@github.com>

> Add jdk.management.AOTCacheMXBean. The interface provides a single action that when called will cause any hosted JVM currently recording AOT information will stop recording. Existing functionality is preserved: when stopped the JVM will create the required artifacts based on the execution mode. Conveniently as the application running on the JVM has not stopped (as was previously the only way to stop recording), the application will resume execution after the artifacts have been generated.
> 
> The interface will return TRUE if a recording was successfully stopped, in all other cases (not recording etc.) will return FALSE
> 
> It follows that invoking the action on a JVM that is recording, twice in succession, should (baring internal errors) produce the following two responses:
> 
> TRUE
> FALSE
> 
> Passes tier1 on linux (x64) and windows (x64)

Mat Carter has updated the pull request incrementally with one additional commit since the last revision:

  Updated test based on comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28010/files
  - new: https://git.openjdk.org/jdk/pull/28010/files/abd6b0dd..d48a200f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28010&range=02-03

  Stats: 23 lines in 1 file changed: 12 ins; 2 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/28010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28010/head:pull/28010

PR: https://git.openjdk.org/jdk/pull/28010

From macarte at openjdk.org  Wed Oct 29 21:07:53 2025
From: macarte at openjdk.org (Mat Carter)
Date: Wed, 29 Oct 2025 21:07:53 GMT
Subject: jmx-dev RFR: 8369736 - Add management interface for AOT cache
 creation [v4]
In-Reply-To: <n6hngN3iwNPiTMlkWWk1CIHxruPxzaS1sEe_PYwrbQY=.a6ef8cb0-1602-4b33-8545-4df6880d3a87@github.com>
References: <bzP4ObqFsRvYImfmZ3Fy0O8D73YoPAOmgNPonIP3Zn4=.8be50dea-578a-44ed-909e-5a186367985f@github.com>
 <n6hngN3iwNPiTMlkWWk1CIHxruPxzaS1sEe_PYwrbQY=.a6ef8cb0-1602-4b33-8545-4df6880d3a87@github.com>
Message-ID: <MPSSbLUQApNUpNO1lhqazYGCLRwXslNgj5f5yn_WWjQ=.6ffc1fd2-7590-4ddf-9a87-7576d6bc085b@github.com>

On Tue, 28 Oct 2025 10:01:14 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Mat Carter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updated test based on comments
>
> test/hotspot/jtreg/runtime/cds/appcds/aotCache/HotSpotAOTCacheMXBeanTest.java line 98:
> 
>> 96:     public static void main(String[] args) {
>> 97:         System.out.println("Hello Leyden " + args[0]);
>> 98:         var aotBean = ManagementFactory.getPlatformMXBean(HotSpotAOTCacheMXBean.class);
> 
> This uses MF.getPlatformMXBean in the child VM. A more complete test would repeat with:
> 
>         MBeanServer server = ManagementFactory.getPlatformMBeanServer();
>         HotSpotAOTCacheMXBean bean = ManagementFactory.newPlatformMXBeanProxy(server,
>                 "jdk.management:type=HotSpotAOTCacheMXBean",
>                 HotSpotAOTCacheMXBean.class);
> 
> 
> In any case, it might be simpler to test that the MXBean is registered in the test itself, it doesn't need to be in the child VM.

Thanks Alan, I changed the code per your recommendation to not use ManagementFactory.getPlatformMXBean

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28010#discussion_r2475470100

From sspitsyn at openjdk.org  Thu Oct 30 00:06:00 2025
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 30 Oct 2025 00:06:00 GMT
Subject: jmx-dev RFR: 8370851: Mark hotspot and jdk tests incompatible
 with test thread factory
In-Reply-To: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
References: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
Message-ID: <zFq6sMvcdK1mnG0ICxSHqOsqVteV9ElCJPSO-K0eifQ=.101b64d7-6a9a-4147-b599-e03f2cf20696@github.com>

On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag.
> 
> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads.
> 
> The tests that are incompatible with test thread factory are marked with
> test.thread.factory == null
> and the tests that are rather incompatible with virtual threads are makred
> with
> test.thread.factory != "Virtual"

This looks good to me modulo the comment from Alan.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3396935258

From phh at openjdk.org  Thu Oct 30 02:49:07 2025
From: phh at openjdk.org (Paul Hohensee)
Date: Thu, 30 Oct 2025 02:49:07 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v10]
In-Reply-To: <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
Message-ID: <K1i6tnXsNXu7igM2n6e8LAY8FOLsWoU8gUvM-jXth44=.68515401-84c8-4978-8bb1-fbd7acf6682d@github.com>

On Wed, 29 Oct 2025 18:08:31 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix phohensee review comments

Cool. Thanks!

-------------

Marked as reviewed by phh (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/27537#pullrequestreview-3397237436

From lmesnik at openjdk.org  Thu Oct 30 03:12:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Oct 2025 03:12:46 GMT
Subject: jmx-dev RFR: 8370851: Mark hotspot and jdk tests incompatible
 with test thread factory [v2]
In-Reply-To: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
References: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
Message-ID: <xgKfCtq-WIJ014QtJFGaImXUPen_TBBSl9ffmRUvpuE=.c94de0bd-b2fa-494b-8fc8-d7877fade874@github.com>

> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag.
> 
> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads.
> 
> The tests that are incompatible with test thread factory are marked with
> test.thread.factory == null
> and the tests that are rather incompatible with virtual threads are makred
> with
> test.thread.factory != "Virtual"

Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:

  reverted back one test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/28030/files
  - new: https://git.openjdk.org/jdk/pull/28030/files/e132e73f..4eec9c78

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=28030&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/28030.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/28030/head:pull/28030

PR: https://git.openjdk.org/jdk/pull/28030

From lmesnik at openjdk.org  Thu Oct 30 03:12:46 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Oct 2025 03:12:46 GMT
Subject: jmx-dev RFR: 8370851: Mark hotspot and jdk tests incompatible
 with test thread factory [v2]
In-Reply-To: <KEqEP1jBizmwYEkfXhki9qBYcH6_ucnxmIZASBXUq00=.fbeae96b-9b38-440a-9d67-31a87aad63a6@github.com>
References: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
 <KEqEP1jBizmwYEkfXhki9qBYcH6_ucnxmIZASBXUq00=.fbeae96b-9b38-440a-9d67-31a87aad63a6@github.com>
Message-ID: <blEKZoCSsojN-v2gEm5nhxMh1EUgNkry93JoiaG0b9M=.cf6bc77f-b143-49af-8c5f-8b0f1b349a60@github.com>

On Wed, 29 Oct 2025 06:56:56 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   reverted back one test
>
> test/jdk/com/sun/management/ThreadMXBean/VirtualThreads.java line 28:
> 
>> 26:  * @bug 8284161 8303242
>> 27:  * @summary Test com.sun.management.ThreadMXBean with virtual threads
>> 28:  * @requires test.thread.factory != "Virtual"
> 
> This test allows the "main thread" to be a virtual thread so should pass with JTREG_TEST_THREAD_FACTORY=Virtual. Can you re-check your notes as to why this one should be excluded from JTREG_TEST_THREAD_FACTORY=Virtual runs?
> 
> (all the rest looks okay, excluded via ProblemList-Virtual in the loom repo)

Yes, it is not failing. I thought to exclude it because it is virtual thread specific. But I agree, it is not complaint with overall approach. I am reverting this test change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/28030#discussion_r2476276800

From alanb at openjdk.org  Thu Oct 30 06:54:10 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 30 Oct 2025 06:54:10 GMT
Subject: jmx-dev RFR: 8370851: Mark hotspot and jdk tests incompatible
 with test thread factory [v2]
In-Reply-To: <xgKfCtq-WIJ014QtJFGaImXUPen_TBBSl9ffmRUvpuE=.c94de0bd-b2fa-494b-8fc8-d7877fade874@github.com>
References: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
 <xgKfCtq-WIJ014QtJFGaImXUPen_TBBSl9ffmRUvpuE=.c94de0bd-b2fa-494b-8fc8-d7877fade874@github.com>
Message-ID: <Y4ioVfGw5oeMC5BUMXQPwZXhGZnhcbalK22tpalZRyA=.5656d817-059b-48e9-9352-c2e814da50eb@github.com>

On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag.
>> 
>> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads.
>> 
>> The tests that are incompatible with test thread factory are marked with
>> test.thread.factory == null
>> and the tests that are rather incompatible with virtual threads are makred
>> with
>> test.thread.factory != "Virtual"
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted back one test

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3397682870

From kevinw at openjdk.org  Thu Oct 30 11:43:29 2025
From: kevinw at openjdk.org (Kevin Walls)
Date: Thu, 30 Oct 2025 11:43:29 GMT
Subject: jmx-dev RFR: 8370851: Mark hotspot and jdk tests incompatible
 with test thread factory [v2]
In-Reply-To: <xgKfCtq-WIJ014QtJFGaImXUPen_TBBSl9ffmRUvpuE=.c94de0bd-b2fa-494b-8fc8-d7877fade874@github.com>
References: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
 <xgKfCtq-WIJ014QtJFGaImXUPen_TBBSl9ffmRUvpuE=.c94de0bd-b2fa-494b-8fc8-d7877fade874@github.com>
Message-ID: <QXFnmkDn1IG-rjX3kSaPVMbvWmL_PGY29Pw4YuSv-Xk=.dfbcbb36-7530-4d02-8703-8facf2b17545@github.com>

On Thu, 30 Oct 2025 03:12:46 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

>> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag.
>> 
>> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads.
>> 
>> The tests that are incompatible with test thread factory are marked with
>> test.thread.factory == null
>> and the tests that are rather incompatible with virtual threads are makred
>> with
>> test.thread.factory != "Virtual"
>
> Leonid Mesnik has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reverted back one test

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/28030#pullrequestreview-3399147490

From lmesnik at openjdk.org  Thu Oct 30 15:38:19 2025
From: lmesnik at openjdk.org (Leonid Mesnik)
Date: Thu, 30 Oct 2025 15:38:19 GMT
Subject: jmx-dev Integrated: 8370851: Mark hotspot and jdk tests
 incompatible with test thread factory
In-Reply-To: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
References: <CGbYe16oIEn6P99er2JxXnE0PJxNUMNUTVYHwkmTyA0=.9bb63482-d5dd-422d-8816-6e432518a36f@github.com>
Message-ID: <anmy_3B506_Rr-VlYdLQcrvyAAJNVQWorqh4Z8CXEnY=.369636b2-0874-4bce-b3ce-8f5054b430fa@github.com>

On Tue, 28 Oct 2025 23:30:52 GMT, Leonid Mesnik <lmesnik at openjdk.org> wrote:

> There are some tests not compatible with with test thread factory. They are marked with corresponding requires tag.
> 
> Currently, the only "Virtual" test thread factory exist. It tries to start threads as virtual threads.
> 
> The tests that are incompatible with test thread factory are marked with
> test.thread.factory == null
> and the tests that are rather incompatible with virtual threads are makred
> with
> test.thread.factory != "Virtual"

This pull request has now been integrated.

Changeset: ed36b9bb
Author:    Leonid Mesnik <lmesnik at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ed36b9bb6f3d429db6accfb3b096e50e7f2217ff
Stats:     29 lines in 13 files changed: 15 ins; 1 del; 13 mod

8370851: Mark hotspot and jdk tests incompatible with test thread factory

Reviewed-by: alanb, kevinw, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/28030

From abarashev at openjdk.org  Thu Oct 30 21:59:07 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 30 Oct 2025 21:59:07 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v3]
In-Reply-To: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
Message-ID: <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>

On Wed, 29 Oct 2025 11:57:45 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed tests to use SecurityUtils.removeDisabled*Algs methods

test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221:

> 219:         if (args[1].contains("MD5")) {
> 220:             // MD5 is used in this test case, don't disable MD5 algorithm.
> 221:             SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms",

Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2479623980

From abarashev at openjdk.org  Thu Oct 30 22:05:04 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Thu, 30 Oct 2025 22:05:04 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v3]
In-Reply-To: <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
Message-ID: <QnXF3VHsCgccp7EQT-ipTIJ4D0GWC-cyc1TaZWEhDzo=.d7f9c0db-80c4-45d6-b333-dfc4607ad343@github.com>

On Wed, 29 Oct 2025 11:57:45 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed tests to use SecurityUtils.removeDisabled*Algs methods

test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 184:

> 182:         SSLContext ctx = SSLContext.getInstance(protocol);
> 183: 
> 184:         if (keyCert != null) {

Why do we check for keyCert being `null`? Do we expect some future tests to make use of it? BTW, in such case `CertificateBuilder.printCertificate` would fail first.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2479633177

From alanb at openjdk.org  Fri Oct 31 10:31:15 2025
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 31 Oct 2025 10:31:15 GMT
Subject: jmx-dev RFR: 8368527: JMX: Add an MXBeans method to query GC
 CPU time [v10]
In-Reply-To: <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
References: <A5WzWuz0lzleWaNzUczsVMUbWVG5u7Z7ZIal878uVXw=.32ccf75f-8202-4318-a127-bdadf8f3a940@github.com>
 <Vl2l5uwR18EA3fM1429JjfIWKr9aWMDe5gXPFfSaAQU=.2e338420-f2aa-40bf-9992-364cf0eea167@github.com>
Message-ID: <My0vQscI8G1yuOctphv9PsVv2MpqFZcMN-9UIio1cqQ=.242ba5a9-2def-488d-8e59-45b486259824@github.com>

On Wed, 29 Oct 2025 18:08:31 GMT, Jonas Norlinder <duke at openjdk.org> wrote:

>> Hi all,
>> 
>> This PR augments the CPU time sampling measurement capabilities that a user can perform from Java code with the addition of `MemoryMXBean.getGcCpuTime()`. With this patch it will be possible for a user to measure process and GC CPU time during critical section or iterations in benchmarks to name a few. This new method complements the existing `OperatingSystemMXBean.getProcessCpuTime()` for a refined understanding.
>> 
>> `CollectedHeap::gc_threads_do` may operate on terminated GC threads during shutdown, but thanks to JDK-8366865 by @walulyai we can piggyback on the new `Universe::is_shutting_down`. I have implemented a stress-test `test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java` that may identify reading CPU time of terminated threads. Synchronizing on `Universe::is_shutting_down` and `Heap_lock` resolves this problem.
>> 
>> FWIW; To my understanding we don't want to add a `Universe::is_shutting_down` check in gc_threads_do as this may introduce a performance penalty that is unacceptable, therefore we must be careful about the few places where external users call upon gc_threads_do and may race with a terminating VM.
>> 
>> Tested: test/jdk/java/lang/management/MemoryMXBean/GetGcCpuTime.java, jdk/javax/management/mxbean hotspot/jtreg/vmTestbase/nsk/monitoring on Linux x64, Linux aarch64, Windows x64, macOS x64 and macOS aarch64 with release and fastdebug.
>
> Jonas Norlinder has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix phohensee review comments

I've edited the CSR to make it a bit clearer (hope that is okay) and added myself as Reviewer so you can finalize when you are ready.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/27537#issuecomment-3472381204

From mdonovan at openjdk.org  Fri Oct 31 13:09:23 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 31 Oct 2025 13:09:23 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v4]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <oHRWMceW2NNAIA0Dxy9STpzKril7N2pkfz2PJEYIiys=.7ddc36a7-7160-4011-aa15-14e6b681fcf2@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  removed unnecessary comment and made getSSLContext(...) private

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/4804c90d..94ea9ba7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=02-03

  Stats: 22 lines in 6 files changed: 0 ins; 13 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

PR: https://git.openjdk.org/jdk/pull/27342

From mdonovan at openjdk.org  Fri Oct 31 13:09:26 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 31 Oct 2025 13:09:26 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v3]
In-Reply-To: <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
 <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>
Message-ID: <edmvh8dOSb7xx_GAECqL_0F2fP3sazh76bqtZW3o3oA=.bd13b7b2-131f-4f19-8131-dafea1ee5e81@github.com>

On Thu, 30 Oct 2025 21:56:15 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   changed tests to use SecurityUtils.removeDisabled*Algs methods
>
> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221:
> 
>> 219:         if (args[1].contains("MD5")) {
>> 220:             // MD5 is used in this test case, don't disable MD5 algorithm.
>> 221:             SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms",
> 
> Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests.

I removed the comment entirely. It seemed redundant to say "if MD5 is used" right below the `if(args[0].equals("MD5")`

> test/jdk/sun/net/www/protocol/https/HttpsURLConnection/IdentitiesBase.java line 184:
> 
>> 182:         SSLContext ctx = SSLContext.getInstance(protocol);
>> 183: 
>> 184:         if (keyCert != null) {
> 
> Why do we check for keyCert being `null`? Do we expect some future tests to make use of it? BTW, in such case `CertificateBuilder.printCertificate` would fail first.

I think that was leftover from refactoring the code. I removed the null checks and made the method private for now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481353898
PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481352676

From abarashev at openjdk.org  Fri Oct 31 14:24:21 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 31 Oct 2025 14:24:21 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v3]
In-Reply-To: <edmvh8dOSb7xx_GAECqL_0F2fP3sazh76bqtZW3o3oA=.bd13b7b2-131f-4f19-8131-dafea1ee5e81@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <_Gq8X1-p6VhI_dKslFixcyzids5L3ZXet73gkiK48Kc=.e821a94d-eb5c-4788-8b46-2058ca0c085a@github.com>
 <yPWwJegDaYzBn06lxaRYkSoNK4QD2DEJjIcJW-VE1C8=.565a8769-a0be-45cb-a9d0-255a1e1f71ae@github.com>
 <edmvh8dOSb7xx_GAECqL_0F2fP3sazh76bqtZW3o3oA=.bd13b7b2-131f-4f19-8131-dafea1ee5e81@github.com>
Message-ID: <ToXHmo4yq_pBrHGYZD4ZjyuH27YZ0GyLInzBwbQlFK0=.734538a5-ea87-4e03-a8f6-d1d5e22986be@github.com>

On Fri, 31 Oct 2025 13:06:48 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> test/jdk/javax/net/ssl/HttpsURLConnection/CriticalSubjectAltName.java line 221:
>> 
>>> 219:         if (args[1].contains("MD5")) {
>>> 220:             // MD5 is used in this test case, don't disable MD5 algorithm.
>>> 221:             SecurityUtils.removeFromDisabledAlgs("jdk.certpath.disabledAlgorithms",
>> 
>> Line length > 80. Also, I think `If MD5 is used ..` comment would be better because we don't always use MD5. Here and in other tests.
>
> I removed the comment entirely. It seemed redundant to say "if MD5 is used" right below the `if(args[0].equals("MD5")`

Yes, makes sense. Please also fix the line length.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/27342#discussion_r2481598670

From mdonovan at openjdk.org  Fri Oct 31 15:02:42 2025
From: mdonovan at openjdk.org (Matthew Donovan)
Date: Fri, 31 Oct 2025 15:02:42 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v5]
In-Reply-To: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
Message-ID: <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>

> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.

Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:

  changed line wrapping

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/27342/files
  - new: https://git.openjdk.org/jdk/pull/27342/files/94ea9ba7..1aaf4247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=27342&range=03-04

  Stats: 10 lines in 5 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/27342.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/27342/head:pull/27342

PR: https://git.openjdk.org/jdk/pull/27342

From abarashev at openjdk.org  Fri Oct 31 16:08:40 2025
From: abarashev at openjdk.org (Artur Barashev)
Date: Fri, 31 Oct 2025 16:08:40 GMT
Subject: jmx-dev RFR: 8353738: Update TLS unit tests to not use
 certificates with MD5 signatures [v5]
In-Reply-To: <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
References: <mBEv1oGEIazOqeTLJKEJ0NtfAWz15hRLJGfR2qt_kYY=.5df5c042-ba97-41fc-95dd-48279881e399@github.com>
 <oFzO2YdyquHLUCZQW-dO5ppLRzbMrGtc9zhIVu_FR4I=.f1db99b1-47a3-4929-b17d-30748dc1d7e1@github.com>
Message-ID: <QRCLhchA_FrVJbR7ZeO5n-CZpjud-FLV_qIqkMmyIH4=.b57b9265-3eea-4523-97e2-04d78d4bb39c@github.com>

On Fri, 31 Oct 2025 15:02:42 GMT, Matthew Donovan <mdonovan at openjdk.org> wrote:

>> This PR updates tests that were using MD5 certificates. For most of the tests, I added test cases for TLSv1.2/MD5withRSA and TLSv1.3/SHA256withRSA.
>
> Matthew Donovan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   changed line wrapping

LGTM

-------------

Marked as reviewed by abarashev (Committer).

PR Review: https://git.openjdk.org/jdk/pull/27342#pullrequestreview-3405000667