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