From mchung at openjdk.org  Fri Nov  1 01:29:52 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 1 Nov 2024 01:29:52 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
Message-ID: <n2hkylB3HsgWYwZ37GvdJe2SAEX-c9geJJtSN_8NiYY=.20707bda-2fd7-4e09-b42d-319407f40ac6@github.com>

On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Some test fixes
>  - Remove period in jlink.properties
>  - Revert changes to ResourcePoolEntry
>  - Fix comment in RuntimeImageLinkException
>  - Remove ImageReader (like JmodsReader)
>  - More comment fixes (JlinkTask)
>  - Move some comments around
>  - More comment fix-ups (JRTArchive)
>  - Fix description of configure option
>  - ... and 162 more: https://git.openjdk.org/jdk/compare/c40bb762...b702ba8c

I expect that the jmodless tests will first build an image (say `image1`) using jlink `--generate-linkable-runtime` option and then verify `image1/bin/jlink` that links from the run-time image.    I don't see `--generate-linkable-runtime` option is used from jmodless tests.   I looked at `AbstractLinkableRuntimeTest` which provides the support to create linkable runtime image but not obvious to me.   Can you describe the idea of this test framework?

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2451122428

From dholmes at openjdk.org  Fri Nov  1 01:59:50 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 1 Nov 2024 01:59:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
Message-ID: <zAfnvgKNOg378M1__ONAqpzOPzrV0KqeL4YhQEv9OS4=.4edddfa1-ca46-48db-bce2-7ee4ab93b463@github.com>

On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add comment to ThreadService::find_deadlocks_at_safepoint
>  - Remove assignments in preempt_kind enum

Marked as reviewed by dholmes (Reviewer).

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:

> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
> 888:   } else {
> 889:     // frame can't be freezed. Most likely the call_stub or upcall_stub

Suggestion:

    // Frame can't be frozen. Most likely the call_stub or upcall_stub

src/hotspot/share/services/threadService.cpp line 467:

> 465:         if (waitingToLockMonitor->has_owner()) {
> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
> 467:           // If currentThread is nullptr we would like to know if the owner

Suggestion:

          // If currentThread is null we would like to know if the owner

src/hotspot/share/services/threadService.cpp line 474:

> 472:           // vthread we never record this as a deadlock. Note: unless there
> 473:           // is a bug in the VM, or a thread exits without releasing monitors
> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.

Suggestion:

          // acquired through JNI, null should imply an unmounted vthread owner.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446

From qamai at openjdk.org  Fri Nov  1 02:44:15 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 1 Nov 2024 02:44:15 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
Message-ID: <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>

> Hi,
> 
> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
> 
> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
> 
> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
> 
>     Benchmark                      Mode  Cnt  Score   Error  Units
>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
> 
> For reference this is the results without this patch:
> 
>     Benchmark                      Mode  Cnt  Score   Error  Units
>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
> 
> Please kindly review, thanks very much.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  wait for the close operation to complete on acquire failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21810/files
  - new: https://git.openjdk.org/jdk/pull/21810/files/ab787c94..29047718

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

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

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

From qamai at openjdk.org  Fri Nov  1 02:44:15 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 1 Nov 2024 02:44:15 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v3]
In-Reply-To: <H_jGObQ-aQDgT6Nvtb_bnN-kw_THKiegNphS0EhUsfs=.ef80d5bf-d11d-4e36-8c6f-6ceb6c510239@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <H_jGObQ-aQDgT6Nvtb_bnN-kw_THKiegNphS0EhUsfs=.ef80d5bf-d11d-4e36-8c6f-6ceb6c510239@github.com>
Message-ID: <nr50fgeKg7XBn7D_tOJ6e_d_waRMEg3CoGmktuw9ono=.d01aa555-7c2c-42ac-8adf-b8aae41cb46e@github.com>

On Thu, 31 Oct 2024 18:09:55 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix benchmarks

Yes you are right, that is a great observation! My solution is that since we are throwing an exception anyway, we will spin on the `state` field to wait for it to change before throwing the exception.

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

PR Comment: https://git.openjdk.org/jdk/pull/21810#issuecomment-2451187099

From heidinga at openjdk.org  Fri Nov  1 03:57:34 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Fri, 1 Nov 2024 03:57:34 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v6]
In-Reply-To: <Wa16sMIw3k7Ad2Fxj3OYhaxYzHsA0nZCYuRkmiUmSbg=.b2d64b08-8edb-47f4-9ab7-6e332950536c@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <Wa16sMIw3k7Ad2Fxj3OYhaxYzHsA0nZCYuRkmiUmSbg=.b2d64b08-8edb-47f4-9ab7-6e332950536c@github.com>
Message-ID: <qM3nz9qI10MFZ14TlthOJERSf2LhhYCcIz5LpZvB8P8=.ad19e9dc-369b-40f9-b425-b682ec0202c6@github.com>

On Thu, 31 Oct 2024 02:23:24 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed whitespace; fixed minimal build

src/hotspot/share/cds/aotClassInitializer.cpp line 348:

> 346:     }
> 347:     JavaValue result(T_VOID);
> 348:     JavaCalls::call_static(&result, ik,

Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup?

I think we do to be consistent with the non-AOTCache run as there is a fence after `<clinit>` (when this code would normally run) due to the initialization lock.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1825400292

From dholmes at openjdk.org  Fri Nov  1 04:52:29 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 1 Nov 2024 04:52:29 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
 <SggKNDCRHs0irYUWCRal7gya7cZF7C8uXuXrlnwrMQQ=.fa48e548-3c8b-46bc-8dd8-1895d4fec107@github.com>
 <r54jnGo7jwe1fTmcza3ZTnn68s5GcKaTOf56YFO-CZ4=.03ca37d7-0807-47d8-8b77-02b2ee470401@github.com>
 <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com>
Message-ID: <oyE83NaeFpdKv5sb8l-fogb8zHB4LQZMeOprCHZwhiA=.0ff4c4ca-8f55-4f7f-8845-813693e3c34e@github.com>

On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

> I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. 

A `CriticalSection` is a mutex. A RWLock is not a "mutex".

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2451288744

From jwaters at openjdk.org  Fri Nov  1 05:28:31 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 1 Nov 2024 05:28:31 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v4]
In-Reply-To: <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
Message-ID: <-ksBFuJLoUvuk79FQCrZeyidIBwr8uQLJ6cKC883Yxc=.d0b3d22e-2432-4885-ac4b-5889f74f0619@github.com>

On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove global memHandle, would've liked to keep it as a comment :(

I guess Weijun's comment means security is good to go, even though it's not an approval. jpackage, any comments?

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2451316177

From dlong at openjdk.org  Fri Nov  1 07:17:48 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 1 Nov 2024 07:17:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
Message-ID: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> OK, so you're saying it's the stack adjustment that's the problem.  It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary.  Isn't that a bug that should be fixed?  I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest.  Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling.
>> 
>> It's still unclear to me exactly how we resume after preemption.  It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted.  If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment.  In your example, last_Java_pc would be set to 0xffffdfdba5e4.  I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments.
>
>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed?
>>
> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method.

It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409

From pminborg at openjdk.org  Fri Nov  1 07:47:28 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 1 Nov 2024 07:47:28 GMT
Subject: RFR: 8343188: Investigate ways to simplify MemorySegment::ofBuffer
 [v5]
In-Reply-To: <7s7o6Ny8Ej3dNdfIPi76f3KAYLaOPEnv00AeyTFfp8E=.83a19ef4-7252-4b8a-9740-601d1cfc1a11@github.com>
References: <iSRWOFr_KAHjpsaBWNQAD4DWYjpIeVkVZ7IsfXWuQcc=.9eff90a5-396f-40d4-a4ba-e7463cf35120@github.com>
 <ThXLm5hdqrgnPB9GMApFMhXCufjvwrgye4Ie20TUmx0=.91b1de8c-7887-44bb-aa7b-e0e13f7aa5b1@github.com>
 <LGMtkrbRnR4SfPvjJs2uDzMBc0YGWfq9-GwxfS0RGQ4=.d68a9828-1f9a-48bb-89fa-5b7354131b58@github.com>
 <7s7o6Ny8Ej3dNdfIPi76f3KAYLaOPEnv00AeyTFfp8E=.83a19ef4-7252-4b8a-9740-601d1cfc1a11@github.com>
Message-ID: <BwoArmeX-0FKbEb3mhtzFLrYtNHpSF_uuT4ekBtdGj0=.7c265696-28b0-4761-a29c-551f1c25c161@github.com>

On Thu, 31 Oct 2024 19:06:16 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/AbstractMemorySegmentImpl.java line 526:
>> 
>>> 524:         final Object base = NIO_ACCESS.getBufferBase(b);
>>> 525:         return (base == null)
>>> 526:                 ? nativeSegment(b, offset, length)
>> 
>> why not calling the other "heapSegment" ?
>
> Because heap?segments don?t?have to?be?backed by?an?array.

The reason was what @ExE-Boss mentioned but for me, I am happy with either name. I will update to `heapSegment()`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21764#discussion_r1825543298

From pminborg at openjdk.org  Fri Nov  1 07:47:28 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 1 Nov 2024 07:47:28 GMT
Subject: RFR: 8343188: Investigate ways to simplify MemorySegment::ofBuffer
 [v5]
In-Reply-To: <BwoArmeX-0FKbEb3mhtzFLrYtNHpSF_uuT4ekBtdGj0=.7c265696-28b0-4761-a29c-551f1c25c161@github.com>
References: <iSRWOFr_KAHjpsaBWNQAD4DWYjpIeVkVZ7IsfXWuQcc=.9eff90a5-396f-40d4-a4ba-e7463cf35120@github.com>
 <ThXLm5hdqrgnPB9GMApFMhXCufjvwrgye4Ie20TUmx0=.91b1de8c-7887-44bb-aa7b-e0e13f7aa5b1@github.com>
 <LGMtkrbRnR4SfPvjJs2uDzMBc0YGWfq9-GwxfS0RGQ4=.d68a9828-1f9a-48bb-89fa-5b7354131b58@github.com>
 <7s7o6Ny8Ej3dNdfIPi76f3KAYLaOPEnv00AeyTFfp8E=.83a19ef4-7252-4b8a-9740-601d1cfc1a11@github.com>
 <BwoArmeX-0FKbEb3mhtzFLrYtNHpSF_uuT4ekBtdGj0=.7c265696-28b0-4761-a29c-551f1c25c161@github.com>
Message-ID: <ymEjqiEhwCl9oFQA5cWTuz2oiJY2r2NjQQsJvonYyYY=.862bd559-505c-4b17-9346-1487da8f81af@github.com>

On Fri, 1 Nov 2024 07:42:34 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Because heap?segments don?t?have to?be?backed by?an?array.
>
> The reason was what @ExE-Boss mentioned but for me, I am happy with either name. I will update to `heapSegment()`.

The method has been moved into Buffer implementations now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21764#discussion_r1825544983

From pminborg at openjdk.org  Fri Nov  1 07:53:03 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 1 Nov 2024 07:53:03 GMT
Subject: RFR: 8343188: Investigate ways to simplify MemorySegment::ofBuffer
 [v6]
In-Reply-To: <iSRWOFr_KAHjpsaBWNQAD4DWYjpIeVkVZ7IsfXWuQcc=.9eff90a5-396f-40d4-a4ba-e7463cf35120@github.com>
References: <iSRWOFr_KAHjpsaBWNQAD4DWYjpIeVkVZ7IsfXWuQcc=.9eff90a5-396f-40d4-a4ba-e7463cf35120@github.com>
Message-ID: <pVYGX6wZmTuYHmal4WosdcjOnGkQ8HaMJGsRhOiLmIo=.6ce2983d-ccc8-4170-b27f-88b8c513bacb@github.com>

> This PR proposes to improve `MemorySegment::ofBuffer` making it more amenable to inlining and generally improving performance.
> 
> Testing successfully on tier1-6

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Rename methods

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21764/files
  - new: https://git.openjdk.org/jdk/pull/21764/files/e6b03e8b..810feb67

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

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

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

From pminborg at openjdk.org  Fri Nov  1 08:57:28 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 1 Nov 2024 08:57:28 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
Message-ID: <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>

On Fri, 1 Nov 2024 02:44:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wait for the close operation to complete on acquire failures

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 90:

> 88:         }
> 89: 
> 90:         STATE.setOpaque(this, CLOSED);

Why are we using opaque semantics here and not volatile?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1825600258

From pminborg at openjdk.org  Fri Nov  1 09:11:43 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 1 Nov 2024 09:11:43 GMT
Subject: RFR: 8340307: Add explanation around MemorySegment:reinterpret
 regarding arenas [v5]
In-Reply-To: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
References: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
Message-ID: <g-Ld4Y_Jf6aPeFUOrOz74yER33wYRg0zep4FPeKofPg=.95d19d7e-343d-44f7-b5b4-14017fec6f52@github.com>

> This PR proposes to add a small text segment on the `MemorySegment::reinterpret` overloads that takes an Arena stating the responsibility of actually freeing reinterpreted segments lies with the *original* arena.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Reword reinterpret docs

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21761/files
  - new: https://git.openjdk.org/jdk/pull/21761/files/34e5b122..771804be

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

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

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

From attila at openjdk.org  Fri Nov  1 09:19:12 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Fri, 1 Nov 2024 09:19:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <yCCKheohe-gTYgtLgXobFgKSQOYjymWCWQ_0zzF9O0w=.84ce1a1f-f8ca-435b-8a98-63073ac9ea5a@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

`jdk.dynalink` changes look good.

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

Marked as reviewed by attila (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2409755977

From schernyshev at openjdk.org  Fri Nov  1 09:54:36 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 1 Nov 2024 09:54:36 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <xDeZ0helum-A3G4D-8hDqByH43Qz_6T7Uv-2lBaIeUs=.49e7d53b-a335-47ac-8139-028f1b763160@github.com>

On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

I've done the standard tiers (1-3), and additionally "jtreg:jdk/internal/platform/cgroup" and "gtest::cgroupTest". I see now some of the dockers are failing. I am looking into it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2451611651

From aturbanov at openjdk.org  Fri Nov  1 10:04:29 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Fri, 1 Nov 2024 10:04:29 GMT
Subject: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with
 CD-ROM drive
In-Reply-To: <oke6ZdAo53Bi9nM08TE7DuXQML_ZKEd7_gopABmmpCg=.77d5d71c-2574-4518-9a90-d8eb0a5e237b@github.com>
References: <oke6ZdAo53Bi9nM08TE7DuXQML_ZKEd7_gopABmmpCg=.77d5d71c-2574-4518-9a90-d8eb0a5e237b@github.com>
Message-ID: <fi6aQ4dlKxlTQ01nxpKU_aC1TPcCrJNt6myX6gFlrAg=.1e286da4-6c40-4111-b3d7-86d713715728@github.com>

On Thu, 31 Oct 2024 07:15:16 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

> To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use  Cygwin?s `df` to get the size for comparison if the test target drive is a CD-ROM drive.
> 
> As described in JDK-8343342, GetDiskSpaceInformationW can't get information about the size of the CD-ROM drive. 
> GetDiskFreeSpaceExW can also get information about the size of the CD-ROM drive. However, because GetDiskFreeSpaceExW is called by the File.get-X-Space methods, it seems more reasonable to compare the size got by other way than GetDiskFreeSpaceExW as a test. For this reason, I use Cygwin's `df`.
> In JDK-8298619, GetDiskSpaceInformationW was adopted instead of `df` because the size got by File.get-X-Space methods may not match the size got by `df` when per-user quotas are used. I don't think this problem applies to CD-ROM  drive, so I think we can use Cygwin's `df` for CD-ROM drive.
> 
> After fix, I ran a test on Windows Server 2019 where drive C is a normal local disk, drive D is an unmounted iso CD-ROM  drive, and drive F is an iso mounted CD-ROM drive and confirmed that it passes.
> 
> I think this fix may also resolves the similar failure reported at https://github.com/openjdk/jdk/pull/12397#issuecomment-1705164515.
> 
> Thanks

Marked as reviewed by aturbanov (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21799#pullrequestreview-2409813848

From qamai at openjdk.org  Fri Nov  1 10:08:30 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 1 Nov 2024 10:08:30 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
Message-ID: <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>

On Fri, 1 Nov 2024 08:55:09 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   wait for the close operation to complete on acquire failures
>
> src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 90:
> 
>> 88:         }
>> 89: 
>> 90:         STATE.setOpaque(this, CLOSED);
> 
> Why are we using opaque semantics here and not volatile?

Because this variable is not used as a synchronization device, so a stronger order is unnecessary. We still need the store to be observed by other threads when they fail an `acquire` or a `close` so opaque is appropriate here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1825658329

From duke at openjdk.org  Fri Nov  1 10:17:43 2024
From: duke at openjdk.org (kabutz)
Date: Fri, 1 Nov 2024 10:17:43 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer split
 the stream
Message-ID: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>

Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.

The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.

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

Commit messages:
 - Fixed bug in spliterators

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

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

From vklang at openjdk.org  Fri Nov  1 10:56:36 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Nov 2024 10:56:36 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
Message-ID: <45pbvUd2N_TF4P-lieQKCRs6OoBv7HG5AZwODeGfQSI=.42413ed6-2373-48cf-8d24-1dfe06665fcf@github.com>

On Fri, 1 Nov 2024 10:13:15 GMT, kabutz <duke at openjdk.org> wrote:

> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
> 
> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.

Hi @kabutz,
Interesting catch!
A regression test (splitability) and a test which verifies correct operation under parallel evaluation would be appropriate here.

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

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2451687772

From duke at openjdk.org  Fri Nov  1 11:00:28 2024
From: duke at openjdk.org (kabutz)
Date: Fri, 1 Nov 2024 11:00:28 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
Message-ID: <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>

On Fri, 1 Nov 2024 10:13:15 GMT, kabutz <duke at openjdk.org> wrote:

> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
> 
> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.

Sure, where should I add that test?

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

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2451692197

From vklang at openjdk.org  Fri Nov  1 11:12:34 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Nov 2024 11:12:34 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
Message-ID: <UsEXDOQAGNijkaq_wGDCqNKl1Cw0bKnKqq5Xatoy_4Y=.b8b8f32d-c8b7-43f9-93e5-29daaeadbf2d@github.com>

On Fri, 1 Nov 2024 10:58:09 GMT, kabutz <duke at openjdk.org> wrote:

>> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
>> 
>> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.
>
> Sure, where should I add that test?

@kabutz I'd say either under its own directory `test/jdk/java/util/concurrent/ConcurrentSkipListMap/` or possibly in `test/jdk/java/util/concurrent/tck/ConcurrentSkipListMapTest.java`.

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

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2451705839

From schernyshev at openjdk.org  Fri Nov  1 13:15:28 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 1 Nov 2024 13:15:28 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <oWCDSLAltHOV8n0QmPtEyeeZHBvN12-DZrqeKhzBql8=.e8c63755-19f1-4c2f-96d3-2df71b6676b2@github.com>

On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Thanks Severin! It was the problematic change in the logic that skips duplicate cgroup contoller mount points. Failing tests are mounting duplicates of the host's cgroups with `--volume=/sys/fs/cgroup:/cgroup-in:ro`. As they're in fact mounting read-write, the logic picked up `rw` mount option and falsely detected "host mode". Also the `--privileged` creates `rw` mounts, so the entire approach needs correction. I am changing to the draft PR for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2451851221

From asotona at openjdk.org  Fri Nov  1 13:56:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 13:56:00 GMT
Subject: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205
Message-ID: <VpJAUp3XD2ZdOBynIAbv_vuF5xBUbuLL5ukB3wks0GY=.791d3895-6630-4ab1-af10-83a2943f55ef@github.com>

This patch fixes regression in StackMapGenerator caused by JDK-8339205 + added test.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8343436: Regression in StackMapGenerator after JDK-8339205

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

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

From liach at openjdk.org  Fri Nov  1 14:02:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 14:02:39 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names
Message-ID: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>

An oversight in the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665 caused `ClassDesc` to incorrectly accept empty strings as binary names.  This patch fixes that problem, and unifies the checks for package and class nominal descriptors.

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

Commit messages:
 - 8343437: ClassDesc.of incorrectly permitting empty names

Changes: https://git.openjdk.org/jdk/pull/21830/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21830&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343437
  Stats: 48 lines in 5 files changed: 22 ins; 6 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21830/head:pull/21830

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

From liach at openjdk.org  Fri Nov  1 14:12:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 14:12:30 GMT
Subject: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205
In-Reply-To: <VpJAUp3XD2ZdOBynIAbv_vuF5xBUbuLL5ukB3wks0GY=.791d3895-6630-4ab1-af10-83a2943f55ef@github.com>
References: <VpJAUp3XD2ZdOBynIAbv_vuF5xBUbuLL5ukB3wks0GY=.791d3895-6630-4ab1-af10-83a2943f55ef@github.com>
Message-ID: <J9iEaBvTbcRiA4cnwzyr0AHXIK0jyLA8zBVEl8yJHac=.c40352e6-0f6f-4f9e-9b78-dd64f1d67bcb@github.com>

On Fri, 1 Nov 2024 13:50:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch fixes regression in StackMapGenerator caused by JDK-8339205 + added test.
> 
> Please review.
> 
> Thanks,
> Adam

Seems we need to fix all the dup methods too. `checkStack` takes a usable max index instead of an exclusive end index so it's super confusing.

Maybe we can rename `checkStack` to `checkMaxStack` and use the exclusive end, like what we are doing with `stackSize` and `frameMaxStack`, to reduce confusions?

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

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21828#pullrequestreview-2410140634
PR Comment: https://git.openjdk.org/jdk/pull/21828#issuecomment-2451936575

From prappo at openjdk.org  Fri Nov  1 14:14:51 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 1 Nov 2024 14:14:51 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v4]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <mK7TQp3GfHcv73DKoOhXaUFeTEAyY9LxpY8e7srvJ18=.6a1c08fd-018d-4884-b184-42583ac41849@github.com>

> Prepare for JDK 25.

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

 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 21
   
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
 - Add forgotten .jcheck/conf
 - Initial commit

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/1286fcca..9a0553bb

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

  Stats: 49274 lines in 836 files changed: 5371 ins; 40901 del; 3002 mod
  Patch: https://git.openjdk.org/jdk/pull/21763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21763/head:pull/21763

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

From rriggs at openjdk.org  Fri Nov  1 14:39:35 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Nov 2024 14:39:35 GMT
Subject: RFR: 8343293: Remove the check for <apphome>/jre/lib/libjava.dylib
 from the launcher's java_md_macosx.m
In-Reply-To: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
References: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
Message-ID: <Nm0JJ7ZabXcQ4urzjGt8AQQmBttW4C7O_2GpZoG79yE=.6eff35ea-7d5a-4d14-8164-a0f75b428b2f@github.com>

On Wed, 30 Oct 2024 14:27:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up a leftover code from the launcher's java_md_macosx.m file?
> 
> In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the launcher code to remove checks for  `<apphome>/jre/lib/` when determining the JDK installation root. Those changes were done in the Unix and Windows files and the macosx one got left out, likely due to an oversight.
> 
> The commit in this PR removes that leftover code. No new tests have been added and existing tier1, tier2, tier3 tests continue to pass.

src/java.base/macosx/native/libjli/java_md_macosx.m line 432:

> 430:             }
> 431:         }
> 432:         /* ensure storage for path + /jre + NULL */

The corresponding changes in JDK-8329862 included adding a call to JLI_TraceLauncher.
Such as:
`    JLI_TraceLauncher("Attempt to get JDK installation root from launcher executable path\n");
`
Adding a similar trace message would be consistent across platforms.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21789#discussion_r1825895271

From rriggs at openjdk.org  Fri Nov  1 14:46:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 1 Nov 2024 14:46:27 GMT
Subject: RFR: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <uhH8XDVcPiZ6SyFzzcPeVb1H0lap7AZd9Be_IBhUfas=.4ac33609-8db4-4075-be18-062d70c4e716@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

Looks good to me.

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

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21783#pullrequestreview-2410211856

From asotona at openjdk.org  Fri Nov  1 14:49:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 14:49:35 GMT
Subject: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205
In-Reply-To: <VpJAUp3XD2ZdOBynIAbv_vuF5xBUbuLL5ukB3wks0GY=.791d3895-6630-4ab1-af10-83a2943f55ef@github.com>
References: <VpJAUp3XD2ZdOBynIAbv_vuF5xBUbuLL5ukB3wks0GY=.791d3895-6630-4ab1-af10-83a2943f55ef@github.com>
Message-ID: <tC_zjtCIZ9AjncXku1yb8F-wURtyKX0QC3uyzZrD-Zg=.48c2649c-9ca8-4128-b6ba-3bb957fd3604@github.com>

On Fri, 1 Nov 2024 13:50:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch fixes regression in StackMapGenerator caused by JDK-8339205 + added test.
> 
> Please review.
> 
> Thanks,
> Adam

Now I noticed 8339205 added large untested surface full of bugs.
I'm closing this PR and will open a new with reversion of 8339205.

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

PR Comment: https://git.openjdk.org/jdk/pull/21828#issuecomment-2451997789

From asotona at openjdk.org  Fri Nov  1 14:49:35 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 14:49:35 GMT
Subject: Withdrawn: 8343436: Regression in StackMapGenerator after JDK-8339205
In-Reply-To: <VpJAUp3XD2ZdOBynIAbv_vuF5xBUbuLL5ukB3wks0GY=.791d3895-6630-4ab1-af10-83a2943f55ef@github.com>
References: <VpJAUp3XD2ZdOBynIAbv_vuF5xBUbuLL5ukB3wks0GY=.791d3895-6630-4ab1-af10-83a2943f55ef@github.com>
Message-ID: <R5IuNHFTXLZ4WGFgmHycRjlSi3zr-mKNEgdBntV3St0=.3d7d1767-6ff7-499d-a008-2588b5b1c112@github.com>

On Fri, 1 Nov 2024 13:50:39 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> This patch fixes regression in StackMapGenerator caused by JDK-8339205 + added test.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has been closed without being integrated.

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

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

From jpai at openjdk.org  Fri Nov  1 14:51:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Nov 2024 14:51:49 GMT
Subject: RFR: 8343293: Remove the check for <apphome>/jre/lib/libjava.dylib
 from the launcher's java_md_macosx.m [v2]
In-Reply-To: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
References: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
Message-ID: <jimrIPiksROK_-goTNbNi0HmPC2qGhiUmzRv6wfsmbI=.859344ce-f50a-420c-a7c6-bb1168a20ab2@github.com>

> Can I please get a review of this change which cleans up a leftover code from the launcher's java_md_macosx.m file?
> 
> In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the launcher code to remove checks for  `<apphome>/jre/lib/` when determining the JDK installation root. Those changes were done in the Unix and Windows files and the macosx one got left out, likely due to an oversight.
> 
> The commit in this PR removes that leftover code. No new tests have been added and existing tier1, tier2, tier3 tests continue to pass.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Roger's suggestion - introduce log message to match unix/windows

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21789/files
  - new: https://git.openjdk.org/jdk/pull/21789/files/e125c18e..e09dd1b3

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

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

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

From jpai at openjdk.org  Fri Nov  1 14:51:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 1 Nov 2024 14:51:49 GMT
Subject: RFR: 8343293: Remove the check for <apphome>/jre/lib/libjava.dylib
 from the launcher's java_md_macosx.m [v2]
In-Reply-To: <Nm0JJ7ZabXcQ4urzjGt8AQQmBttW4C7O_2GpZoG79yE=.6eff35ea-7d5a-4d14-8164-a0f75b428b2f@github.com>
References: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
 <Nm0JJ7ZabXcQ4urzjGt8AQQmBttW4C7O_2GpZoG79yE=.6eff35ea-7d5a-4d14-8164-a0f75b428b2f@github.com>
Message-ID: <5fj1AyctbnneF6JwMLg7BhVEt1J5tWs0EXiDefjsCk8=.665d6feb-2607-45de-b7d7-8a7a6d2b4912@github.com>

On Fri, 1 Nov 2024 14:36:39 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Roger's suggestion - introduce log message to match unix/windows
>
> src/java.base/macosx/native/libjli/java_md_macosx.m line 432:
> 
>> 430:             }
>> 431:         }
>> 432:         /* ensure storage for path + /jre + NULL */
> 
> The corresponding changes in JDK-8329862 included adding a call to JLI_TraceLauncher.
> Such as:
> `    JLI_TraceLauncher("Attempt to get JDK installation root from launcher executable path\n");
> `
> Adding a similar trace message would be consistent across platforms.

That's a good point. I've now updated the PR to add the same log message as the one present in unix/windows variant of this code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21789#discussion_r1825910349

From vklang at openjdk.org  Fri Nov  1 14:54:29 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 1 Nov 2024 14:54:29 GMT
Subject: RFR: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <TMdUTFTUHkbWft3psttVBOZ7-1o-z6xtfPe9LRBnI9A=.19a0fba7-593c-4fc2-bc25-3d99fd5d4a33@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

@DougLea Any concerns from your point of view?

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

PR Comment: https://git.openjdk.org/jdk/pull/21783#issuecomment-2452006118

From asotona at openjdk.org  Fri Nov  1 15:09:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 15:09:00 GMT
Subject: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205
Message-ID: <6RSxcb_9ZihmeSIp78EF85MF0BOiRZ4resuNOfS_qnk=.9790d2ad-9f8a-4639-b340-0744c7ac2762@github.com>

JDK-8339205 introduced multiple regressions in StackMapGenerator and added a lot of new untested code.

This patch reverts StackMapGenerator to the state before JDK-8339205 and adds one regression test.

Please review.

Thanks,
Adam

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

Commit messages:
 - 8343436: Regression in StackMapGenerator after JDK-8339205

Changes: https://git.openjdk.org/jdk/pull/21835/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21835&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343436
  Stats: 354 lines in 2 files changed: 52 ins; 223 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/21835.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21835/head:pull/21835

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

From roger.riggs at oracle.com  Fri Nov  1 15:20:24 2024
From: roger.riggs at oracle.com (Roger Riggs)
Date: Fri, 1 Nov 2024 11:20:24 -0400
Subject: Using a standard bug report template and a definition of done
In-Reply-To: <CH3PR10MB76772EFAED5910367368BE30A2562@CH3PR10MB7677.namprd10.prod.outlook.com>
References: <LO4P265MB73728B2676C9E21F0346FA3BFA562@LO4P265MB7372.GBRP265.PROD.OUTLOOK.COM>
 <CH3PR10MB76772EFAED5910367368BE30A2562@CH3PR10MB7677.namprd10.prod.outlook.com>
Message-ID: <f7e2e982-b0ee-47c9-94b0-3b7f0b2eec1d@oracle.com>

Hi Tom,

Your interest seems to be more in the libraries area, so redirecting 
this conversation to core-lib-dev at openjdk.java.net.

There is quite a complete OpenJDK Developers Guide that describes the 
process and guidance.

<https://openjdk.org/guide/>


      The OpenJDK Developers' Guide <https://openjdk.org/guide/>

<https://openjdk.org/guide/>

There is already quite a bit of process and discussions of process fit 
into the mail alias for the DevGuide:
*guide-dev* <https://mail.openjdk.org/mailman/listinfo/guide-dev> 
Technical discussion related to the Developers' Guide Project
*guide-discuss* 
<https://mail.openjdk.org/mailman/listinfo/guide-discuss> 	General 
discussion of topics related to the OpenJDK Developers' Guide


There are separate email aliases for the VM, language, compiler, and 
subareas of the libraries.
For all the Mailing Lists see: https://mail.openjdk.org/mailman/listinfo

Regards, Roger


On 11/1/24 10:54 AM, Chen Liang wrote:
> Hello Tom,
> There is a standard template for bug reports at 
> https://bugreport.java.com/bugreport/ 
> <https://bugreport.java.com/bugreport/>.? Unfortunately, there are 
> many antique bugs in the JBS which are forgotten, so they may be 
> obsolete (no longer valid) or their reproduction steps have changed; 
> we cannot do much.? Also, you don't always have to write identical 
> regression tests as in the bug report; often times you can write 
> simpler cases with professional test suites like JUnit, and that's at 
> least the trend on the core libraries side of the JDK.
>
> You said you want a definition of "done." Where did you see that term? 
> In the JBS, you should look for bugs with "Resolution" that is 
> "Unresolved."? If you mean for sending patches, we recommend that when 
> you open a PR, it should be complete with tests as if it can be 
> immediately merged, so that you don't have to push more unless public 
> review request changes.
>
> Chen
> ------------------------------------------------------------------------
> *From:* jdk-dev <jdk-dev-retn at openjdk.org> on behalf of Tom Mooney 
> <Tom.Mooney at bjss.com>
> *Sent:* Friday, November 1, 2024 9:45 AM
> *To:* jdk-dev at openjdk.org <jdk-dev at openjdk.org>
> *Subject:* Using a standard bug report template and a definition of done
> Has the project tried a standardized bug report template before with 
> supplied test data and exact steps to reproduce the bug? I feel that 
> this would help contributors very quickly reproduce the bug exactly as 
> it was originally produced, possibly write a regression test(s) for it 
> (where applicable) and be able to get to the business of fixing it as 
> soon as possible. Plus it could make it easier for new contributors 
> like me to get started faster. Its just that I've been browsing new 
> bugs for something to work on and I find it difficult to be able to 
> confirm when I've actually fixed it (apart from not seeing the same 
> error messages produced). I could volunteer such a template it was 
> deemed by the mailing list as something that would be useful.? Perhaps 
> a definition of done too would be useful so that bug fixers can know 
> when they are truly done and they could mail the evidence along with 
> their patches for review giving them a better chance of getting their 
> contributions accepted.
>
> Ta
> Tom
>
> The information included in this email and any files transmitted with 
> it may contain information that is confidential and it must not be 
> used by, or its contents or attachments copied or disclosed to, 
> persons other than the intended addressee. If you have received this 
> email in error, please notify BJSS. In the absence of written 
> agreement to the contrary BJSS' relevant standard terms of contract 
> for any work to be undertaken will apply. Please carry out virus or 
> such other checks as you consider appropriate in respect of this 
> email. BJSS does not accept responsibility for any adverse effect upon 
> your system or data in relation to this email or any files transmitted 
> with it. BJSS Limited, a company registered in England and Wales 
> (Company Number 2777575), VAT Registration Number 613295452, 
> Registered Office Address, 1 Whitehall Quay, Leeds, LS1 4HR
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241101/f87d2409/attachment.htm>

From aboldtch at openjdk.org  Fri Nov  1 15:26:56 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 1 Nov 2024 15:26:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
Message-ID: <E_2bhhPKWwlsXcXEcFM0S67WYrrXLK7cSrSEqaxJVFY=.e1ab6e11-553d-41fd-9f10-0686082402d6@github.com>

On Thu, 31 Oct 2024 21:50:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - add comment to ThreadService::find_deadlocks_at_safepoint
>  - Remove assignments in preempt_kind enum

src/hotspot/share/oops/stackChunkOop.cpp line 445:

> 443: 
> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();

Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 

There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

src/hotspot/share/oops/stackChunkOop.cpp line 460:

> 458:     } else {
> 459:       oop value = *reinterpret_cast<oop*>(at);
> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);

Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825949756
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254

From liach at openjdk.org  Fri Nov  1 15:29:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 15:29:27 GMT
Subject: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205
In-Reply-To: <6RSxcb_9ZihmeSIp78EF85MF0BOiRZ4resuNOfS_qnk=.9790d2ad-9f8a-4639-b340-0744c7ac2762@github.com>
References: <6RSxcb_9ZihmeSIp78EF85MF0BOiRZ4resuNOfS_qnk=.9790d2ad-9f8a-4639-b340-0744c7ac2762@github.com>
Message-ID: <XJsQfNkVifl2_Lx-zl9Jb5DNFVq8cHZzahTTNBs4Onw=.8ee7b0d7-4bf5-4e21-9470-3a005b8e4591@github.com>

On Fri, 1 Nov 2024 15:03:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> JDK-8339205 introduced multiple regressions in StackMapGenerator and added a lot of new untested code.
> 
> This patch reverts StackMapGenerator to the state before JDK-8339205 and adds one regression test.
> 
> Please review.
> 
> Thanks,
> Adam

Looks good.  For the future, do we want to expand this test to cover more instructions, or is this just added for the particular bug?

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21835#pullrequestreview-2410298707

From liach at openjdk.org  Fri Nov  1 15:30:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 15:30:38 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <N4udecFYGdBn2uPJgAJbHViJomzTPecxTffp1mRG5yE=.e8457c9f-e47b-4c00-bb1e-1ced8b985101@github.com>

On Wed, 16 Oct 2024 16:23:41 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

test/jdk/tools/sincechecker/jdk_compiler/CheckSince_jdkCompiler.java line 27:

> 25:  * @test
> 26:  * @bug 8341399
> 27:  * @summary Test for `@since` for java.base module

You forgot to change the summaries but remembered to change the `@run` directives. Curious!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21542#discussion_r1825957173

From asotona at openjdk.org  Fri Nov  1 15:38:26 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 15:38:26 GMT
Subject: RFR: 8343436: Regression in StackMapGenerator after JDK-8339205
In-Reply-To: <6RSxcb_9ZihmeSIp78EF85MF0BOiRZ4resuNOfS_qnk=.9790d2ad-9f8a-4639-b340-0744c7ac2762@github.com>
References: <6RSxcb_9ZihmeSIp78EF85MF0BOiRZ4resuNOfS_qnk=.9790d2ad-9f8a-4639-b340-0744c7ac2762@github.com>
Message-ID: <ZaWgwE9cuJj6u0nKifrSflbesvNPnpZdQOFzmqjWRz4=.b5550d26-fdd4-410f-bd13-4afb7f102577@github.com>

On Fri, 1 Nov 2024 15:03:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> JDK-8339205 introduced multiple regressions in StackMapGenerator and added a lot of new untested code.
> 
> This patch reverts StackMapGenerator to the state before JDK-8339205 and adds one regression test.
> 
> Please review.
> 
> Thanks,
> Adam

This one test is added to cover the reported bug.
However better test coverage should be always included when statically expanding existing functionality and introducing a lot of new code. It is much smaller chance to catch the bug with existing tests, when each new method is handling only very small set of cases.
Also overriding fields with local variables with modified values is very bad practice.

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

PR Comment: https://git.openjdk.org/jdk/pull/21835#issuecomment-2452083528

From nbenalla at openjdk.org  Fri Nov  1 15:39:29 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 1 Nov 2024 15:39:29 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
In-Reply-To: <N4udecFYGdBn2uPJgAJbHViJomzTPecxTffp1mRG5yE=.e8457c9f-e47b-4c00-bb1e-1ced8b985101@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
 <N4udecFYGdBn2uPJgAJbHViJomzTPecxTffp1mRG5yE=.e8457c9f-e47b-4c00-bb1e-1ced8b985101@github.com>
Message-ID: <EhKxhDU85YecjnHvz_aztminnVpBeeAKnyKDUq47OvU=.27d7c5dc-595c-4bc4-85c2-7594f6756f53@github.com>

On Fri, 1 Nov 2024 15:28:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
>> 
>> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
>> 
>> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
>> 
>> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
>> 
>> TIA
>
> test/jdk/tools/sincechecker/jdk_compiler/CheckSince_jdkCompiler.java line 27:
> 
>> 25:  * @test
>> 26:  * @bug 8341399
>> 27:  * @summary Test for `@since` for java.base module
> 
> You forgot to change the summaries but remembered to change the `@run` directives. Curious!

Nice catch! I'll update them

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21542#discussion_r1825966738

From ihse at openjdk.org  Fri Nov  1 15:46:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 15:46:56 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v16]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <X-W5xpLJavtod2GFKfnRm8CDWgjcpiJde9NDq00JIcU=.b88eb238-28a6-4bb1-a7dc-5c07f920a295@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  No need to check for LP64 inside a #ifdef _WINDOWS anymore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/0fff0971..fe8ba082

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=14-15

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

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

From ihse at openjdk.org  Fri Nov  1 15:46:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 15:46:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
Message-ID: <ZvX86_z9vXhkAYeLLm_uj2RwRvsii-DdQgffQc6Smk4=.0a8ca866-0f7e-4df5-b217-1a55228f313e@github.com>

On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Error in os_windows.cpp for unknown cpu
>
> `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes

@vnkozlov 

> There is useless code in src/hotspot/cpu//x86/interpreterRT_x86_32.cpp which is guarded by #ifdef AMD64 which is false for 32-bit.

Yes; this has been discussed above. Aleksey opened https://bugs.openjdk.org/browse/JDK-8343167 to solve that separately, since it is not Windows 32-bit specific.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452093887

From nbenalla at openjdk.org  Fri Nov  1 15:51:10 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 1 Nov 2024 15:51:10 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v2]
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <rtieLAPRPfNnR3NOdwrdDYfk7Ee3kM99TxHgfTtu64o=.1d8042be-2561-4163-a09d-5f5e7e2df86e@github.com>

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

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

 - remove redundant line
 - Merge remote-tracking branch 'upstream/master' into since-checks-langtools
 - fix test summary, add jshell module
 - Add since checker tests to other modules

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21542/files
  - new: https://git.openjdk.org/jdk/pull/21542/files/e81c2851..d8590019

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

  Stats: 100190 lines in 1847 files changed: 33821 ins; 61786 del; 4583 mod
  Patch: https://git.openjdk.org/jdk/pull/21542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21542/head:pull/21542

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

From nbenalla at openjdk.org  Fri Nov  1 15:51:10 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 1 Nov 2024 15:51:10 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v2]
In-Reply-To: <EhKxhDU85YecjnHvz_aztminnVpBeeAKnyKDUq47OvU=.27d7c5dc-595c-4bc4-85c2-7594f6756f53@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
 <N4udecFYGdBn2uPJgAJbHViJomzTPecxTffp1mRG5yE=.e8457c9f-e47b-4c00-bb1e-1ced8b985101@github.com>
 <EhKxhDU85YecjnHvz_aztminnVpBeeAKnyKDUq47OvU=.27d7c5dc-595c-4bc4-85c2-7594f6756f53@github.com>
Message-ID: <7uiCTvl_pHCRxd3nYHsVg5wgGTmG2lKR5md7zabzuUI=.978646c0-69c4-4ebf-919f-f2d7a17fe9cb@github.com>

On Fri, 1 Nov 2024 15:36:59 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> test/jdk/tools/sincechecker/jdk_compiler/CheckSince_jdkCompiler.java line 27:
>> 
>>> 25:  * @test
>>> 26:  * @bug 8341399
>>> 27:  * @summary Test for `@since` for java.base module
>> 
>> You forgot to change the summaries but remembered to change the `@run` directives. Curious!
>
> Nice catch! I'll update them

Fixed and also added a test for `jdk.jshell`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21542#discussion_r1825978307

From ihse at openjdk.org  Fri Nov  1 15:55:39 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 15:55:39 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>
Message-ID: <sFemwHDEC-n1yJwrzOmAJHR2Go5YIqi187t38m_Buhk=.a5163f69-d1c7-470b-9137-ef0bd1f86a7c@github.com>

On Wed, 30 Oct 2024 19:37:47 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> Bug in macroAssembler_x86.cpp - should be _WINDOWS

So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452112264

From dl at openjdk.org  Fri Nov  1 16:00:37 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 1 Nov 2024 16:00:37 GMT
Subject: RFR: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <iqE6Q2BqMKtM-2k8sh_rYoxvXbnuf6DKrt2KIGtiXYk=.38bc7ee4-6492-4b49-b7ae-34d0a070a964@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

Looks good; thanks for spotting and fixing this!

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

PR Comment: https://git.openjdk.org/jdk/pull/21783#issuecomment-2452120136

From ihse at openjdk.org  Fri Nov  1 16:04:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:04:55 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
 - Remove windows-32-bit code in CompilerConfig::ergo_initialize

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/fe8ba082..68d6fe5a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=15-16

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

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

From ihse at openjdk.org  Fri Nov  1 16:04:55 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:04:55 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <pPwK5NkUJV-mXas1UuxIW3pQW0r5g_GsmlOH3fiqLV4=.14846330-0423-4197-a7e3-0bb0f6d82cd6@github.com>
Message-ID: <Y585KrkQYx3x1yODXG7iY--AYSguo2hiH-7X8rLet-Y=.9627af5f-b665-4259-8483-35bb1c7ec9e4@github.com>

On Wed, 30 Oct 2024 19:53:27 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes

I'm actually not sure which places you refer to here. Can you be more specific? 

(Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.)

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452127151

From ihse at openjdk.org  Fri Nov  1 16:11:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:11:31 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
Message-ID: <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>

On Tue, 29 Oct 2024 20:43:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug in filtering out -Wl,--exclude-libs,ALL

I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly.

When I try using a pre-compiled HelloWorld, the linux port works for me too.

@jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR.


ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java
public class HelloWorld {
  public static void main(String[] args) {
    System.out.println("Hello, world!");
  }
}
ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java 
ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld 
Hello, world!
ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java
Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin
Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage
ihse at sthihse:/localhome/git/jdk-ALT$

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452139764

From alanb at openjdk.org  Fri Nov  1 16:13:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Nov 2024 16:13:28 GMT
Subject: RFR: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <NtJxEOAiA6hovKhObXg5ZjBO7yrI3QmSdWjDFVQGfMI=.ab888883-a55a-40c4-82f4-52ddc5d10c91@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

A good find.

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

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21783#pullrequestreview-2410378934

From ihse at openjdk.org  Fri Nov  1 16:15:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:15:31 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
Message-ID: <sK9d8KjxfB9vA6b6k38ahfJwGEwJioen5X0QM5KnFPA=.e8224043-ebb8-4de2-9929-531877785799@github.com>

On Tue, 29 Oct 2024 20:43:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug in filtering out -Wl,--exclude-libs,ALL

My (private) criteria here have been to get a fix to the build system that can run "hello world" -- I realize that the initial implementation of a static java launcher is likely to have additional bugs that needs fixing before it can pass a similar set of JTreg tests as the normal launcher (let alone the JCK). 

So running HelloWorld.class perhaps *technically* passes this barrier, but I think that if not the source code launching works, then it is almost as bad as if not HelloWorld.class works, so I would still consider that an integration blocker for this PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452144818

From bpb at openjdk.org  Fri Nov  1 16:16:29 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 1 Nov 2024 16:16:29 GMT
Subject: RFR: 8343342: java/io/File/GetXSpace.java fails on Windows with
 CD-ROM drive
In-Reply-To: <oke6ZdAo53Bi9nM08TE7DuXQML_ZKEd7_gopABmmpCg=.77d5d71c-2574-4518-9a90-d8eb0a5e237b@github.com>
References: <oke6ZdAo53Bi9nM08TE7DuXQML_ZKEd7_gopABmmpCg=.77d5d71c-2574-4518-9a90-d8eb0a5e237b@github.com>
Message-ID: <PhwtJltgZHsvNW8siq5BDYyvLsW1QhhJWRD4IoqKuXw=.08483d32-3ecb-4609-8417-b77d8412531c@github.com>

On Thu, 31 Oct 2024 07:15:16 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

> To resolve java/io/File/GetXSpace.java failure, I fix libGetXSpace.c to use  Cygwin?s `df` to get the size for comparison if the test target drive is a CD-ROM drive.
> 
> As described in JDK-8343342, GetDiskSpaceInformationW can't get information about the size of the CD-ROM drive. 
> GetDiskFreeSpaceExW can also get information about the size of the CD-ROM drive. However, because GetDiskFreeSpaceExW is called by the File.get-X-Space methods, it seems more reasonable to compare the size got by other way than GetDiskFreeSpaceExW as a test. For this reason, I use Cygwin's `df`.
> In JDK-8298619, GetDiskSpaceInformationW was adopted instead of `df` because the size got by File.get-X-Space methods may not match the size got by `df` when per-user quotas are used. I don't think this problem applies to CD-ROM  drive, so I think we can use Cygwin's `df` for CD-ROM drive.
> 
> After fix, I ran a test on Windows Server 2019 where drive C is a normal local disk, drive D is an unmounted iso CD-ROM  drive, and drive F is an iso mounted CD-ROM drive and confirmed that it passes.
> 
> I think this fix may also resolves the similar failure reported at https://github.com/openjdk/jdk/pull/12397#issuecomment-1705164515.
> 
> Thanks

It's in my queue to review this and test it on actual hardware.

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

PR Comment: https://git.openjdk.org/jdk/pull/21799#issuecomment-2452147053

From aph at openjdk.org  Fri Nov  1 16:23:03 2024
From: aph at openjdk.org (Andrew Haley)
Date: Fri, 1 Nov 2024 16:23:03 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v7]
In-Reply-To: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
Message-ID: <bNus8x7qI2VcQhh3vrCHDrtyJUT3u0ypFd3EdWVvv4o=.b69d8399-5e1b-42f1-ac0a-c20e97f5c881@github.com>

> The fourth preview of scoped values.

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

 - Merge https://github.com/openjdk/jdk into JDK-8341903
 - Typo in comment. (Thanks, Roland!)
 - API change
 - Merge branch 'clean' into JDK-8341903
 - Scoped values
 - Scoped values
 - Fix javadoc
 - Scoped Values API changes
 - Scoped Values API changes
 - Scoped Values API changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21456/files
  - new: https://git.openjdk.org/jdk/pull/21456/files/bc3bdc10..84a436cc

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

  Stats: 115145 lines in 2059 files changed: 43921 ins; 63558 del; 7666 mod
  Patch: https://git.openjdk.org/jdk/pull/21456.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21456/head:pull/21456

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

From asotona at openjdk.org  Fri Nov  1 16:23:34 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 16:23:34 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
Message-ID: <MyDELcrkBSGRLWaSH1SiBLCbRUQ1j-4RjRYxht3Wlq8=.b29108c1-a430-4c90-945c-9107977bddd9@github.com>

On Wed, 30 Oct 2024 13:01:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a partial implementation of JEP 495 - adjustments of the JEP metadata in `PreviewFeature`. There are no language changes associated with this JEP. Changes to the `java.io.IO` class are covered by https://github.com/openjdk/jdk/pull/21693.

Looks good to me.

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21787#pullrequestreview-2410400307

From asotona at openjdk.org  Fri Nov  1 16:25:38 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 1 Nov 2024 16:25:38 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v3]
In-Reply-To: <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
Message-ID: <PJMzwrFb7FB7XTAUr9oOP4m8XVJLSQw80TqN8sni9vo=.eafc1ea9-b7cb-4bcd-8d89-bab16dcc56cc@github.com>

On Tue, 29 Oct 2024 08:13:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR is simply adding parameter-less `java.io.IO.{println(),readln()}`, with the (hopefully) obvious semantics, plus the corresponding wiring to make those work. This may become part of JEP 495:
>> https://openjdk.org/jeps/495
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test for Console.readln/readLine, ensuring the proper methods are called.

Marked as reviewed by asotona (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21693#pullrequestreview-2410405267

From ihse at openjdk.org  Fri Nov  1 16:25:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:25:59 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into static-jdk-image
 - Fix bug in filtering out -Wl,--exclude-libs,ALL
 - Don't hardcode server variant
 - Setup LDFLAGS_STATIC_JDK
 - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
 - Add lookup asserts
 - Remove superfluous SRC.
 - Merge branch 'master' into static-jdk-image
 - Makefile changes needed for static-launcher and static-jdk-image targets
 - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher

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

Changes: https://git.openjdk.org/jdk/pull/20837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=08
  Stats: 447 lines in 26 files changed: 367 ins; 5 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

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

From alanb at openjdk.org  Fri Nov  1 16:27:32 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 1 Nov 2024 16:27:32 GMT
Subject: RFR: 8341903: Implementation of Scoped Values (Fourth Preview)
 [v7]
In-Reply-To: <bNus8x7qI2VcQhh3vrCHDrtyJUT3u0ypFd3EdWVvv4o=.b69d8399-5e1b-42f1-ac0a-c20e97f5c881@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
 <bNus8x7qI2VcQhh3vrCHDrtyJUT3u0ypFd3EdWVvv4o=.b69d8399-5e1b-42f1-ac0a-c20e97f5c881@github.com>
Message-ID: <tns5eVqgStci_uqguZC7RH1_264WVYJQANMAecof0h4=.fb9e383a-9dae-40b1-9461-a036f34f8d4e@github.com>

On Fri, 1 Nov 2024 16:23:03 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> The fourth preview of scoped values.
>
> Andrew Haley has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - Merge https://github.com/openjdk/jdk into JDK-8341903
>  - Typo in comment. (Thanks, Roland!)
>  - API change
>  - Merge branch 'clean' into JDK-8341903
>  - Scoped values
>  - Scoped values
>  - Fix javadoc
>  - Scoped Values API changes
>  - Scoped Values API changes
>  - Scoped Values API changes

Marked as reviewed by alanb (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21456#pullrequestreview-2410408387

From ihse at openjdk.org  Fri Nov  1 16:33:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 16:33:30 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <yDZJc66GqRWwaNORthZ6yepgT6iJPCI29-l_opf33OI=.a310dfa1-11a2-4243-8ed4-2adae0e878ee@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <yDZJc66GqRWwaNORthZ6yepgT6iJPCI29-l_opf33OI=.a310dfa1-11a2-4243-8ed4-2adae0e878ee@github.com>
Message-ID: <0q-xhL4V8lDNxWwXXhgHM-iMXuwd1bRbKxbZgLiL-MU=.c1c22ded-60ec-442c-85fb-4155c417b930@github.com>

On Wed, 23 Oct 2024 08:23:34 GMT, Johan Vos <jvos at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Don't hardcode server variant
>
> I tried to build/run this on Linux as well (since I'm using parts of this PR in https://github.com/openjdk/mobile/pull/30) and I noticed that the executable doesn't start (even with --version):
> 
> images/static-jdk/bin/java --version
> Error: Failed , because images/static-jdk/bin/java: undefined symbol: JNI_CreateJavaVM
> 
> The `JNI_CreateJavaVM` symbol seems to be local only:
> 
> nm images/static-jdk/bin/java |grep JNI_CreateJ
> 0000000000e22430 t JNI_CreateJavaVM
> 
> Hence calling it with `dlsym` won't work. And indeed, that is how it is called from `./java.base/unix/native/libjli/java_md.c ` `(LoadJavaVM)`
> 
> dlsym(libjvm, "JNI_CreateJavaVM");
> 
> 
> I noticed that the launcher is created using `-Wl,--export-dynamic ... -Wl,--whole-archive ... libjvm.a`
> I checked `libjvm.a` and as expected, that contains a global symbol for JNI_CreateJavaVM:
> 
> nm libjvm.a |grep JNI_CreateJavaVM
> 0000000000000000 T JNI_CreateJavaVM
> 
> If I remove the `-Wl,--export-dynamic` from the link options, the resulting executable has a global symbol for JNI_createJavaVM. However, in that case `dlsym` will clearly not work because the symbol is not added to the symbol table.
> 
> This is maybe a stupid question, but I wonder though why `dlsym` is used here? 
> When doing this for iOS, I directly use the symbols (instead of searching for them using `dlsym`). We know for sure that this symbol is in the executable, as it is statically linked into it.

@johanvos 

There is indeed no reason to use dlsym for a static build. Unfortunately, the code related to looking up symbols in JDK-internal libraries is still not up to par. It is scattered among several places, and each place is doing its own implementation. I was thinking that cleaning this up could be done as a follow-up, later on, but maybe it is necessary to take the bull by the horns and address all those places in this PR as well. Many of them are already touched by this PR anyway...

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452177592

From jlu at openjdk.org  Fri Nov  1 16:37:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Nov 2024 16:37:33 GMT
Subject: RFR: 8343236: Use @apiNote and @implSpec in j.util.Currency [v2]
In-Reply-To: <2NvHXzsBqvT_RgQwlUCLW9khjqHFGQF3wtOoyc0U5eA=.36dc303f-c5fc-4557-bb7d-6c1d8958f766@github.com>
References: <HHNKr_ir5dwJqMqWChR37svmAbsBN5XWkTB3l7v_C6g=.6524c170-75c0-4b4d-83c1-b42f2a4a9f9e@github.com>
 <2NvHXzsBqvT_RgQwlUCLW9khjqHFGQF3wtOoyc0U5eA=.36dc303f-c5fc-4557-bb7d-6c1d8958f766@github.com>
Message-ID: <vn4Wf3NctuD0l5pkKEhXzpEk6SFljbj8OOoFj4ZSWJw=.812239ca-04c4-4237-a77a-612536dcccc3@github.com>

On Thu, 31 Oct 2024 19:40:06 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which aims to improve the _j.util.Currency_ specification by using `@apiNote` and `@implSpec`.
>> 
>> A corresponding CSR has been filed.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   CSR review: implNote -> implSpec

Thank you for the reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21793#issuecomment-2452184651

From jlu at openjdk.org  Fri Nov  1 16:37:33 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Nov 2024 16:37:33 GMT
Subject: Integrated: 8343236: Use @apiNote and @implSpec in j.util.Currency
In-Reply-To: <HHNKr_ir5dwJqMqWChR37svmAbsBN5XWkTB3l7v_C6g=.6524c170-75c0-4b4d-83c1-b42f2a4a9f9e@github.com>
References: <HHNKr_ir5dwJqMqWChR37svmAbsBN5XWkTB3l7v_C6g=.6524c170-75c0-4b4d-83c1-b42f2a4a9f9e@github.com>
Message-ID: <hTmH3_8NeTCSid0TFv8bjf_jU9k_ysQcGfgHLowT4DE=.a24d5bbb-47cc-4a16-98eb-d283c637a61a@github.com>

On Wed, 30 Oct 2024 20:34:04 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which aims to improve the _j.util.Currency_ specification by using `@apiNote` and `@implSpec`.
> 
> A corresponding CSR has been filed.

This pull request has now been integrated.

Changeset: ea110c35
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ea110c35f5429f1e1de57a301e2256f508a4c324
Stats:     6 lines in 1 file changed: 2 ins; 0 del; 4 mod

8343236: Use @apiNote and @implSpec in j.util.Currency

Reviewed-by: iris, lancea, bpb, naoto

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

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

From mchung at openjdk.org  Fri Nov  1 16:55:27 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 1 Nov 2024 16:55:27 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names
In-Reply-To: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
Message-ID: <ZKm5veJBF--FNaJ11cc8_o2o0t_nnxgHcvJEVtXVqEM=.929b926f-4d56-4d5d-9bf6-d88ff807adb3@github.com>

On Fri, 1 Nov 2024 13:58:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> An oversight in the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665 caused `ClassDesc` to incorrectly accept empty strings as binary names.  This patch fixes that problem, and unifies the checks for package and class nominal descriptors.

Please describe where the bug was caused and also record the evaluation explaining the cause in the issue.    Here is one part I understand for your reference.

One of the causes is that the refactoring done by JDK-8338544 converts the explicit check of the return value from `ConstantUtils::skipOverFieldSignature` called by `ClassOrInterfaceDescImpl::ofValidated` to `assert`.    The refactoring was hard to review.   So `validateBinaryClassName` only validates the binary name.  Prior to JDK-8338544, the implementation expects more validations performed from `ClassDesc::ofDescriptor`.

I think it requires a thorough understanding of what being validated before JDK-8338544 to see if anything else is missing.

I am not sure what validation of package name is regressed.  Please also explain.

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

PR Comment: https://git.openjdk.org/jdk/pull/21830#issuecomment-2452218010

From ihse at openjdk.org  Fri Nov  1 17:14:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 1 Nov 2024 17:14:34 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
Message-ID: <GG2ZY0U8Gd6QuV3JYvYflOmdsiRvqy4U0z0Tem5wdyc=.42709f17-d18f-4af2-8fce-75e057a1b251@github.com>

On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into static-jdk-image
>  - Fix bug in filtering out -Wl,--exclude-libs,ALL
>  - Don't hardcode server variant
>  - Setup LDFLAGS_STATIC_JDK
>  - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>  - Add lookup asserts
>  - Remove superfluous SRC.
>  - Merge branch 'master' into static-jdk-image
>  - Makefile changes needed for static-launcher and static-jdk-image targets
>  - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher

I'm still not sure how or why this goes wrong on Linux (or why it manages to work on macOS!), but at least with this patch I get it to work on Linux:


diff --git a/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java b/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java
index 0e3b178c32b..54db79e6527 100644
--- a/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java
+++ b/src/java.base/share/classes/jdk/internal/jimage/NativeImageBuffer.java
@@ -40,7 +40,7 @@ class NativeImageBuffer {
                 new java.security.PrivilegedAction<Void>() {
                     @SuppressWarnings("restricted")
                     public Void run() {
-                        System.loadLibrary("jimage");
+                        jdk.internal.loader.BootLoader.loadLibrary("jimage");
                         return null;
                     }
                 });


The problem here is that this file is also compiled as part of the jrtfs.jar, where `BootLoader` is not available, so I also had to do 

diff --git a/make/Main.gmk b/make/Main.gmk
index 9fc5490a1ef..606dd215e72 100644
--- a/make/Main.gmk
+++ b/make/Main.gmk
@@ -1000,7 +1000,7 @@ else
   # When creating the BUILDJDK, we don't need to add hashes to java.base, thus
   # we don't need to depend on all other jmods
   ifneq ($(CREATING_BUILDJDK), true)
-    java.base-jmod: jrtfs-jar $(addsuffix -jmod, $(filter-out java.base, $(sort \
+    java.base-jmod:  $(addsuffix -jmod, $(filter-out java.base, $(sort \
         $(foreach m, $(filter-out $(call FindAllUpgradeableModules), $(JMOD_MODULES)), \
           $m $(call FindTransitiveDepsForModules, $m) \
         ))))


to be able to compile this.

But this seems to be the wrong approach. `System.loadLibrary("jimage")` should be able to figure out that an internal, statically-linked, library is being requested. Or at least, I guess that is a reasonable approach? I searched for `System.loadLibrary` and we're doing that a lot to connect to our internal native libraries. (One alternative approach would have been that the JDK should have a separate way to load its own internal libraries, that is not exposed to user code. I was honestly a bit surprised to find out that this is not the case.)

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452258062

From liach at openjdk.org  Fri Nov  1 17:31:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 17:31:28 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names
In-Reply-To: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
Message-ID: <J1mTbY5TjWJ99NKKmTC1SIeodMrIxxyj-E2GppBnr3k=.a91767f2-73ef-484d-a11b-194e49853ede@github.com>

On Fri, 1 Nov 2024 13:58:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> An oversight in the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665 caused `ClassDesc` to incorrectly accept empty strings as binary names, so erroneous calls `ClassDesc.of("")` and `ClassDesc.ofInternalName("")` return instead of throw IllegalArgumentExceptions.  This patch fixes that problem by updating the package separator tracking in `validateBinary/InternalClassName` to closely resemble that in `skipOverFieldSignature` to prohibit empty strings, leading, trailing, or consecutive separator chars.
> 
> In addition, the package name validation erroneously does not prohibit leading, trailing or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  Make package name validation reuse class or interface name validation and added those cases to the test suite.

Before 8338544, the binary/internal name validation was partial. It missed a few validations performed by `skipOverFieldSignature`: no empty strings, leading or trailing or consecutive separator chars.  In 8338544, the empty string validation was incorrectly missed.

PackageDesc in theory should not accept leading or trailing or consecutive separator chars, just like the names of classes and interfaces do not.  Added validations for PackageDesc, so if we wish to create ClassDesc from a PackageDesc, we won't find invalid packages that cannot have classes or interfaces.

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

PR Comment: https://git.openjdk.org/jdk/pull/21830#issuecomment-2452283588

From liach at openjdk.org  Fri Nov  1 17:35:29 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 17:35:29 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v2]
In-Reply-To: <rtieLAPRPfNnR3NOdwrdDYfk7Ee3kM99TxHgfTtu64o=.1d8042be-2561-4163-a09d-5f5e7e2df86e@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
 <rtieLAPRPfNnR3NOdwrdDYfk7Ee3kM99TxHgfTtu64o=.1d8042be-2561-4163-a09d-5f5e7e2df86e@github.com>
Message-ID: <ruleJieENHn0WeM11TX-Cu1YXSEW7-xm9mig-aClNa4=.123de5b0-459e-4b46-b353-0c209d3c22b7@github.com>

On Fri, 1 Nov 2024 15:51:10 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
>> 
>> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
>> 
>> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
>> 
>> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - remove redundant line
>  - Merge remote-tracking branch 'upstream/master' into since-checks-langtools
>  - fix test summary, add jshell module
>  - Add since checker tests to other modules

Why are some test and the test for java.base in modules subdirectory, while some other jdk. module tests are not? Like `test/jdk/tools/sincechecker/modules/java_compiler/CheckSince_javaCompiler.java` vs `test/jdk/tools/sincechecker/jdk_compiler/CheckSince_jdkCompiler.java` (note `jdk_compiler` is not the a `modules` directory)

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

PR Comment: https://git.openjdk.org/jdk/pull/21542#issuecomment-2452292014

From mchung at openjdk.org  Fri Nov  1 17:38:28 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 1 Nov 2024 17:38:28 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names
In-Reply-To: <J1mTbY5TjWJ99NKKmTC1SIeodMrIxxyj-E2GppBnr3k=.a91767f2-73ef-484d-a11b-194e49853ede@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <J1mTbY5TjWJ99NKKmTC1SIeodMrIxxyj-E2GppBnr3k=.a91767f2-73ef-484d-a11b-194e49853ede@github.com>
Message-ID: <mJtga5pYkJSUnBj_FPt2li4dMeHBNP0CWZBbuu_3qo4=.469d118f-5a86-403c-a6be-5a88e594d490@github.com>

On Fri, 1 Nov 2024 17:28:28 GMT, Chen Liang <liach at openjdk.org> wrote:

> Before 8338544, the binary/internal name validation was partial. It missed a few validations performed by `skipOverFieldSignature`: no empty strings, leading or trailing or consecutive separator chars. In 8338544, the empty string validation was incorrectly missed.

With your proposed change, all validations are done by `validateBinaryClassName`?

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

PR Comment: https://git.openjdk.org/jdk/pull/21830#issuecomment-2452296917

From nbenalla at openjdk.org  Fri Nov  1 17:39:30 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 1 Nov 2024 17:39:30 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v2]
In-Reply-To: <rtieLAPRPfNnR3NOdwrdDYfk7Ee3kM99TxHgfTtu64o=.1d8042be-2561-4163-a09d-5f5e7e2df86e@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
 <rtieLAPRPfNnR3NOdwrdDYfk7Ee3kM99TxHgfTtu64o=.1d8042be-2561-4163-a09d-5f5e7e2df86e@github.com>
Message-ID: <1wMfUiWMoMaft7aMWDZqLTxcHgLDKYqW36TPRcLOKxg=.902a4829-fb1f-496f-9ca8-d6dfe4432d84@github.com>

On Fri, 1 Nov 2024 15:51:10 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
>> 
>> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
>> 
>> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
>> 
>> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - remove redundant line
>  - Merge remote-tracking branch 'upstream/master' into since-checks-langtools
>  - fix test summary, add jshell module
>  - Add since checker tests to other modules

The tests are all meant to be under the `modules` directory, there was a problem with how subdirectories were shown in my IDE.

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

PR Comment: https://git.openjdk.org/jdk/pull/21542#issuecomment-2452297552

From dl at openjdk.org  Fri Nov  1 17:46:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 1 Nov 2024 17:46:54 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v14]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <QZrI9oTm2lvNrXhAF3LFHhE0WyZBAVrMJHNhZJQOrKc=.ed006f8f-325d-4df7-acf3-00f11bbee048@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

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

 - Merge branch 'openjdk:master' into JDK-8336707
 - Reduce shutdown overhead and contention
 - dropWaiters now back to releaseAll
 - Merge branch 'openjdk:master' into JDK-8336707
 - reduce shutdown overhead
 - For starvation check #7
 - For starvation checks #6
 - Rervert; recheck
 - For starvation check #5
 - For starvation check #4
 - ... and 22 more: https://git.openjdk.org/jdk/compare/fd15234d...b12be0e1

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/2efcb442..b12be0e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=12-13

  Stats: 50321 lines in 1032 files changed: 5717 ins; 41260 del; 3344 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

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

From mchung at openjdk.org  Fri Nov  1 17:53:53 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 1 Nov 2024 17:53:53 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <-wwepTOpM8jcjw8v3km8uDNiE2alI4c9-mleMh8NTq0=.342018e7-8b5d-45f4-928a-f5dbca380dae@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <-wwepTOpM8jcjw8v3km8uDNiE2alI4c9-mleMh8NTq0=.342018e7-8b5d-45f4-928a-f5dbca380dae@github.com>
Message-ID: <UX4UX6yxyVceYqCRk4nt9VjxU4MP_krP5z_4Gt3OM8k=.347bd2f9-0e94-4e24-b380-ead888c50afa@github.com>

On Thu, 31 Oct 2024 22:25:04 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> Many tests failed in compiling test library `test/jdk/tools/lib/tests/JImageValidator.java` as it depends on the ClassFile API and preview needs to be enabled.

It looks like my environment issue.   They all pass for me now.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2452319723

From kvn at openjdk.org  Fri Nov  1 17:55:41 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 1 Nov 2024 17:55:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v15]
In-Reply-To: <sFemwHDEC-n1yJwrzOmAJHR2Go5YIqi187t38m_Buhk=.a5163f69-d1c7-470b-9137-ef0bd1f86a7c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <xsAteC7JWLhmu3YLu5VSyRo-1BO4JBOmbjl4YwxfEd0=.c9d719ce-c10b-4ea0-bbd4-5e91768b90be@github.com>
 <76biejW3S4MlZgDqNgarB8X1Fg_r1nnquUs5YvpeyYU=.663fe887-f273-4159-bb7f-89fad204eb28@github.com>
 <sFemwHDEC-n1yJwrzOmAJHR2Go5YIqi187t38m_Buhk=.a5163f69-d1c7-470b-9137-ef0bd1f86a7c@github.com>
Message-ID: <xX7oGwHEdEU6DdTfgEI9j5dePvA77d5amR3Hefjl6KQ=.cf304223-330d-49f2-b7ae-c1fb90b886f4@github.com>

On Fri, 1 Nov 2024 15:52:50 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > Bug in macroAssembler_x86.cpp - should be _WINDOWS
> 
> So what does that mean? That the code is currently broken and is incorrectly included on Windows? If so, it should be fixed in a separate PR. Or is it just a stylistic issue, that both `_WINDOWS` and `WINDOWS` are defined when building hotspot on Windows, but the rule is to stick to `_WINDOWS`? If so, I can sneak in a fix for it here, even if it is not really part of the x86 removal.

I think `WINDOWS` is not defined in our build macros. I filed https://bugs.openjdk.org/browse/JDK-8343452 to fix it and backport.

> > `grep -i win32 -r src/hotspot/share/` shows several places missed in these changes
> 
> I'm actually not sure which places you refer to here. Can you be more specific?
> 
> (Note that, oddly enough, `_WIN32` is still defined on 64-bit Windows, Microsoft considers "win32" to be the general name of the Windows API.)


% grep -i win32 -r src/hotspot/share/ 
src/hotspot/share//c1/c1_Compiler.cpp:  // compilation seems to be too expensive (at least on Intel win32).
src/hotspot/share//runtime/globals.hpp:          "Using high time resolution (for Win32 only)")                    \
src/hotspot/share//runtime/globals.hpp:          "Bypass Win32 file system criteria checks (Windows Only)")        \
src/hotspot/share//runtime/globals.hpp:          "Unguard page and retry on no-execute fault (Win32 only) "        \
src/hotspot/share//runtime/javaCalls.cpp:  // This is used for e.g. Win32 structured exception handlers.
src/hotspot/share//runtime/safefetch.hpp:#ifdef _WIN32
src/hotspot/share//runtime/os.hpp:  class win32;
src/hotspot/share//runtime/vmStructs.cpp:  /* unsigned short on Win32 */                                           \
src/hotspot/share//runtime/vmStructs.cpp:  // Win32, we can put this back in.
src/hotspot/share//runtime/park.cpp:// Native TLS (Win32/Linux/Solaris) can only be initialized or
src/hotspot/share//runtime/sharedRuntimeTrans.cpp:// by roughly 15% on both Win32/x86 and Solaris/SPARC.
src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
src/hotspot/share//runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
src/hotspot/share//prims/jvmti.xml:      example, in the Java 2 SDK a CTRL-Break on Win32 and a CTRL-\ on Linux
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//prims/jni.cpp:#if defined(_WIN32) && !defined(USE_VECTORED_EXCEPTION_HANDLING)
src/hotspot/share//classfile/javaClasses.cpp:#if defined(_WIN32) && !defined(_WIN64)
src/hotspot/share//classfile/compactHashtable.cpp:#ifndef O_BINARY       // if defined (Win32) use binary files.
src/hotspot/share//cds/filemap.cpp:#ifndef O_BINARY       // if defined (Win32) use binary files.
src/hotspot/share//utilities/vmError.cpp:#ifndef _WIN32
src/hotspot/share//adlc/adlc.hpp:#ifdef _WIN32
src/hotspot/share//adlc/adlc.hpp:#endif // _WIN32
src/hotspot/share//adlc/main.cpp:#if !defined(_WIN32) || defined(_WIN64)
src/hotspot/share//compiler/disassembler.cpp:#ifdef _WIN32

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452318589
PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452322471

From kvn at openjdk.org  Fri Nov  1 18:04:44 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 1 Nov 2024 18:04:44 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <qof8GPRZ7SEfAZIx94XqCQX-yFCXy2A-ooZqLdsYV2k=.a62af9ab-1f10-4ce3-b8e0-7bf42baca07d@github.com>

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

1. There is use of `WIN32` instead of `_WIN32`.
2. There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion.
3. There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE.
4. "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452335968

From nbenalla at openjdk.org  Fri Nov  1 18:05:05 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 1 Nov 2024 18:05:05 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v3]
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <cvyYjmb12rnC7TnIZiiovA4lo9m688P3uBPJx6Q49kc=.99c55e38-0f73-4af2-a0ae-50394bc443f8@github.com>

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  since checks should be under modules directory

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21542/files
  - new: https://git.openjdk.org/jdk/pull/21542/files/d8590019..408ae6d7

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

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

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

From mchung at openjdk.org  Fri Nov  1 18:05:45 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 1 Nov 2024 18:05:45 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <n2hkylB3HsgWYwZ37GvdJe2SAEX-c9geJJtSN_8NiYY=.20707bda-2fd7-4e09-b42d-319407f40ac6@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <n2hkylB3HsgWYwZ37GvdJe2SAEX-c9geJJtSN_8NiYY=.20707bda-2fd7-4e09-b42d-319407f40ac6@github.com>
Message-ID: <hAQ0t6h7-4RW0a43Jsn0o9AwJzFoDoOKsXm7OhlmcLY=.f5980637-2622-4d0c-8481-cdbc4ef46572@github.com>

On Fri, 1 Nov 2024 01:26:44 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I expect that the jmodless tests will first build an image (say `image1`) using jlink `--generate-linkable-runtime` option and then verify `image1/bin/jlink` that links from the run-time image. I don't see `--generate-linkable-runtime` option is used from jmodless tests. I looked at `AbstractLinkableRuntimeTest` which provides the support to create linkable runtime image but not obvious to me. Can you describe the idea of this test framework?

OK.  I see this now (`@requires jlink.runtime.linkable` in all jmodless tests).  I.e. No test for the default JDK build.

I think this feature needs test verification even for the default JDK build.   One way to do that is to build a test image (say `base-image`) using jlink `--generate-linkable-runtime` option and then verify `base-image/bin/jlink` instead of the JDK.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2452337769

From rgiulietti at openjdk.org  Fri Nov  1 18:07:01 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Nov 2024 18:07:01 GMT
Subject: RFR: 8343453: Modernize FloatingDecimal tests
Message-ID: <WjnZQkldHSP1qqSvR00nM7vtLhh2-XGrajwcejgY1qM=.482cd2d4-4e42-4d03-9fa3-43f3ace94f5a@github.com>

Simplify tests.

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

Commit messages:
 - Merge branch 'master' into 8343453
 - 8343453: Modernize FloatingDecimal tests

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

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

From rgiulietti at openjdk.org  Fri Nov  1 18:07:01 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Nov 2024 18:07:01 GMT
Subject: RFR: 8343453: Modernize FloatingDecimal tests
In-Reply-To: <WjnZQkldHSP1qqSvR00nM7vtLhh2-XGrajwcejgY1qM=.482cd2d4-4e42-4d03-9fa3-43f3ace94f5a@github.com>
References: <WjnZQkldHSP1qqSvR00nM7vtLhh2-XGrajwcejgY1qM=.482cd2d4-4e42-4d03-9fa3-43f3ace94f5a@github.com>
Message-ID: <2ChdTJEgC0omp8-gvpdqS4uLQadViaapUisA5xpX0_g=.d235c629-0368-4483-980b-c15fe8c52202@github.com>

On Fri, 1 Nov 2024 18:01:18 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Simplify tests.

See the JBS issue for details.

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

PR Comment: https://git.openjdk.org/jdk/pull/21840#issuecomment-2452338486

From nbenalla at openjdk.org  Fri Nov  1 18:10:03 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 1 Nov 2024 18:10:03 GMT
Subject: RFR: 8343071: Broken anchors to restricted method page and some
 redundant ids
Message-ID: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>

Can I get a review for this patch that brings the last changes to fix broken anchors in the source code.

The links updated in this patch can be grouped into 3 sections, they were minor so I grouped them into one PR.

1- Move some references from the old `foreign/package-summary.html#restricted` to the new `Restricted Methods` page, these were broken after https://github.com/openjdk/jdk/commit/f4dccfd4cf354f360b823c8cce15bb54ef90e9ca

2- Remove a redundant `<a>` tag in `Class.java`, the id not needed as we already created an index.

3- Fix some broken anchors in `StructuredTaskScope.java`, the text will be updated in a JEP but we can fix the current text now. 

Thanks!

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

Commit messages:
 - fix various links

Changes: https://git.openjdk.org/jdk/pull/21839/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21839&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343071
  Stats: 7 lines in 4 files changed: 0 ins; 0 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21839.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21839/head:pull/21839

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

From kvn at openjdk.org  Fri Nov  1 18:13:58 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 1 Nov 2024 18:13:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Okay, I am confuse about `_WIN32` vs `WIN32`. 

You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32`
And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2452349567

From rgiulietti at openjdk.org  Fri Nov  1 18:15:47 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 1 Nov 2024 18:15:47 GMT
Subject: RFR: 8343453: Modernize FloatingDecimal tests [v2]
In-Reply-To: <WjnZQkldHSP1qqSvR00nM7vtLhh2-XGrajwcejgY1qM=.482cd2d4-4e42-4d03-9fa3-43f3ace94f5a@github.com>
References: <WjnZQkldHSP1qqSvR00nM7vtLhh2-XGrajwcejgY1qM=.482cd2d4-4e42-4d03-9fa3-43f3ace94f5a@github.com>
Message-ID: <oC6tFpJ5Nv0bq15wCCRJQDOtrbgJZQL590ZbJQ1Gn1M=.90f7749d-b2b2-4316-ac6c-8977d9da3fea@github.com>

> Simplify tests.

Raffaello Giulietti has updated the pull request incrementally with one additional commit since the last revision:

  Remove test jdk/jdk/internal/math/ToString.java as well.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21840/files
  - new: https://git.openjdk.org/jdk/pull/21840/files/53496174..e1f8b895

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

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

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

From pchilanomate at openjdk.org  Fri Nov  1 18:19:20 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:19:20 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v26]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <glhsL1_7cEL9eimWvI0jzYJZFcbSdVW0KiikTxvVNW4=.06978271-02cd-4fb1-91b6-042687b606d3@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 61 commits:

 - Fix comments for David
 - Add comment in X509TrustManagerImpl.java
 - Remove oop clearing in transfer_lockstack + pass _barriers as argument
 - Merge branch 'master' into JDK-8338383
 - add comment to ThreadService::find_deadlocks_at_safepoint
 - Remove assignments in preempt_kind enum
 - Remove redundant assert in ObjectMonitor::VThreadEpilog
 - Comment in FreezeBase::recurse_freeze + renames in continuation.hpp
 - Explicitly pass tmp register to inc/dec_held_monitor_count + use static const in clobber_nonvolatile_registers
 - Use frame::sender_sp_offset in continuationFreezeThaw_riscv.inline.hpp
 - ... and 51 more: https://git.openjdk.org/jdk/compare/751a914b...113fb3d3

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

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25
  Stats: 9506 lines in 242 files changed: 6936 ins; 1424 del; 1146 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Fri Nov  1 18:19:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:19:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <E_2bhhPKWwlsXcXEcFM0S67WYrrXLK7cSrSEqaxJVFY=.e1ab6e11-553d-41fd-9f10-0686082402d6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
 <E_2bhhPKWwlsXcXEcFM0S67WYrrXLK7cSrSEqaxJVFY=.e1ab6e11-553d-41fd-9f10-0686082402d6@github.com>
Message-ID: <xQ12-EqaObKFPZllXD9_E3Wcb0nf4oEEGFwab-AoYPg=.9cf2aa52-cd1f-4d70-86e3-ccaced3421a8@github.com>

On Fri, 1 Nov 2024 15:21:50 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add comment to ThreadService::find_deadlocks_at_safepoint
>>  - Remove assignments in preempt_kind enum
>
> src/hotspot/share/oops/stackChunkOop.cpp line 445:
> 
>> 443: 
>> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
>> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
> 
> Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 
> 
> There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

Good, passed as argument now.

> src/hotspot/share/oops/stackChunkOop.cpp line 460:
> 
>> 458:     } else {
>> 459:       oop value = *reinterpret_cast<oop*>(at);
>> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
> 
> Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
> So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

Ok, I just omitted clearing the oop.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826149674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888

From pchilanomate at openjdk.org  Fri Nov  1 18:24:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:24:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v22]
In-Reply-To: <fXBcPJW3drIVISiB_7H70owy34P-9cbHdM_PI1InV1I=.e0bf7ca0-4e12-4182-959a-9f93c73a117b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <u9HkNDKJ3-wM0WRFe7I_SJVhqh-CH2tzF7dXNkknNGs=.eee0a2ec-7bd5-47e1-a440-98178fd65b5e@github.com>
 <0C6Y-BWqBlPx6UG8W9NS6TsDuAEmZya4dqtY8E8ymX4=.c45ec952-7387-4ce8-aa5a-f294347f0555@github.com>
 <fXBcPJW3drIVISiB_7H70owy34P-9cbHdM_PI1InV1I=.e0bf7ca0-4e12-4182-959a-9f93c73a117b@github.com>
Message-ID: <cbf7sd9t-JRpuKIcvoZXbga78_Uwu_mqHYxoto2prGs=.40966aac-9897-4568-8019-4e46115f8a1d@github.com>

On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:
>> 
>>> 55:     static {
>>> 56:         try {
>>> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);
>> 
>> Why is this needed?  A comment would help.
>
> That's probably a good idea.  It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority.

Added comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929

From pchilanomate at openjdk.org  Fri Nov  1 18:24:52 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:24:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v25]
In-Reply-To: <zAfnvgKNOg378M1__ONAqpzOPzrV0KqeL4YhQEv9OS4=.4edddfa1-ca46-48db-bce2-7ee4ab93b463@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <0fb3tGmN5Rl_9vsp0_DMs14KItBXRJ6xMKxQoHPc94I=.d363cc0a-5cd7-4281-86a9-1fa796c52437@github.com>
 <zAfnvgKNOg378M1__ONAqpzOPzrV0KqeL4YhQEv9OS4=.4edddfa1-ca46-48db-bce2-7ee4ab93b463@github.com>
Message-ID: <f4ZgITHm9pgiBkVpXqBXvnlwcG0H0v_uB4jrxo-jsCw=.e29b33d5-46a4-4886-ab08-41b57be1bacc@github.com>

On Fri, 1 Nov 2024 01:53:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - add comment to ThreadService::find_deadlocks_at_safepoint
>>  - Remove assignments in preempt_kind enum
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:
> 
>> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
>> 888:   } else {
>> 889:     // frame can't be freezed. Most likely the call_stub or upcall_stub
> 
> Suggestion:
> 
>     // Frame can't be frozen. Most likely the call_stub or upcall_stub

Fixed.

> src/hotspot/share/services/threadService.cpp line 467:
> 
>> 465:         if (waitingToLockMonitor->has_owner()) {
>> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
>> 467:           // If currentThread is nullptr we would like to know if the owner
> 
> Suggestion:
> 
>           // If currentThread is null we would like to know if the owner

Fixed.

> src/hotspot/share/services/threadService.cpp line 474:
> 
>> 472:           // vthread we never record this as a deadlock. Note: unless there
>> 473:           // is a bug in the VM, or a thread exits without releasing monitors
>> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.
> 
> Suggestion:
> 
>           // acquired through JNI, null should imply an unmounted vthread owner.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826154797
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815

From liach at openjdk.org  Fri Nov  1 18:28:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 18:28:27 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names
In-Reply-To: <mJtga5pYkJSUnBj_FPt2li4dMeHBNP0CWZBbuu_3qo4=.469d118f-5a86-403c-a6be-5a88e594d490@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <J1mTbY5TjWJ99NKKmTC1SIeodMrIxxyj-E2GppBnr3k=.a91767f2-73ef-484d-a11b-194e49853ede@github.com>
 <mJtga5pYkJSUnBj_FPt2li4dMeHBNP0CWZBbuu_3qo4=.469d118f-5a86-403c-a6be-5a88e594d490@github.com>
Message-ID: <i5I-O3yC6z2LfljskPdu9n7g_ACABS5bvEuLWJJm38c=.672d00ea-5b7f-4d1d-beb8-4f91cba30aa4@github.com>

On Fri, 1 Nov 2024 17:36:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> With your proposed change, all validations are done by `validateBinaryClassName`?

Yes.  Now all validations are done by that and `validateInternalClassName`, which uses the `/` separator instead of the `.` separator char.  Meanwhile, the package name validation delegates to those two, and additionally permits the unnamed package represented by an empty string.

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

PR Comment: https://git.openjdk.org/jdk/pull/21830#issuecomment-2452370608

From pchilanomate at openjdk.org  Fri Nov  1 18:29:49 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:29:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v7]
In-Reply-To: <nFePukqky1dSO4k6jQ80MnMTU_xHHVMfXWgiYjH7xBc=.fa46d919-64bf-485d-8b28-d4f4302f5b56@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <zjh2NOa8S_vbfeLgjbhCCHBuetVbSd5izmu3RwF689s=.b20b267b-b595-4bd6-a99c-df1dcd24e2dd@github.com>
 <oCz_JduIx3WAawWsBC8_oMFssh3rDBupnndzyVret7U=.5b4a7635-8919-46d4-a5ac-2ba1622d16e4@github.com>
 <DwXJpf1Za50tDYEL50zRihiH2ZNG6pWFm9WL53-BGyg=.51d15a8a-4218-4e65-bd9b-49f41a618cb5@github.com>
 <PEZBf7HmKJM90FvYDNlfAZ1zbvRTpP6J--zFspzMEOo=.af3a83d8-932f-44da-aa9d-7b510ea84610@github.com>
 <nFePukqky1dSO4k6jQ80MnMTU_xHHVMfXWgiYjH7xBc=.fa46d919-64bf-485d-8b28-d4f4302f5b56@github.com>
Message-ID: <eQsNuW1dYTC5Jth_rKACj76kGFv3ShNY0hP525XOIM8=.8d6d5d7e-0a48-43a2-9caa-a8b2a684e3a7@github.com>

On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks for the explanation but that needs to be documented somewhere.
>
> The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in.

Brought the comment from the loom repo.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691

From prr at openjdk.org  Fri Nov  1 18:46:57 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 1 Nov 2024 18:46:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

make/modules/jdk.accessibility/Lib.gmk line 57:

> 55:   TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
> 56: 
> 57:   ##############################################################################

Most of the desktop related changes are related to Assistive Technologies
I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something.
The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT.

So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826177047

From pchilanomate at openjdk.org  Fri Nov  1 18:47:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 18:47:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v27]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <CZQmDqaeoz76pMRNejHdpcbTg-o_PTENxGtTxVYHpGg=.6995864d-89ad-4f82-a011-b0ca2c8e0f72@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Revert fixes after 8343132

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/113fb3d3..33eb6388

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=25-26

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

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

From eirbjo at gmail.com  Fri Nov  1 19:11:22 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 1 Nov 2024 20:11:22 +0100
Subject: RFD: "equal" vs "equivalent" in Float.NaN, Double.NaN
Message-ID: <CA+pBWhsBx5_h0mfu_Q8ZMf35L6hQyvcHseYc-c38h7ra_ZtSSA@mail.gmail.com>

Hi,

Just an observation from a floating point layman:

I noticed that Float and Double uses "It is equal to the value.." when
describing various constant values like MIN_VALUE, MAX_VALUE etc.

However, Float.NaN and Double.NaN instead uses "equivalent to":

/**
>  * A constant holding a Not-a-Number (NaN) value of type
>  * {@code float}.  It is *equivalent* to the value returned by
>  * {@code Float.intBitsToFloat(0x7fc00000)}.
>  */
> public static final float NaN = 0.0f / 0.0f;


Is this difference in terms deliberate and justified by there being more
than one NaN bit pattern? Is the implementation allowed to return any NaN,
since all NaNs are equivalent, even when not equal?

If not, would it perhaps be more appropriate to use "equal to" here as
well?

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241101/b4755bdf/attachment.htm>

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <5_m66jOr6E-qHq5r9AHGX-Yb5IKCT_VbHGmq_Yh8v34=.172e81bb-9281-4364-a8cb-3696c5ef4b36@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

I looked through the updates to `java.desktop` module and to tests under `java/awt`, `javax/sound`, `javax/swing`.

Looks good.

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

Marked as reviewed by aivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2410517684

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <WM0Qjbvf3k3li5Xp-ygeYIhj5wnaFpdwIoRbagkDPQI=.adf5de99-50c3-40eb-9a45-b79e87a4ba39@github.com>
 <JdM98pKGFw9GA_pIiBpYy4I_I353bZu4szl6FQp_EZE=.29fe28c6-b5a2-477f-9b18-f030f201a7aa@github.com>
 <GDZ4s_P4grfrPdK5_gje0FJD9t_9bF6bmCTUQIQCloo=.4e1d32b8-1726-4020-a9e0-d0c3f3d85042@github.com>
Message-ID: <mvT1t92RTxP5hIzw4FI8nhFlY_Vv9Md6ZhT5I6jr4rc=.16f5be4b-3885-4e52-920f-7cf399e99a70@github.com>

On Thu, 24 Oct 2024 20:57:50 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> @honkar-jdk I'm inclined to leave it as because it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.
>> 
>> If it's worth taking care of, we may submit another bug to address it later.
>
> This does not need to be handled in this PR. In the majority of changes, we have really tried hard to avoid making unrelated changes, but sometimes a few snuck in, like moving package imports or perhaps fixing a typo here and there that was not specific to JEP 486. My opinion is that unless it is something that _really_ should be done as part of a more general technical debt or code cleanup exercise, then it is ok to let a few of these in and they don't have to be reverted.

> > Can we add a blank line here? It's present in the methods above.
> > 
> > Although there are other places below where it's missing; _so not worth worrying_.
>
> ? it's not the only method which doesn't have a blank line between `@param` and `@throw` in this file.
> 
> If it's worth taking care of, we may submit another bug to address it later.

I've submitted [JDK-8343448](https://bugs.openjdk.org/browse/JDK-8343448): _Improve formatting of docs in java.awt.Desktop_.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826079117

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <9rJh272Zem3qiduMHS7u3Jx1zkOjtQknwHnp-TkHq-I=.9e7b31e3-df12-4990-81e5-4e88f136b65a@github.com>
Message-ID: <BKKnlgdcwUbIGvmukmS0xfXL3JqXL6TVXwckzzdXKRk=.c68053bd-cb29-4dcc-a34b-c0a49397ff6c@github.com>

On Mon, 28 Oct 2024 14:08:46 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/Font.java line 1612:
>> 
>>> 1610:      * obtained.  The {@code String} value of this property is then
>>> 1611:      * interpreted as a {@code Font} object according to the
>>> 1612:      * specification of {@code Font.decode(String)}
>> 
>> Suggestion:
>> 
>>      * specification of {@code Font.decode(String)}.
>> 
>> Period is missing.
>
> Not part of this change, can be fixed later as a follow-on cleanup.

I've submitted [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446): _Add missing periods in docs for java.awt.Font_.

>> src/java.desktop/share/classes/java/awt/Font.java line 1780:
>> 
>>> 1778:      * <p>
>>> 1779:      * The property value should be one of the forms accepted by
>>> 1780:      * {@code Font.decode(String)}
>> 
>> Suggestion:
>> 
>>      * {@code Font.decode(String)}.
>> 
>> Period is missing.
>
> Not part of this change, can be fixed later as a follow-on cleanup.

Deferred to [JDK-8343446](https://bugs.openjdk.org/browse/JDK-8343446).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826080609
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826081342

From aivanov at openjdk.org  Fri Nov  1 19:17:12 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:17:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
 <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
Message-ID: <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>

On Mon, 28 Oct 2024 18:07:26 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used.
>> But I don't see a problem with keeping the rest of the test.
>
> Test updated in sandbox - https://github.com/openjdk/jdk-sandbox/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea

> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test.

@prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?

The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:

https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826141057

From liach at openjdk.org  Fri Nov  1 19:24:05 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 19:24:05 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]
In-Reply-To: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
Message-ID: <AEKaSqQIm4x1yPhPxkuM6QxQ5djVWtPouiBVpwAnVhk=.e18ad356-da43-450f-b76f-939b234c42a8@github.com>

> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665, the validation methods `validateBinaryClassName` and `validateInternalClassName` only checks if a separator char is the initial or final char, or if it immediately follows another chars.  This omitted the case of empty strings, and allowed creation of invalid ClassDesc with empty binary name, which is otherwise rejected by `ofDescriptor`.
> 
> To better check for the separator char, the tracking mechanism is updated to indicate a position where a separator char shouldn't appear, or where the name string should not terminate.  This is initially set to the initial position 0, and upon each time of encountering a separator, this is updated to the next char.
> 
> This logic is similar to the existing one in `skipOverFieldSignature`, which uses a boolean `legal` variable.  Both reject empty strings, leading and trailing separators, or consecutive separators.  The new logic, however, does not require repeated updates to the new `afterSeparator` variable upon scanning each character.
> 
> In addition, I noted the package name validation erroneously does not prohibit leading, trailing, or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  This patch also makes package name validation reuse class or interface name validation in non-empty (unnamed package) cases, and added those cases to the test suite.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Comments to clarify, also align skipOverFieldSignature

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21830/files
  - new: https://git.openjdk.org/jdk/pull/21830/files/79d4dd18..4325e94d

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

  Stats: 52 lines in 2 files changed: 18 ins; 11 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/21830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21830/head:pull/21830

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

From pchilanomate at openjdk.org  Fri Nov  1 19:37:14 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 1 Nov 2024 19:37:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Use lazySubmitRunContinuation when blocking

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/33eb6388..52c26642

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=26-27

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

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

From joe.darcy at oracle.com  Fri Nov  1 19:42:45 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Fri, 1 Nov 2024 12:42:45 -0700
Subject: RFD: "equal" vs "equivalent" in Float.NaN, Double.NaN
In-Reply-To: <CA+pBWhsBx5_h0mfu_Q8ZMf35L6hQyvcHseYc-c38h7ra_ZtSSA@mail.gmail.com>
References: <CA+pBWhsBx5_h0mfu_Q8ZMf35L6hQyvcHseYc-c38h7ra_ZtSSA@mail.gmail.com>
Message-ID: <a7abef5e-43d4-4f8d-a807-56190d481457@oracle.com>


On 11/1/2024 12:11 PM, Eirik Bj?rsn?s wrote:
> Hi,
>
> Just an observation from a floating?point layman:
>
> I noticed that Float and Double uses "It is equal to the value.." when 
> describing various constant values like?MIN_VALUE,?MAX_VALUE etc.


A few releases back, a discussion of "quality, equivalence, and 
comparison of floating-point values" was added to java.lang.Double:

https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Double.html#equivalenceRelation

That note discusses the topics in question.

>
> However, Float.NaN and Double.NaN instead uses "equivalent to":
>
>     /**
>     ?* A constant holding a Not-a-Number (NaN) value of type
>     ?* {@code float}.? It is /equivalent/ to the value returned by
>     ?* {@code Float.intBitsToFloat(0x7fc00000)}.
>     ?*/
>     public static final float NaN = 0.0f / 0.0f;
>
>
> Is this?difference in terms deliberate and justified by there being 
> more than one NaN bit pattern? Is the implementation allowed to return 
> any NaN, since all NaNs are?equivalent, even when not equal?


In terms of NaN, relevant factors are there are multiple bit patterns 
than encode a NaN and a NaN is not equal to itself per the IEEE 754 
standard.

HTH; cheers,

-Joe
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241101/b23143b6/attachment.htm>

From aivanov at openjdk.org  Fri Nov  1 19:43:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:43:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1:

> 1: /*

I wonder if we should add an Oracle copyright to the update test file.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826228675

From aivanov at openjdk.org  Fri Nov  1 19:43:18 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 19:43:18 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <TI0_6XwHFZ27RKbJl5Mv9juyC26zoWEWaKsVrrt9hE8=.8d35b66d-bef2-4350-add9-00b58812fe2f@github.com>
 <PZLs83o6UGHYbTZ-bfdbHEWZvlTw-6m1XekK-b1FIFo=.159f4ebe-2f0e-45ed-bba5-c9d82a592045@github.com>
 <i22WvF4FfxzMY2ugAx4DikqMwo0AD74L0HmeDgYtRtg=.e0f6a629-42fd-4de5-bec8-58daf9592d6e@github.com>
 <hQMuanOmLxrea5W1__mUTZq7vICKebkEB25t3sQVd1o=.690e336f-05b7-4a75-9094-8b4625999b07@github.com>
Message-ID: <f5IcQJqOak2nDS4qB6f3s_Dl-zHGs4g45Grph8KCe_s=.9978557c-258f-4b7f-b49a-c0595cfd2a29@github.com>

On Mon, 28 Oct 2024 14:35:57 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> That and possibly rename the test because now it does not have anything to do with the SecurityException. Now we only check that providing an empty file causes the InvalidMidiDataException so EmptySoundBankTest or something to that extent would be a better name.
>
> Fixed in https://github.com/openjdk/jdk/pull/21498/commits/934e1c28f783b32c43e6977f0e1ba6e1c68f810f

Thank you for clarification.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826225216

From dlong at openjdk.org  Fri Nov  1 20:11:50 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 1 Nov 2024 20:11:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
Message-ID: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>

On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed?
>>>
>> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method.
>
> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

Here's my suggested C2 change:

diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
index d9c77a2f529..1e99db191ae 100644
--- a/src/hotspot/cpu/aarch64/aarch64.ad
+++ b/src/hotspot/cpu/aarch64/aarch64.ad
@@ -3692,14 +3692,13 @@ encode %{
       __ post_call_nop();
     } else {
       Label retaddr;
+      // Make the anchor frame walkable
       __ adr(rscratch2, retaddr);
+      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
       __ lea(rscratch1, RuntimeAddress(entry));
-      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
-      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
       __ blr(rscratch1);
       __ bind(retaddr);
       __ post_call_nop();
-      __ add(sp, sp, 2 * wordSize);
     }
     if (Compile::current()->max_vector_size() > 0) {
       __ reinitialize_ptrue();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551

From eirbjo at gmail.com  Fri Nov  1 20:19:37 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Fri, 1 Nov 2024 21:19:37 +0100
Subject: RFD: "equal" vs "equivalent" in Float.NaN, Double.NaN
In-Reply-To: <a7abef5e-43d4-4f8d-a807-56190d481457@oracle.com>
References: <CA+pBWhsBx5_h0mfu_Q8ZMf35L6hQyvcHseYc-c38h7ra_ZtSSA@mail.gmail.com>
 <a7abef5e-43d4-4f8d-a807-56190d481457@oracle.com>
Message-ID: <CA+pBWht9w+eLn2Heeqp1fPPNn_tNiFEh6n=Ytaa+7u4Oyno5Fw@mail.gmail.com>

On Fri, Nov 1, 2024 at 8:42?PM Joseph D. Darcy <joe.darcy at oracle.com> wrote:

> A few releases back, a discussion of "quality, equivalence, and comparison
> of floating-point values" was added to java.lang.Double:
>
>
> https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Double.html#equivalenceRelation
>
> That note discusses the topics in question.
>
Thanks Joe, that's exactly what I was missing. Saying "equivalent to"
without defining the equivalence relation seems to leave room for
confusion.

I see the API note of Float/Double::equals link to this note. Do you think
it would be useful / worthwhile to add a @linkplain from the NaN
descriptions as well, like this?

     /**
      * A constant holding a Not-a-Number (NaN) value of type
-     * {@code float}.  It is equivalent to the value returned by
-     * {@code Float.intBitsToFloat(0x7fc00000)}.
+     * {@code float}.  It is {@linkplain Double##equivalenceRelation
equivalent}
+     * to the value returned by {@code Float.intBitsToFloat(0x7fc00000)}.
      */
     public static final float NaN = 0.0f / 0.0f;

Cheers,
Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241101/cbcae863/attachment.htm>

From joehw at openjdk.org  Fri Nov  1 20:30:23 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 1 Nov 2024 20:30:23 GMT
Subject: RFR: 8333582: Update CLDR to Version 46.0 [v2]
In-Reply-To: <vwyPn_mWPIeHvteo6lmkD5H27EJRXjdQlBiBKVfkbcY=.597a468f-f00b-440a-bc1e-ebbe1b20b8b2@github.com>
References: <BC9maq8cicKr97KrRECyl-I_IulD7I4N07p2hmkACuo=.217bf2ae-9a89-4e88-b7d7-78de0aa2ce89@github.com>
 <vwyPn_mWPIeHvteo6lmkD5H27EJRXjdQlBiBKVfkbcY=.597a468f-f00b-440a-bc1e-ebbe1b20b8b2@github.com>
Message-ID: <qqUqpdAB57kWkl9EIIl4CknS-kWjzyC8Hpp3wAhGhis=.facbeb7b-b4d7-4217-b874-45ff103ac843@github.com>

On Thu, 31 Oct 2024 20:06:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 46.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses review comments

Looks good to me.

test/jdk/sun/text/resources/LocaleDataTest.java line 44:

> 42:  *      8209775 8221432 8227127 8230284 8231273 8233579 8234288 8250665 8255086
> 43:  *      8251317 8274658 8283277 8283805 8265315 8287868 8295564 8284840 8296715
> 44:  *      8301206 8303472 8317979 8306116 8174269 8333582

Similar situation as TimeZoneNameTest.java? Looks like no other change than the bug id.

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

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21772#pullrequestreview-2410813842
PR Review Comment: https://git.openjdk.org/jdk/pull/21772#discussion_r1826253551

From dlong at openjdk.org  Fri Nov  1 20:30:51 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 1 Nov 2024 20:30:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.b0547cc1-5c22-4b3f-9fe2-fb57c8ef326b@github.com>

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

Marked as reviewed by dlong (Reviewer).

I finished looking at this, and it looks good.  Nice work!

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349

From aivanov at openjdk.org  Fri Nov  1 20:31:37 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 1 Nov 2024 20:31:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ZjvIinnneQEiABlGWJWgB_owcCW6csoUdmIkts6fCes=.fe83cda0-44a0-4530-8fae-8e92681ae231@github.com>
 <IDw8kJ497Hp-v9eVl7GVCmPYIauOw5LqHpmJiGN_Rxs=.6592fc82-f806-4c03-9e36-7b259aca7c04@github.com>
 <s3YCQcREuV1UNKZIW3HxX_TrbKWx5OpNfHQlB0pPOFM=.ba80ab37-3a59-4872-ab76-c04e2817ad0a@github.com>
Message-ID: <sA2jKaSsQXz3NGMICFq-okZkJV_NNcIPZgEyd-vEMio=.bcb93df4-b266-4951-87d4-a91d610ec051@github.com>

On Tue, 29 Oct 2024 12:56:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> test/jdk/javax/xml/crypto/dsig/keyinfo/KeyInfo/Marshal.java line 30:
>> 
>>> 28:  * @modules java.xml.crypto/org.jcp.xml.dsig.internal.dom
>>> 29:  * @compile -XDignore.symbol.file Marshal.java
>>> 30:  * @run main/othervm/java.security.policy==test.policy Marshal
>> 
>> With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main <test>" when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.
>> 
>> Also, missing a copyright update, will fix.
>
> Fixed in https://github.com/openjdk/jdk/pull/21498/commits/548eb9e2eb3f586bbb620d5357fe3e5665aeb505

> With this change, the test now only compiles but doesn't run the test. It could be a bug in jtreg since it is supposed to default to running the test as "run main " when there is no @run tag. In any case, the @compile line is no longer necessary, so I will remove that, and then the test will be run again.

I guess it's the intended behaviour, jtreg implies `@run` if there are no other commands; you have to provide `@run` explicitly if there are `@compile` or `@build` tags.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826256418

From naoto at openjdk.org  Fri Nov  1 20:40:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 1 Nov 2024 20:40:30 GMT
Subject: RFR: 8333582: Update CLDR to Version 46.0 [v2]
In-Reply-To: <qqUqpdAB57kWkl9EIIl4CknS-kWjzyC8Hpp3wAhGhis=.facbeb7b-b4d7-4217-b874-45ff103ac843@github.com>
References: <BC9maq8cicKr97KrRECyl-I_IulD7I4N07p2hmkACuo=.217bf2ae-9a89-4e88-b7d7-78de0aa2ce89@github.com>
 <vwyPn_mWPIeHvteo6lmkD5H27EJRXjdQlBiBKVfkbcY=.597a468f-f00b-440a-bc1e-ebbe1b20b8b2@github.com>
 <qqUqpdAB57kWkl9EIIl4CknS-kWjzyC8Hpp3wAhGhis=.facbeb7b-b4d7-4217-b874-45ff103ac843@github.com>
Message-ID: <q2s1pzJzyXxfVQ4iU58XKvbkX6CBKvWMKx015j7XSic=.bba258c3-f929-436d-9b0f-143d439029ca@github.com>

On Fri, 1 Nov 2024 20:10:02 GMT, Joe Wang <joehw at openjdk.org> wrote:

>> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Addresses review comments
>
> test/jdk/sun/text/resources/LocaleDataTest.java line 44:
> 
>> 42:  *      8209775 8221432 8227127 8230284 8231273 8233579 8234288 8250665 8255086
>> 43:  *      8251317 8274658 8283277 8283805 8265315 8287868 8295564 8284840 8296715
>> 44:  *      8301206 8303472 8317979 8306116 8174269 8333582
> 
> Similar situation as TimeZoneNameTest.java? Looks like no other change than the bug id.

There are changes in `LocaleData.cldr` data file, which is an input to this test case. Everytime the data file is modified, the bug id is recorded here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21772#discussion_r1826275066

From fbredberg at openjdk.org  Fri Nov  1 20:59:49 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Fri, 1 Nov 2024 20:59:49 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <ssUtNAUgdYvjQ_KecwfpxDRYGOfUMmTx_05x9S0U58o=.f78a1d08-115d-4027-8e8d-14552092d31d@github.com>

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks!

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

Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086

From mchung at openjdk.org  Fri Nov  1 21:42:27 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Fri, 1 Nov 2024 21:42:27 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]
In-Reply-To: <AEKaSqQIm4x1yPhPxkuM6QxQ5djVWtPouiBVpwAnVhk=.e18ad356-da43-450f-b76f-939b234c42a8@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <AEKaSqQIm4x1yPhPxkuM6QxQ5djVWtPouiBVpwAnVhk=.e18ad356-da43-450f-b76f-939b234c42a8@github.com>
Message-ID: <WH6CDWHVXfAV_latmlIBSisO4TSqTv0_MnQmyQ5oubw=.1c943e88-c636-4f81-9298-964da7143ac6@github.com>

On Fri, 1 Nov 2024 19:24:05 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665, the validation methods `validateBinaryClassName` and `validateInternalClassName` only checks if a separator char is the initial or final char, or if it immediately follows another chars.  This omitted the case of empty strings, and allowed creation of invalid ClassDesc with empty binary name, which is otherwise rejected by `ofDescriptor`.
>> 
>> To better check for the separator char, the tracking mechanism is updated to indicate a position where a separator char shouldn't appear, or where the name string should not terminate.  This is initially set to the initial position 0, and upon each time of encountering a separator, this is updated to the next char.
>> 
>> This logic is similar to the existing one in `skipOverFieldSignature`, which uses a boolean `legal` variable.  Both reject empty strings, leading and trailing separators, or consecutive separators.  The new logic, however, does not require repeated updates to the new `afterSeparator` variable upon scanning each character.
>> 
>> In addition, I noted the package name validation erroneously does not prohibit leading, trailing, or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  This patch also makes package name validation reuse class or interface name validation in non-empty (unnamed package) cases, and added those cases to the test suite.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Comments to clarify, also align skipOverFieldSignature

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 258:

> 256:         if (name.isEmpty())
> 257:             return name;
> 258:         return validateBinaryClassName(name);

Perhaps have a utility method to specify if empty name is allowed.   `validateBinaryClassName` and `validateInternalClassName` only differ in the separator charactor.   They can be refactored to call one single name validation method something like this:


    private static String validateName(String name, boolean internalName, boolean allowEmptyName) {
        if (!allowEmptyName && name.isEmpty())
              throw invalidClassName(name);
              
        // state variable for detection of illegal states, such as:
        // empty unqualified name, consecutive, leading, or trailing separators
        int afterSeparator = 0;
        int len = name.length();
        for (int i = 0; i < len; i++) {
            char ch = name.charAt(i);
            // reject ';' or '[' or other form's separator
            if (ch == ';' || ch == '[' || (internalName && ch == '.') || (!internalName && ch == '/'))
                throw invalidClassName(name);
            if ((internalName && ch == '/') || (!internalName && ch == '.')) {
                // illegal state when received separator indicates consecutive
                // or leading separators
                if (i == afterSeparator)
                    throw invalidClassName(name);
                afterSeparator = i + 1;
            }
        }
        // reject empty unqualified name or trailing separators
        if (len == afterSeparator)
            throw invalidClassName(name);
        return name;
    }

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21830#discussion_r1826315242

From asemenyuk at openjdk.org  Fri Nov  1 22:02:56 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 1 Nov 2024 22:02:56 GMT
Subject: RFR: 8340311: JPackage app-image exe launches multiple exe's in
 JDK 22+ [v3]
In-Reply-To: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
References: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
Message-ID: <aszFqPogHzdfXG9lgEo-cFWqY0hKJzB9hdHuYnTJbF0=.1b9d740a-75f0-44a6-8722-758247faadad@github.com>

> Support `win.norestart` application property in jpackage .cfg file. If found in the .cfg file and set to `true`, it forces the Windows app launcher not to restart the launcher process.
> 
> Collateral changes to the tests:
>  - Added `WindowsHelper.killProcess()` to kill process by PID;
>  - Added `WindowsHelper.findAppLauncherPID()` that will return PIDs of the running app launcher processes for the given app launcher name. The implementation grabbed from `Win8301247Test` test;
>  - Rework `CfgFile` to make it R/W and capable of writing multiple instances of the same key;
>  - Added `JPackageCommand.ignoreFakeRuntime()` to ignore external runtime if it is a stub. Should speed up local test runs.

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

 - Merge branch 'master' into JDK-8340311
 - Better log message
 - Rework findAppLauncherPID() into findAndKillAppLauncherProcess() that will kill detected running app launcher processes regardless if their number is as expected or not.
 - A comment added
 - Fix copyright year
 - fix order of modifiers
 - fix order of modifiers
 - fix order of modifiers
 - Merge branch 'master' into JDK-8340311
 - Better function names
 - ... and 5 more: https://git.openjdk.org/jdk/compare/ebebe95a...d87a5a41

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21726/files
  - new: https://git.openjdk.org/jdk/pull/21726/files/4aa56aa1..d87a5a41

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

  Stats: 48446 lines in 822 files changed: 4607 ins; 40796 del; 3043 mod
  Patch: https://git.openjdk.org/jdk/pull/21726.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21726/head:pull/21726

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

From asemenyuk at openjdk.org  Fri Nov  1 22:09:29 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 1 Nov 2024 22:09:29 GMT
Subject: RFR: 8340311: JPackage app-image exe launches multiple exe's in
 JDK 22+ [v2]
In-Reply-To: <2kSlrKqawHrUOz5YQlY0oe-rTwBqDEm3uhsL9WfrSAI=.1248b875-3d4c-4e77-8c17-0c2183b29755@github.com>
References: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
 <_c27T3RXEZoIQ3hgC72Q8tF_vMk335wsYNJ3TilvFi4=.853d0049-1c95-4046-9648-e66100a2c83d@github.com>
 <2kSlrKqawHrUOz5YQlY0oe-rTwBqDEm3uhsL9WfrSAI=.1248b875-3d4c-4e77-8c17-0c2183b29755@github.com>
Message-ID: <Txn1n9z2RXFR_SA2GajpzXdUtvMG0EZhu6TxFNdNcTw=.fdd71ccc-336c-496a-8242-29f859a5bb7e@github.com>

On Thu, 31 Oct 2024 22:32:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Better log message
>>  - Rework findAppLauncherPID() into findAndKillAppLauncherProcess() that will kill detected running app launcher processes regardless if their number is as expected or not.
>>  - A comment added
>>  - Fix copyright year
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 235:
> 
>> 233: 
>> 234:     public static void killProcess(long pid) {
>> 235:         Executor.of("taskkill", "/F", "/PID", Long.toString(pid)).dumpOutput(true).execute();
> 
> In case of two processes (parent and child) it will terminate only parent. Based on `taskkill /?` `/T` needs to be specified to terminate child process as well or call it for both processes.

It is sufficient to terminate the parent process only. The child process will be terminated automatically. Automatic app launcher child process termination was implemented in [JDK-8301247](https://bugs.openjdk.org/browse/JDK-8301247)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21726#discussion_r1826336434

From kbarrett at openjdk.org  Fri Nov  1 22:10:40 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 1 Nov 2024 22:10:40 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <0AP1wOF-MdqLdSNofINZ2JTL4nnIdVFRsZpZ1LT7oHY=.e1bb41e9-b0f4-4157-9d78-d5b819c5c1d9@github.com>

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Looks good, subject to addressing @vnkozlov comments.

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

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2410940653

From asemenyuk at openjdk.org  Fri Nov  1 22:20:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 1 Nov 2024 22:20:03 GMT
Subject: RFR: 8340311: JPackage app-image exe launches multiple exe's in
 JDK 22+ [v4]
In-Reply-To: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
References: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
Message-ID: <-Quj6usqXE2AUpmrgm-MEnDNE98kEKMtbXQ2QhoabMc=.23b280b5-4ebd-4642-b080-a9dca6fe79d8@github.com>

> Support `win.norestart` application property in jpackage .cfg file. If found in the .cfg file and set to `true`, it forces the Windows app launcher not to restart the launcher process.
> 
> Collateral changes to the tests:
>  - Added `WindowsHelper.killProcess()` to kill process by PID;
>  - Added `WindowsHelper.findAppLauncherPID()` that will return PIDs of the running app launcher processes for the given app launcher name. The implementation grabbed from `Win8301247Test` test;
>  - Rework `CfgFile` to make it R/W and capable of writing multiple instances of the same key;
>  - Added `JPackageCommand.ignoreFakeRuntime()` to ignore external runtime if it is a stub. Should speed up local test runs.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Minor cleanup

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21726/files
  - new: https://git.openjdk.org/jdk/pull/21726/files/d87a5a41..fdde7778

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

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

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

From almatvee at openjdk.org  Fri Nov  1 22:20:04 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 1 Nov 2024 22:20:04 GMT
Subject: RFR: 8340311: JPackage app-image exe launches multiple exe's in
 JDK 22+ [v4]
In-Reply-To: <-Quj6usqXE2AUpmrgm-MEnDNE98kEKMtbXQ2QhoabMc=.23b280b5-4ebd-4642-b080-a9dca6fe79d8@github.com>
References: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
 <-Quj6usqXE2AUpmrgm-MEnDNE98kEKMtbXQ2QhoabMc=.23b280b5-4ebd-4642-b080-a9dca6fe79d8@github.com>
Message-ID: <WJhpNW0ReSvh6Xe5M_TESZJKaRPd3IFoLMYFGRHaZew=.d1b79c01-7db0-4942-9576-7b08222be528@github.com>

On Fri, 1 Nov 2024 22:17:21 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Support `win.norestart` application property in jpackage .cfg file. If found in the .cfg file and set to `true`, it forces the Windows app launcher not to restart the launcher process.
>> 
>> Collateral changes to the tests:
>>  - Added `WindowsHelper.killProcess()` to kill process by PID;
>>  - Added `WindowsHelper.findAppLauncherPID()` that will return PIDs of the running app launcher processes for the given app launcher name. The implementation grabbed from `Win8301247Test` test;
>>  - Rework `CfgFile` to make it R/W and capable of writing multiple instances of the same key;
>>  - Added `JPackageCommand.ignoreFakeRuntime()` to ignore external runtime if it is a stub. Should speed up local test runs.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Minor cleanup

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21726#pullrequestreview-2410946850

From jiangli at openjdk.org  Fri Nov  1 22:27:30 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Fri, 1 Nov 2024 22:27:30 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
 <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>
Message-ID: <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com>

On Fri, 1 Nov 2024 16:09:20 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly.
> 
> When I try using a pre-compiled HelloWorld, the linux port works for me too.
> 
> @jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR.
> 
> ```
> ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java
> public class HelloWorld {
>   public static void main(String[] args) {
>     System.out.println("Hello, world!");
>   }
> }
> ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java 
> ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld 
> Hello, world!
> ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java
> Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
> Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin
> Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage
> ihse at sthihse:/localhome/git/jdk-ALT$ 
> ```

I can reproduce the issue with running a `.java` directly using static-jdk/bin/java built from your branch. The issue does not exist with the `bin/javastatic` built from https://github.com/openjdk/leyden/tree/hermetic-java-runtime (I just tested). I have a hunch of where is problem might be. I'll do some debugging. 


$ bin/java /usr/local/google/home/jianglizhou/tests/HelloWorld.java
Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /usr/local/google/home/jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk/bin
Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452668656

From nbenalla at openjdk.org  Fri Nov  1 22:33:42 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 1 Nov 2024 22:33:42 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v4]
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <hKK5IuvxzhjkTdQF6KQWlkrEjD-cPSmRhZD5BAscB74=.75bb8eea-3b1a-4b3d-acb1-bece936893e9@github.com>

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Globally add modules using `TEST.properties`

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21542/files
  - new: https://git.openjdk.org/jdk/pull/21542/files/408ae6d7..e973302b

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

  Stats: 34 lines in 7 files changed: 4 ins; 24 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21542.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21542/head:pull/21542

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

From jlu at openjdk.org  Fri Nov  1 23:21:56 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 1 Nov 2024 23:21:56 GMT
Subject: RFR: 8343237: Improve the copying of the available set of Currencies
Message-ID: <PuaktdmoJvTll6jpRanMGp6RoG85xw-FSn86s9IA0xQ=.f2db1c2e-3b14-48d3-a8f4-92a4ae338f52@github.com>

Please review this PR which is a small cleanup in `Currency.getAvailableCurrencies()`. We can use the `HashSet` constructor over `clone()` to make the defensive copy of the set of available currencies. This gets rid of the unsightly unchecked cast and SuppressWarnings annotation.

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

Commit messages:
 - init

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

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

From liach at openjdk.org  Fri Nov  1 23:59:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 1 Nov 2024 23:59:30 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]
In-Reply-To: <WH6CDWHVXfAV_latmlIBSisO4TSqTv0_MnQmyQ5oubw=.1c943e88-c636-4f81-9298-964da7143ac6@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <AEKaSqQIm4x1yPhPxkuM6QxQ5djVWtPouiBVpwAnVhk=.e18ad356-da43-450f-b76f-939b234c42a8@github.com>
 <WH6CDWHVXfAV_latmlIBSisO4TSqTv0_MnQmyQ5oubw=.1c943e88-c636-4f81-9298-964da7143ac6@github.com>
Message-ID: <aYcqcn7CpDDoyYLNQOsgKT5pEU_pCNHd93uCP_v36ug=.8a966d64-620d-451a-886d-34c0d3eaa8d4@github.com>

On Fri, 1 Nov 2024 21:32:23 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Comments to clarify, also align skipOverFieldSignature
>
> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 258:
> 
>> 256:         if (name.isEmpty())
>> 257:             return name;
>> 258:         return validateBinaryClassName(name);
> 
> Perhaps have a utility method to specify if empty name is allowed.   `validateBinaryClassName` and `validateInternalClassName` only differ in the separator charactor.   They can be refactored to call one single name validation method something like this:
> 
> 
>     private static String validateName(String name, boolean internalName, boolean allowEmptyName) {
>         if (!allowEmptyName && name.isEmpty())
>               throw invalidClassName(name);
>               
>         // state variable for detection of illegal states, such as:
>         // empty unqualified name, consecutive, leading, or trailing separators
>         int afterSeparator = 0;
>         int len = name.length();
>         for (int i = 0; i < len; i++) {
>             char ch = name.charAt(i);
>             // reject ';' or '[' or other form's separator
>             if (ch == ';' || ch == '[' || (internalName && ch == '.') || (!internalName && ch == '/'))
>                 throw invalidClassName(name);
>             if ((internalName && ch == '/') || (!internalName && ch == '.')) {
>                 // illegal state when received separator indicates consecutive
>                 // or leading separators
>                 if (i == afterSeparator)
>                     throw invalidClassName(name);
>                 afterSeparator = i + 1;
>             }
>         }
>         // reject empty unqualified name or trailing separators
>         if (len == afterSeparator)
>             throw invalidClassName(name);
>         return name;
>     }

I assume I will still keep the 4 public methods to call this implementation method, as the boolean arguments will be otherwise confusing.  Is that what you intend?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21830#discussion_r1826385667

From liach at openjdk.org  Sat Nov  2 00:16:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 2 Nov 2024 00:16:41 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v3]
In-Reply-To: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
Message-ID: <FwQzl9MnqcySTXKeOI-NXXXDCP63hF9ZeSl7l44r0U0=.7e379c6f-7e7a-4309-949c-f7e555d2ff47@github.com>

> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665, the validation methods `validateBinaryClassName` and `validateInternalClassName` only checks if a separator char is the initial or final char, or if it immediately follows another chars.  This omitted the case of empty strings, and allowed creation of invalid ClassDesc with empty binary name, which is otherwise rejected by `ofDescriptor`.
> 
> To better check for the separator char, the tracking mechanism is updated to indicate a position where a separator char shouldn't appear, or where the name string should not terminate.  This is initially set to the initial position 0, and upon each time of encountering a separator, this is updated to the next char.
> 
> This logic is similar to the existing one in `skipOverFieldSignature`, which uses a boolean `legal` variable.  Both reject empty strings, leading and trailing separators, or consecutive separators.  The new logic, however, does not require repeated updates to the new `afterSeparator` variable upon scanning each character.
> 
> In addition, I noted the package name validation erroneously does not prohibit leading, trailing, or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  This patch also makes package name validation reuse class or interface name validation in non-empty (unnamed package) cases, and added those cases to the test suite.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Reuse the check implementation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21830/files
  - new: https://git.openjdk.org/jdk/pull/21830/files/4325e94d..dae377a4

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

  Stats: 77 lines in 1 file changed: 25 ins; 27 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/21830.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21830/head:pull/21830

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

From mchung at openjdk.org  Sat Nov  2 00:16:41 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 2 Nov 2024 00:16:41 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v2]
In-Reply-To: <aYcqcn7CpDDoyYLNQOsgKT5pEU_pCNHd93uCP_v36ug=.8a966d64-620d-451a-886d-34c0d3eaa8d4@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <AEKaSqQIm4x1yPhPxkuM6QxQ5djVWtPouiBVpwAnVhk=.e18ad356-da43-450f-b76f-939b234c42a8@github.com>
 <WH6CDWHVXfAV_latmlIBSisO4TSqTv0_MnQmyQ5oubw=.1c943e88-c636-4f81-9298-964da7143ac6@github.com>
 <aYcqcn7CpDDoyYLNQOsgKT5pEU_pCNHd93uCP_v36ug=.8a966d64-620d-451a-886d-34c0d3eaa8d4@github.com>
Message-ID: <QPPgnSrzDJsyhlfKges2o69poGah1yPSL27fW2aF4tE=.6da51bf5-e2ef-4ab8-baff-a53d441aa97e@github.com>

On Fri, 1 Nov 2024 23:57:20 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 258:
>> 
>>> 256:         if (name.isEmpty())
>>> 257:             return name;
>>> 258:         return validateBinaryClassName(name);
>> 
>> Perhaps have a utility method to specify if empty name is allowed.   `validateBinaryClassName` and `validateInternalClassName` only differ in the separator charactor.   They can be refactored to call one single name validation method something like this:
>> 
>> 
>>     private static String validateName(String name, boolean internalName, boolean allowEmptyName) {
>>         if (!allowEmptyName && name.isEmpty())
>>               throw invalidClassName(name);
>>               
>>         // state variable for detection of illegal states, such as:
>>         // empty unqualified name, consecutive, leading, or trailing separators
>>         int afterSeparator = 0;
>>         int len = name.length();
>>         for (int i = 0; i < len; i++) {
>>             char ch = name.charAt(i);
>>             // reject ';' or '[' or other form's separator
>>             if (ch == ';' || ch == '[' || (internalName && ch == '.') || (!internalName && ch == '/'))
>>                 throw invalidClassName(name);
>>             if ((internalName && ch == '/') || (!internalName && ch == '.')) {
>>                 // illegal state when received separator indicates consecutive
>>                 // or leading separators
>>                 if (i == afterSeparator)
>>                     throw invalidClassName(name);
>>                 afterSeparator = i + 1;
>>             }
>>         }
>>         // reject empty unqualified name or trailing separators
>>         if (len == afterSeparator)
>>             throw invalidClassName(name);
>>         return name;
>>     }
>
> I assume I will still keep the 4 public methods to call this implementation method, as the boolean arguments will be otherwise confusing.  Is that what you intend?

yes.  since you already made some refactoring, can improve further.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21830#discussion_r1826395001

From vaivanov at openjdk.org  Sat Nov  2 00:20:37 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Sat, 2 Nov 2024 00:20:37 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers
Message-ID: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>

The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
Unit tests was not affected:
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR
   jtreg:test/jaxp                                     516   516     0     0
   jtreg:test/jdk/javax/xml                             70    70     0     0
==============================
TEST SUCCESS

The tier1 is OK too.

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

Commit messages:
 - 8317542: Specjvm::xml have scalability issue for high vCPU numbers
 - 8317542 Specjvm::xml have scalability issue for high vCPU numbers

Changes: https://git.openjdk.org/jdk/pull/21815/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21815&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8317542
  Stats: 57 lines in 1 file changed: 23 ins; 4 del; 30 mod
  Patch: https://git.openjdk.org/jdk/pull/21815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21815/head:pull/21815

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

From liach at openjdk.org  Sat Nov  2 00:32:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 2 Nov 2024 00:32:49 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v4]
In-Reply-To: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
Message-ID: <812QQ47QfmjattI_c7dzBGhqf4H97DLMFQ5jP5BSMFU=.e37d5aab-e13b-4d4e-8ca8-a8a75092c125@github.com>

> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665, the validation methods `validateBinaryClassName` and `validateInternalClassName` only checks if a separator char is the initial or final char, or if it immediately follows another chars.  This omitted the case of empty strings, and allowed creation of invalid ClassDesc with empty binary name, which is otherwise rejected by `ofDescriptor`.
> 
> To better check for the separator char, the tracking mechanism is updated to indicate a position where a separator char shouldn't appear, or where the name string should not terminate.  This is initially set to the initial position 0, and upon each time of encountering a separator, this is updated to the next char.
> 
> This logic is similar to the existing one in `skipOverFieldSignature`, which uses a boolean `legal` variable.  Both reject empty strings, leading and trailing separators, or consecutive separators.  The new logic, however, does not require repeated updates to the new `afterSeparator` variable upon scanning each character.
> 
> In addition, I noted the package name validation erroneously does not prohibit leading, trailing, or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  This patch also makes package name validation reuse class or interface name validation in non-empty (unnamed package) cases, and added those cases to the test suite.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  More descriptive names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21830/files
  - new: https://git.openjdk.org/jdk/pull/21830/files/dae377a4..469077d8

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

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

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

From mchung at openjdk.org  Sat Nov  2 00:32:49 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 2 Nov 2024 00:32:49 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v3]
In-Reply-To: <FwQzl9MnqcySTXKeOI-NXXXDCP63hF9ZeSl7l44r0U0=.7e379c6f-7e7a-4309-949c-f7e555d2ff47@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <FwQzl9MnqcySTXKeOI-NXXXDCP63hF9ZeSl7l44r0U0=.7e379c6f-7e7a-4309-949c-f7e555d2ff47@github.com>
Message-ID: <sBTx_MarrZssvBCo7a_2zsQEtniqsLTPl14Mn90L-nk=.f833554c-df1c-44b1-a45e-25965c8e2b44@github.com>

On Sat, 2 Nov 2024 00:16:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665, the validation methods `validateBinaryClassName` and `validateInternalClassName` only checks if a separator char is the initial or final char, or if it immediately follows another chars.  This omitted the case of empty strings, and allowed creation of invalid ClassDesc with empty binary name, which is otherwise rejected by `ofDescriptor`.
>> 
>> To better check for the separator char, the tracking mechanism is updated to indicate a position where a separator char shouldn't appear, or where the name string should not terminate.  This is initially set to the initial position 0, and upon each time of encountering a separator, this is updated to the next char.
>> 
>> This logic is similar to the existing one in `skipOverFieldSignature`, which uses a boolean `legal` variable.  Both reject empty strings, leading and trailing separators, or consecutive separators.  The new logic, however, does not require repeated updates to the new `afterSeparator` variable upon scanning each character.
>> 
>> In addition, I noted the package name validation erroneously does not prohibit leading, trailing, or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  This patch also makes package name validation reuse class or interface name validation in non-empty (unnamed package) cases, and added those cases to the test suite.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reuse the check implementation

Looks good with minor suggestion to rename the method name.

src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 191:

> 189:      * @throws NullPointerException if name is {@code null}
> 190:      */
> 191:     private static String validatePathBasedName(String name, boolean usesSlash, boolean allowsEmpty) {

Suggestion:

    private static String validatePackageOrClassName(String name, boolean internalName, boolean allowEmpty) {

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

Marked as reviewed by mchung (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21830#pullrequestreview-2411032617
PR Review Comment: https://git.openjdk.org/jdk/pull/21830#discussion_r1826400726

From liach at openjdk.org  Sat Nov  2 01:06:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 2 Nov 2024 01:06:41 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v3]
In-Reply-To: <sBTx_MarrZssvBCo7a_2zsQEtniqsLTPl14Mn90L-nk=.f833554c-df1c-44b1-a45e-25965c8e2b44@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <FwQzl9MnqcySTXKeOI-NXXXDCP63hF9ZeSl7l44r0U0=.7e379c6f-7e7a-4309-949c-f7e555d2ff47@github.com>
 <sBTx_MarrZssvBCo7a_2zsQEtniqsLTPl14Mn90L-nk=.f833554c-df1c-44b1-a45e-25965c8e2b44@github.com>
Message-ID: <FTKFBzJH53fw05rzTMD01MSlKoEgxTjCNQqrpyIB-90=.fd9420ea-3af7-4fed-8240-8690556bd08f@github.com>

On Sat, 2 Nov 2024 00:27:52 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reuse the check implementation
>
> src/java.base/share/classes/jdk/internal/constant/ConstantUtils.java line 191:
> 
>> 189:      * @throws NullPointerException if name is {@code null}
>> 190:      */
>> 191:     private static String validatePathBasedName(String name, boolean usesSlash, boolean allowsEmpty) {
> 
> Suggestion:
> 
>     private static String validatePackageOrClassName(String name, boolean internalName, boolean allowEmpty) {

Done. Seems skara bot doesn't recognize your review sent after I pushed my rename unfortunately.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21830#discussion_r1826433516

From jiangli at openjdk.org  Sat Nov  2 01:08:40 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sat, 2 Nov 2024 01:08:40 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
 <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>
 <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com>
Message-ID: <zuGp6ZwW6hvpfdwvlHMmHfnsa2hVkVaMOYKMp872ZIA=.9c95a697-5fc3-4104-89bc-3ad637ed72f3@github.com>

On Fri, 1 Nov 2024 22:24:28 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly.
> > When I try using a pre-compiled HelloWorld, the linux port works for me too.
> > @jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR.
> > ```
> > ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java
> > public class HelloWorld {
> >   public static void main(String[] args) {
> >     System.out.println("Hello, world!");
> >   }
> > }
> > ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java 
> > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld 
> > Hello, world!
> > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java
> > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
> > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin
> > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage
> > ihse at sthihse:/localhome/git/jdk-ALT$ 
> > ```
> 
> I can reproduce the issue with running a `.java` directly using static-jdk/bin/java built from your branch. The issue does not exist with the `bin/javastatic` built from https://github.com/openjdk/leyden/tree/hermetic-java-runtime (I just tested). I have a hunch of where is problem might be. I'll do some debugging.
> 
> ```
> $ bin/java /usr/local/google/home/jianglizhou/tests/HelloWorld.java
> Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
> Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /usr/local/google/home/jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk/bin
> Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage
> ```

Ok, I've found the cause. It's because `<jdk_build_path>/static-jdk/bin` instead of `<jdk_build_path>/static-jdk/lib` is set as the `_sun_boot_library_path` by `Arguments::set_dll_dir()`, during `os::init_system_properties_values()`. The path is retrieved via `StaticProperty.sunBootLibraryPath()` and used by `ClassLoader.loadLibrary()` to locate `jimage`. Hence the failure.

Looking at why it only fails with running with `.java` but not with `.class`, a quick looks shows me that the following call path is only taken when running with `.java`:


	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2410)
	at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:927)
	at java.base/java.lang.System.loadLibrary(System.java:2078)
	at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:43)
	at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:40)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
	at java.base/jdk.internal.jimage.NativeImageBuffer.<clinit>(NativeImageBuffer.java:39)
	at java.base/jdk.internal.jimage.BasicImageReader.<init>(BasicImageReader.java:97)
	at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.<init>(ImageReader.java:229)
	at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:243)
	at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:67)
	at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:71)
	at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:70)
	at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:67)
	at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1714)
	at java.base/jdk.internal.jimage.ImageReaderFactory.get(ImageReaderFactory.java:61)
	at java.base/jdk.internal.jimage.ImageReaderFactory.getImageReader(ImageReaderFactory.java:85)
	at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.<clinit>(SystemModuleFinders.java:385)
	at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429)
	at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483)
	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:640)
	at java.base/java.lang.Class.forName(Class.java:673)
	at java.base/java.lang.Class.forName(Class.java:648)
	at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:798)
	at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:733)


I'm going to look into a fix and update in this comment thread.

While investigating, I also just found there a new issue in https://github.com/openjdk/leyden/tree/hermetic-java-runtime. Let's focus on resolving the `.java` run issue with your PR to make progress first.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2452777288

From bpb at openjdk.org  Sat Nov  2 01:29:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 2 Nov 2024 01:29:27 GMT
Subject: RFR: 8343237: Improve the copying of the available set of
 Currencies
In-Reply-To: <PuaktdmoJvTll6jpRanMGp6RoG85xw-FSn86s9IA0xQ=.f2db1c2e-3b14-48d3-a8f4-92a4ae338f52@github.com>
References: <PuaktdmoJvTll6jpRanMGp6RoG85xw-FSn86s9IA0xQ=.f2db1c2e-3b14-48d3-a8f4-92a4ae338f52@github.com>
Message-ID: <Zu0ANYKQCN3lmWC5ZlxAAJVPIf8dSQQkydjp3a3blrU=.344527ee-5056-45d6-985c-fa5f95d5d6ff@github.com>

On Fri, 1 Nov 2024 23:17:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a small cleanup in `Currency.getAvailableCurrencies()`. We can use the `HashSet` constructor over `clone()` to make the defensive copy of the set of available currencies. This gets rid of the unsightly unchecked cast and SuppressWarnings annotation.

Looks fine.

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

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21845#pullrequestreview-2411110241

From fyang at openjdk.org  Sat Nov  2 02:44:55 2024
From: fyang at openjdk.org (Fei Yang)
Date: Sat, 2 Nov 2024 02:44:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
Message-ID: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>

On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
>> 
>>> 271:         ? frame_sp + fsize - frame::sender_sp_offset
>>> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
>>> 273:         : *(intptr_t**)(hf.sp() - 2);
>> 
>> Suggestion:
>> 
>>         : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);
>
> Changed.

Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713

From sspitsyn at openjdk.org  Sat Nov  2 04:53:56 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Sat, 2 Nov 2024 04:53:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <a4feDci916h0jQyvBcTdBCTt_Cn20rkNi8pm2TuEkbw=.5babb895-54e3-4427-be3d-3e87b5943b8a@github.com>

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

src/hotspot/share/runtime/objectMonitor.cpp line 537:

> 535:       }
> 536:     }
> 537: 

Just a question. It is not clear from scratch why the `Continuation::try_preempt()` is called before the `VThreadMonitorEnter()`. It would be nice to add a comment explaining it. It can be also good to explain how it works together in this order. Even a surface explanation of a general idea would be very helpful. A part of this already explained in the comment at lines 515-517.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826492850

From kizune at openjdk.org  Sat Nov  2 07:53:44 2024
From: kizune at openjdk.org (Alexander Zuev)
Date: Sat, 2 Nov 2024 07:53:44 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>
Message-ID: <Cc1Z7x6SVjqGjBRKwLciK-GnlFF1Xyc76p-4nwcvF4g=.b7e0b372-a2d2-4b61-ae1c-aa1b646700d4@github.com>

On Fri, 1 Nov 2024 18:44:02 GMT, Phil Race <prr at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize
>
> make/modules/jdk.accessibility/Lib.gmk line 57:
> 
>> 55:   TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
>> 56: 
>> 57:   ##############################################################################
> 
> Most of the desktop related changes are related to Assistive Technologies
> I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something.
> The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT.
> 
> So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java

We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1826520980

From jpai at openjdk.org  Sat Nov  2 10:45:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Nov 2024 10:45:28 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
Message-ID: <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>

On Wed, 30 Oct 2024 13:01:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a partial implementation of JEP 495 - adjustments of the JEP metadata in `PreviewFeature`. There are no language changes associated with this JEP. Changes to the `java.io.IO` class are covered by https://github.com/openjdk/jdk/pull/21693.

This looks OK to me and matches what is stated in the CSR.

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:

> 70:         //---
> 71:         @JEP(number=495, title="Simple Source Files and Instance Main Methods", status="Fourth Preview")
> 72:         IMPLICIT_CLASSES,

Hello Jan, although it's just an internal enum name, do you think we should rename it to be closer to the JEP's title or is it not worth it?

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

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21787#pullrequestreview-2411231079
PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826544471

From jpai at openjdk.org  Sat Nov  2 11:04:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 2 Nov 2024 11:04:27 GMT
Subject: RFR: 8342775: [Graal]
 java/util/concurrent/locks/Lock/OOMEInAQS.java fails OOME  thrown from the
 UncaughtExceptionHandler
In-Reply-To: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
References: <4FAN9C0IIpxPS_6_-adhzbvOOKYQKlR5SJJzk_leZ70=.30e08e90-4d61-4a69-a2a1-ba89f6fde9a7@github.com>
Message-ID: <Sw5qgIpjCtNrPVBkTSvt5Hp5ZnIEheMGRTR4FEto_aQ=.837e62c7-d9aa-4aa2-8286-5f3842976757@github.com>

On Mon, 28 Oct 2024 18:45:59 GMT, Tom Rodriguez <never at openjdk.org> wrote:

> Deoptimization with escape analysis can fail when trying to rematerialize objects as described in JDK-8227309.  In this test this can happen in Xcomp mode in the framework of the test resulting in a test failure.  Making the number of threads non-final avoids scalar replacement and thus the OOM during deopt.

test/jdk/java/util/concurrent/locks/Lock/OOMEInAQS.java line 48:

> 46:     // Intentionaly non-final to avoid EA of the threads array in main which can cause this test to
> 47:     // fail in Xcomp mode.
> 48:     static int NTHREADS = 2; // intentionally not a scalable test; > 2 is very slow

Hello Tom, I don't have the necessary knowledge of runtime compilers, so consider this as drive-by questions than a review. 

On its own, the `static final` construct appears to be the correct one for this field. Removing the `final` to address an escape analysis implementation detail appears odd.
Do you know if the failure happens only in `-Xcomp` mode? Looking at JDK-8342775 it wasn't clear to me that was the case. If it's happening only in `-Xcomp` mode, perhaps due to additional work being done by the compiler threads (?) and the fact that this test intentional runs with a very low `-Xmx`, maybe we should just skip the test from `-Xcomp` mode instead of changing the field declaration? We have several such tests which we skip in `-Xcomp` mode by using:

@requires (vm.compMode != "Xcomp")

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21745#discussion_r1826547393

From asemenyuk at openjdk.org  Sat Nov  2 12:47:33 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 2 Nov 2024 12:47:33 GMT
Subject: Integrated: 8340311: JPackage app-image exe launches multiple exe's in
 JDK 22+
In-Reply-To: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
References: <KgicxBW_nJkHww0TV_-QTe-zEbRj2FT7K9d5QuWhTj4=.2cdfa7e9-6fa1-4f9a-9982-55dac027997f@github.com>
Message-ID: <LQYATQVWs7JYX1mNtQ3BnDmvEF-RmngX94ANm8MjdkM=.cc2aa1ff-b994-4e19-9b63-0b0be58b904b@github.com>

On Sat, 26 Oct 2024 01:16:05 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Support `win.norestart` application property in jpackage .cfg file. If found in the .cfg file and set to `true`, it forces the Windows app launcher not to restart the launcher process.
> 
> Collateral changes to the tests:
>  - Added `WindowsHelper.killProcess()` to kill process by PID;
>  - Added `WindowsHelper.findAppLauncherPID()` that will return PIDs of the running app launcher processes for the given app launcher name. The implementation grabbed from `Win8301247Test` test;
>  - Rework `CfgFile` to make it R/W and capable of writing multiple instances of the same key;
>  - Added `JPackageCommand.ignoreFakeRuntime()` to ignore external runtime if it is a stub. Should speed up local test runs.

This pull request has now been integrated.

Changeset: 29882bfe
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/29882bfe7b7e76446a96862cd0a5e81c7e054415
Stats:     552 lines in 13 files changed: 400 ins; 91 del; 61 mod

8340311: JPackage app-image exe launches multiple exe's in JDK 22+

Reviewed-by: almatvee

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

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

From forax at univ-mlv.fr  Sat Nov  2 13:13:26 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Sat, 2 Nov 2024 14:13:26 +0100 (CET)
Subject: ewrite the last section of the overwiew fo SortedMap documentation
 and a link fo NavigableMap
Message-ID: <2027579494.12726998.1730553206044.JavaMail.zimbra@univ-eiffel.fr>

Hello,
I was discussing with a student, she was trying to use the SortedMap interface but had trouble with tailMap() no being a strictly higher view from a key.
The solution was to use NavigableMap instead of SortedMap because it provides more methods to get lower/higher subMap and entries from keys.

I think we can improve de documentation of SortedMap (the last section (Note:) of the overview) by rewriting it saying that NavigableMap provides a richer API
instead of the current documentation that propose to add 1 or '\0' to the subMap() which is a ugly hack.

regards,
R?mi

From asemenyuk at openjdk.org  Sat Nov  2 14:27:05 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 2 Nov 2024 14:27:05 GMT
Subject: RFR: 8343314: Move common properties from jpackage jtreg test
 declarations to TEST.properties file
Message-ID: <WlR1qz4C6miTVQz6LotCiEy0oqinc4LxBRbr5wigc0M=.c9a5d80c-3e50-4df8-91fc-06085dbe8d90@github.com>

Clean up of jpackage jtreg test declarations:
 - remove "<span>@</span>modules java.base/jdk.internal.util";
 - remove `--add-opens` from <span>@</span>run;
 - replace "<span>@</span>library ../../../../helpers" and "<span>@</span>library ../helpers" with "<span>@</span>library /test/jdk/tools/jpackage/helpers";
 - remove <span>@</span>library referring to unused libraries;
 - remove duplicated <span>@</span>build;
 - add `modules=jdk.jpackage/jdk.jpackage.internal:+open java.base/jdk.internal.util` to jpackage's `TEST.properties` file.

Most changes were automated with ad-hoc scripts.

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

Commit messages:
 - Merge fix
 - Merge branch 'master' into JDK-8343314
 - Merge
 - Merge branch 'master' into JDK-8343314
 - Fix for "Parse Exception: `@library' must appear before first action tag" jtreg error
 - Cleanup
 - Cleanup
 - Automatic Copyright year update
 - Automatic jtreg test declarations clean up

Changes: https://git.openjdk.org/jdk/pull/21792/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21792&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343314
  Stats: 297 lines in 87 files changed: 4 ins; 122 del; 171 mod
  Patch: https://git.openjdk.org/jdk/pull/21792.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21792/head:pull/21792

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

From asemenyuk at openjdk.org  Sat Nov  2 14:27:05 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 2 Nov 2024 14:27:05 GMT
Subject: RFR: 8343314: Move common properties from jpackage jtreg test
 declarations to TEST.properties file
In-Reply-To: <WlR1qz4C6miTVQz6LotCiEy0oqinc4LxBRbr5wigc0M=.c9a5d80c-3e50-4df8-91fc-06085dbe8d90@github.com>
References: <WlR1qz4C6miTVQz6LotCiEy0oqinc4LxBRbr5wigc0M=.c9a5d80c-3e50-4df8-91fc-06085dbe8d90@github.com>
Message-ID: <qrBd0Q2g_M-iyZeKd0P8XAqtB3pweWZuVBAFlj6SIkg=.e74f2c29-04ca-4468-a252-90ac2db70cb2@github.com>

On Wed, 30 Oct 2024 19:07:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Clean up of jpackage jtreg test declarations:
>  - remove "<span>@</span>modules java.base/jdk.internal.util";
>  - remove `--add-opens` from <span>@</span>run;
>  - replace "<span>@</span>library ../../../../helpers" and "<span>@</span>library ../helpers" with "<span>@</span>library /test/jdk/tools/jpackage/helpers";
>  - remove <span>@</span>library referring to unused libraries;
>  - remove duplicated <span>@</span>build;
>  - add `modules=jdk.jpackage/jdk.jpackage.internal:+open java.base/jdk.internal.util` to jpackage's `TEST.properties` file.
> 
> Most changes were automated with ad-hoc scripts.

@sashamatveev ptal

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

PR Comment: https://git.openjdk.org/jdk/pull/21792#issuecomment-2453007062

From alanb at openjdk.org  Sat Nov  2 15:13:29 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 2 Nov 2024 15:13:29 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
 <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
Message-ID: <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>

On Sat, 2 Nov 2024 10:41:23 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> This is a partial implementation of JEP 495 - adjustments of the JEP metadata in `PreviewFeature`. There are no language changes associated with this JEP. Changes to the `java.io.IO` class are covered by https://github.com/openjdk/jdk/pull/21693.
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:
> 
>> 70:         //---
>> 71:         @JEP(number=495, title="Simple Source Files and Instance Main Methods", status="Fourth Preview")
>> 72:         IMPLICIT_CLASSES,
> 
> Hello Jan, although it's just an internal enum name, do you think we should rename it to be closer to the JEP's title or is it not worth it?

The title also shows up in list of preview APIs in the javadoc so changing seems correct.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826585785

From acobbs at openjdk.org  Sat Nov  2 15:45:00 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sat, 2 Nov 2024 15:45:00 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs)
Message-ID: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>

Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

Commit messages:
 - Remove unnecessary @SuppressWarnings annotations.

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343478
  Stats: 113 lines in 89 files changed: 0 ins; 82 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From chen.l.liang at oracle.com  Sat Nov  2 17:08:40 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 2 Nov 2024 17:08:40 +0000
Subject: ewrite the last section of the overwiew fo SortedMap
 documentation and a link fo NavigableMap
In-Reply-To: <2027579494.12726998.1730553206044.JavaMail.zimbra@univ-eiffel.fr>
References: <2027579494.12726998.1730553206044.JavaMail.zimbra@univ-eiffel.fr>
Message-ID: <IA0SPRMB000283891B5C584212DC550AA2572@IA0SPRMB0002.namprd10.prod.outlook.com>

I strongly agree.  The use of SortedMap should be no longer preferred, like that for java.util.Stack/Vector.  We should update the Javadoc to refer to NavigableMap as the main total-ordered version and refer to SortedMap as a legacy interface.  In fact, we should probably override all SortedMap methods in NavigableMap, so IDE navigations never direct users to SortedMap.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Saturday, November 2, 2024 8:13 AM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Cc: Stuart Marks <smarks at openjdk.java.net>
Subject: ewrite the last section of the overwiew fo SortedMap documentation and a link fo NavigableMap

Hello,
I was discussing with a student, she was trying to use the SortedMap interface but had trouble with tailMap() no being a strictly higher view from a key.
The solution was to use NavigableMap instead of SortedMap because it provides more methods to get lower/higher subMap and entries from keys.

I think we can improve de documentation of SortedMap (the last section (Note:) of the overview) by rewriting it saying that NavigableMap provides a richer API
instead of the current documentation that propose to add 1 or '\0' to the subMap() which is a ugly hack.

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241102/2f772627/attachment.htm>

From jlahoda at openjdk.org  Sat Nov  2 17:11:28 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Sat, 2 Nov 2024 17:11:28 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
 <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
 <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>
Message-ID: <QJUoyokVZYfwOpJ7my1USn-6N9GH2l7ppWXO630yaM0=.3f7f0e7a-5b9d-4bc2-ae81-af0b6e32c6cb@github.com>

On Sat, 2 Nov 2024 15:11:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 72:
>> 
>>> 70:         //---
>>> 71:         @JEP(number=495, title="Simple Source Files and Instance Main Methods", status="Fourth Preview")
>>> 72:         IMPLICIT_CLASSES,
>> 
>> Hello Jan, although it's just an internal enum name, do you think we should rename it to be closer to the JEP's title or is it not worth it?
>
> The title also shows up in list of preview APIs in the javadoc so changing seems correct.

Please note the title is adjusted to match the current name of the JEP. So the built javadoc should not be an issue. What Jaikiran is speaking about is the enum constant name, which hopefully(!) does not have a meaning outside of the JDK.

We could change the constant to `SIMPLE_SOURCE_FILES_AND_INSTANCE_MAIN_METHODS` (to precisely reflect the JEP's name), but it seems like an unnecessary git churn to me. We might also need to keep the existing constant due to bootstrap issues, then remove it when JDK 25 is switched to bootstrap on JDK 24.

I can do that, if really needed, though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826603335

From chen.l.liang at oracle.com  Sat Nov  2 17:13:23 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Sat, 2 Nov 2024 17:13:23 +0000
Subject: ewrite the last section of the overwiew fo SortedMap
 documentation and a link fo NavigableMap
In-Reply-To: <IA0SPRMB000283891B5C584212DC550AA2572@IA0SPRMB0002.namprd10.prod.outlook.com>
References: <2027579494.12726998.1730553206044.JavaMail.zimbra@univ-eiffel.fr>
 <IA0SPRMB000283891B5C584212DC550AA2572@IA0SPRMB0002.namprd10.prod.outlook.com>
Message-ID: <IA0SPRMB000280796CD4695D5993FFF8A2572@IA0SPRMB0002.namprd10.prod.outlook.com>

In addition, I discovered that a few methods, subMap, headMap, tailMap, sequencedKeySet, keySet, can be provided default implementations with covariant overrides.  This will bring convenience to both user implementations and API users, and adding covariant override is binary (but not source) compatible; example being LinkedList.

Another aspect is that the SequencedMap should explicitly override keySet, values, entrySet methods, asking users to implement the sequenced versions and delegate plain versions to return the sequenced versions instead.  This also troubles NavigableMap, but should be easy to fix (and is doc-only)

-Chen
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Chen Liang <chen.l.liang at oracle.com>
Sent: Saturday, November 2, 2024 12:08 PM
To: Remi Forax <forax at univ-mlv.fr>; core-libs-dev <core-libs-dev at openjdk.java.net>
Cc: Stuart Marks <smarks at openjdk.java.net>
Subject: Re: ewrite the last section of the overwiew fo SortedMap documentation and a link fo NavigableMap

I strongly agree.  The use of SortedMap should be no longer preferred, like that for java.util.Stack/Vector.  We should update the Javadoc to refer to NavigableMap as the main total-ordered version and refer to SortedMap as a legacy interface.  In fact, we should probably override all SortedMap methods in NavigableMap, so IDE navigations never direct users to SortedMap.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Remi Forax <forax at univ-mlv.fr>
Sent: Saturday, November 2, 2024 8:13 AM
To: core-libs-dev <core-libs-dev at openjdk.java.net>
Cc: Stuart Marks <smarks at openjdk.java.net>
Subject: ewrite the last section of the overwiew fo SortedMap documentation and a link fo NavigableMap

Hello,
I was discussing with a student, she was trying to use the SortedMap interface but had trouble with tailMap() no being a strictly higher view from a key.
The solution was to use NavigableMap instead of SortedMap because it provides more methods to get lower/higher subMap and entries from keys.

I think we can improve de documentation of SortedMap (the last section (Note:) of the overview) by rewriting it saying that NavigableMap provides a richer API
instead of the current documentation that propose to add 1 or '\0' to the subMap() which is a ugly hack.

regards,
R?mi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241102/1c83d59b/attachment.htm>

From dl at openjdk.org  Sat Nov  2 17:32:02 2024
From: dl at openjdk.org (Doug Lea)
Date: Sat, 2 Nov 2024 17:32:02 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v15]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <N8mM04kqRFqhHbAl8bH9L8biHXHjK2OQ1WbGaPghYTk=.ce475eba-527d-469f-a8cd-020c232b76aa@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Reduce read contention

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/b12be0e1..5cebdb12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=13-14

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

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

From duke at openjdk.org  Sat Nov  2 22:42:07 2024
From: duke at openjdk.org (ExE Boss)
Date: Sat, 2 Nov 2024 22:42:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
Message-ID: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>

On Wed, 30 Oct 2024 19:28:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Modify three RMI tests to work without the security manager:
>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>    Also remove them from the problem list.
>  - Remove two obsolete RMI tests:
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>    Adjust two tests to run without the Security Manager:
>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>    Remove all of these tests from the problem list.
>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>    grants no permissions. A few other small changes to Policy and PD.
>  - Merge branch 'master' into jep486
>  - JAXP tests: organize imports of a few tests
>  - Improve description of Executors.privilegedThreadFactory
>  - rename TestAppletLoggerContext.java as suggested in util test review
>  - clientlibs: Javadoc cleanup
>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b

src/java.base/share/classes/java/lang/System.java line 1364:

> 1362:      * <br>
> 1363:      * It is the responsibility of the provider of
> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that

This is?still a?part of?the?paragraph related to?the?security?manager.

src/java.base/share/classes/java/lang/System.java line 2338:

> 2336:      * Invoked by VM.  Phase 3 is the final system initialization:
> 2337:      * 1. eagerly initialize bootstrap method factories that might interact
> 2338:      *    negatively with custom security managers and custom class loaders

They?might?still interact?negatively with?custom class?loaders?though.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826864120
PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826863295

From mchung at openjdk.org  Sun Nov  3 00:13:27 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Sun, 3 Nov 2024 00:13:27 GMT
Subject: RFR: 8343437: ClassDesc.of incorrectly permitting empty names [v4]
In-Reply-To: <812QQ47QfmjattI_c7dzBGhqf4H97DLMFQ5jP5BSMFU=.e37d5aab-e13b-4d4e-8ca8-a8a75092c125@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
 <812QQ47QfmjattI_c7dzBGhqf4H97DLMFQ5jP5BSMFU=.e37d5aab-e13b-4d4e-8ca8-a8a75092c125@github.com>
Message-ID: <E_z-9jIMQkm-bGKYD8BALZnafgTWzuwf0SicA4SlwiQ=.ee12ebd0-206b-40f1-a0a3-dce0aab2a969@github.com>

On Sat, 2 Nov 2024 00:32:49 GMT, Chen Liang <liach at openjdk.org> wrote:

>> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665, the validation methods `validateBinaryClassName` and `validateInternalClassName` only checks if a separator char is the initial or final char, or if it immediately follows another chars.  This omitted the case of empty strings, and allowed creation of invalid ClassDesc with empty binary name, which is otherwise rejected by `ofDescriptor`.
>> 
>> To better check for the separator char, the tracking mechanism is updated to indicate a position where a separator char shouldn't appear, or where the name string should not terminate.  This is initially set to the initial position 0, and upon each time of encountering a separator, this is updated to the next char.
>> 
>> This logic is similar to the existing one in `skipOverFieldSignature`, which uses a boolean `legal` variable.  Both reject empty strings, leading and trailing separators, or consecutive separators.  The new logic, however, does not require repeated updates to the new `afterSeparator` variable upon scanning each character.
>> 
>> In addition, I noted the package name validation erroneously does not prohibit leading, trailing, or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  This patch also makes package name validation reuse class or interface name validation in non-empty (unnamed package) cases, and added those cases to the test suite.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   More descriptive names

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21830#pullrequestreview-2411757994

From jpai at openjdk.org  Sun Nov  3 01:32:39 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 3 Nov 2024 01:32:39 GMT
Subject: RFR: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <QJUoyokVZYfwOpJ7my1USn-6N9GH2l7ppWXO630yaM0=.3f7f0e7a-5b9d-4bc2-ae81-af0b6e32c6cb@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
 <elSRLgdgkzBBd0Z2CwIy_rKpQAcEZeXOCDAECDz6Cbw=.9a931aaf-a551-4cae-8435-2d56cb682357@github.com>
 <0msmzsfCMI6iPc9L8tiWPYSwA7u1ovaFjCCYpmF9qKc=.0f71f4b4-8505-4b8b-9fb1-8bfc43aebce2@github.com>
 <QJUoyokVZYfwOpJ7my1USn-6N9GH2l7ppWXO630yaM0=.3f7f0e7a-5b9d-4bc2-ae81-af0b6e32c6cb@github.com>
Message-ID: <DHzvNMLyGUfqQdJtNhx7Cs3SQF5gUQoG8IleCOVh5Jo=.17e30b89-35ea-4f90-9b63-ebe32d95842f@github.com>

On Sat, 2 Nov 2024 17:08:41 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> What Jaikiran is speaking about is the enum constant name, which hopefully(!) does not have a meaning outside of the JDK.

I had looked around the rendered javadoc and a few other places and I didn't notice the enum name showing up anywhere publically. It merely appears to be an internal reference within the code.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21787#discussion_r1826884467

From acobbs at openjdk.org  Sun Nov  3 03:13:25 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Sun, 3 Nov 2024 03:13:25 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v2]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <zvOlVozGs_y3wT3BPPdVPSG-pMZSon_S9jkoDYObhN4=.0b54a387-3926-460a-90a2-3a98cbc41ff1@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

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

 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove unnecessary @SuppressWarnings annotations.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/9cef2ae6..7842dfea

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

  Stats: 3279 lines in 177 files changed: 2078 ins; 749 del; 452 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

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

From jiangli at openjdk.org  Sun Nov  3 05:08:34 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sun, 3 Nov 2024 05:08:34 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <zuGp6ZwW6hvpfdwvlHMmHfnsa2hVkVaMOYKMp872ZIA=.9c95a697-5fc3-4104-89bc-3ad637ed72f3@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
 <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>
 <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com>
 <zuGp6ZwW6hvpfdwvlHMmHfnsa2hVkVaMOYKMp872ZIA=.9c95a697-5fc3-4104-89bc-3ad637ed72f3@github.com>
Message-ID: <vxhfWryABYSWDMPG3TTmQBUoi-z5OkhPUF0bQ64blBU=.b74728ed-dae2-4553-9891-0cbc0f04b4a4@github.com>

On Sat, 2 Nov 2024 01:05:27 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> > > I finally noticed that you are testing a precompiled HelloWorld class, and I have been running with a source file argument to have java compile it on the fly.
> > > When I try using a pre-compiled HelloWorld, the linux port works for me too.
> > > @jianglizhou Can you please verify if you can run this with a .java file directly? To be clear: this works fine on my mac with this PR, and (as I said), I'm pretty certain it used to work at least at some point during development on this PR.
> > > ```
> > > ihse at sthihse:/localhome/git/jdk-ALT$ cat > HelloWorld.java
> > > public class HelloWorld {
> > >   public static void main(String[] args) {
> > >     System.out.println("Hello, world!");
> > >   }
> > > }
> > > ihse at sthihse:/localhome/git/jdk-ALT$ javac HelloWorld.java 
> > > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld 
> > > Hello, world!
> > > ihse at sthihse:/localhome/git/jdk-ALT$ ./build/linux-x64/images/static-jdk/bin/java HelloWorld.java
> > > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
> > > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /localhome/git/jdk-ALT/build/linux-x64/images/static-jdk/bin
> > > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage
> > > ihse at sthihse:/localhome/git/jdk-ALT$ 
> > > ```
> > 
> > 
> > I can reproduce the issue with running a `.java` directly using static-jdk/bin/java built from your branch. The issue does not exist with the `bin/javastatic` built from https://github.com/openjdk/leyden/tree/hermetic-java-runtime (I just tested). I have a hunch of where is problem might be. I'll do some debugging.
> > ```
> > $ bin/java /usr/local/google/home/jianglizhou/tests/HelloWorld.java
> > Error: Unable to load main class com.sun.tools.javac.launcher.SourceLauncher in module jdk.compiler
> > Caused by: java.lang.UnsatisfiedLinkError: no jimage in system library path: /usr/local/google/home/jianglizhou/github/jdk_pull_20837/build/linux-x86_64-server-slowdebug/images/static-jdk/bin
> > Runtime.exit(1) logging failed: Could not initialize class jdk.internal.module.SystemModuleFinders$SystemImage
> > ```
> 
> Ok, I've found the cause. It's because `<jdk_build_path>/static-jdk/bin` instead of `<jdk_build_path>/static-jdk/lib` is set as the `_sun_boot_library_path` by `Arguments::set_dll_dir()`, during `os::init_system_properties_values()`. The path is retrieved via `StaticProperty.sunBootLibraryPath()` and used by `ClassLoader.loadLibrary()` to locate `jimage`. Hence the failure.
> 
> Looking at why it only fails with running with `.java` but not with `.class`, a quick looks shows me that the following call path is only taken when running with `.java`:
> 
> ```
> 	at java.base/java.lang.ClassLoader.loadLibrary(ClassLoader.java:2410)
> 	at java.base/java.lang.Runtime.loadLibrary0(Runtime.java:927)
> 	at java.base/java.lang.System.loadLibrary(System.java:2078)
> 	at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:43)
> 	at java.base/jdk.internal.jimage.NativeImageBuffer$1.run(NativeImageBuffer.java:40)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:319)
> 	at java.base/jdk.internal.jimage.NativeImageBuffer.<clinit>(NativeImageBuffer.java:39)
> 	at java.base/jdk.internal.jimage.BasicImageReader.<init>(BasicImageReader.java:97)
> 	at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.<init>(ImageReader.java:229)
> 	at java.base/jdk.internal.jimage.ImageReader$SharedImageReader.open(ImageReader.java:243)
> 	at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:67)
> 	at java.base/jdk.internal.jimage.ImageReader.open(ImageReader.java:71)
> 	at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:70)
> 	at java.base/jdk.internal.jimage.ImageReaderFactory$1.apply(ImageReaderFactory.java:67)
> 	at java.base/java.util.concurrent.ConcurrentHashMap.computeIfAbsent(ConcurrentHashMap.java:1714)
> 	at java.base/jdk.internal.jimage.ImageReaderFactory.get(ImageReaderFactory.java:61)
> 	at java.base/jdk.internal.jimage.ImageReaderFactory.getImageReader(ImageReaderFactory.java:85)
> 	at java.base/jdk.internal.module.SystemModuleFinders$SystemImage.<clinit>(SystemModuleFinders.java:385)
> 	at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.findImageLocation(SystemModuleFinders.java:429)
> 	at java.base/jdk.internal.module.SystemModuleFinders$SystemModuleReader.read(SystemModuleFinders.java:483)
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.defineClass(BuiltinClassLoader.java:809)
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassInModuleOrNull(BuiltinClassLoader.java:741)
> 	at java.base/jdk.internal.loader.BuiltinClassLoader.findClass(BuiltinClassLoader.java:621)
> 	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:640)
> 	at java.base/java.lang.Class.forName(Class.java:673)
> 	at java.base/java.lang.Class.forName(Class.java:648)
> 	at java.base/sun.launcher.LauncherHelper.loadModuleMainClass(LauncherHelper.java:798)
> 	at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:733)
> ```
> 
> I'm going to look into a fix and update in this comment thread.
> 
> While investigating, I also just found there a new issue in https://github.com/openjdk/leyden/tree/hermetic-java-runtime. Let's focus on resolving the `.java` run issue with your PR to make progress first.

With further debugging I found the problem is actually due to failing to load `jimage` as a **built-in** native library. And, that's because `DEF_STATIC_JNI_OnLoad` is missing from jimage.cpp, see change in
https://github.com/openjdk/leyden/blob/3cfd92bfcc6e54377fc2cd4004c926db6aa5e16e/src/java.base/share/native/libjimage/jimage.cpp#L44. I'm going to create a bug to fix the missing `DEF_STATIC_JNI_OnLoad` in the mainline now.

With your PR, `libjimage.so` is statically linked into `static-jdk/bin/java`. As a result there is no `lib/libjimage.so`. So the `_sun_boot_library_path` issue that I pointed out earlier is not the direct cause of the failure. I don't think we need to address that in your PR. We can fix it later. I think we would need to decide what is the `dll_dir` with the static JDK support and hermetic support.

While debugging the issue, I found debugging symbols do not work for `static-jdk/bin/java`. There is no `static-jdk/bin/java.debuginfo`. I do see there's a `./support/static-native/launcher/java.debuginfo`. Please fix the debugging symbol issue in your PR.


Reading symbols from images/static-jdk/bin/java...
(No debugging symbols found in images/static-jdk/bin/java)
(gdb)

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2453298940

From alanb at openjdk.org  Sun Nov  3 07:01:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Nov 2024 07:01:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
Message-ID: <ZlkjUPtWJiKV28QHg5wypFJPAkqECKNofd8X0Tr6TqA=.8ffd4d6f-3d9b-4978-a45c-804050b038ba@github.com>

On Sat, 2 Nov 2024 22:18:09 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Modify three RMI tests to work without the security manager:
>>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>>    Also remove them from the problem list.
>>  - Remove two obsolete RMI tests:
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>>    Adjust two tests to run without the Security Manager:
>>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>>    Remove all of these tests from the problem list.
>>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>>    grants no permissions. A few other small changes to Policy and PD.
>>  - Merge branch 'master' into jep486
>>  - JAXP tests: organize imports of a few tests
>>  - Improve description of Executors.privilegedThreadFactory
>>  - rename TestAppletLoggerContext.java as suggested in util test review
>>  - clientlibs: Javadoc cleanup
>>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b
>
> src/java.base/share/classes/java/lang/System.java line 2338:
> 
>> 2336:      * Invoked by VM.  Phase 3 is the final system initialization:
>> 2337:      * 1. eagerly initialize bootstrap method factories that might interact
>> 2338:      *    negatively with custom security managers and custom class loaders
> 
> They?might?still interact?negatively with?custom class?loaders?though.

The context here is custom a security manager doing string concatenation, this has required StringConcatFactory be eagerly initialized or security managers set on the command line to have been compiled with -XDstringConcat=inline. I think your question is about overriding the system class loader and whether its initialisation can use string concatenation reliably. That's a good thing to add a test for.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826916876

From jpai at openjdk.org  Sun Nov  3 07:14:27 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 3 Nov 2024 07:14:27 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v3]
In-Reply-To: <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
Message-ID: <r-YU3OKicECOrNJsaz-bVVOhjsppRdzWZQFG7tTbgJI=.26845050-e5b5-43a7-9fef-255a35a5a053@github.com>

On Tue, 29 Oct 2024 08:13:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR is simply adding parameter-less `java.io.IO.{println(),readln()}`, with the (hopefully) obvious semantics, plus the corresponding wiring to make those work. This may become part of JEP 495:
>> https://openjdk.org/jeps/495
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test for Console.readln/readLine, ensuring the proper methods are called.

Marked as reviewed by jpai (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21693#pullrequestreview-2411792540

From jpai at openjdk.org  Sun Nov  3 07:14:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sun, 3 Nov 2024 07:14:29 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v3]
In-Reply-To: <VVo-KS0EHccB-fz2dYkNj9FQj5JSLEiZI8OOyvgZJ4A=.915ba6b9-7295-4e47-ad7d-64b2934abe04@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
 <OY4ARfcr0reNyMfiNqT9vAeOZYvE_a5K4Ziy3VZSW8M=.7030b12e-ae29-45b4-b963-7bf7482d5b27@github.com>
 <VVo-KS0EHccB-fz2dYkNj9FQj5JSLEiZI8OOyvgZJ4A=.915ba6b9-7295-4e47-ad7d-64b2934abe04@github.com>
Message-ID: <YOZHzZ7hnUtMLpojnWroPMW41JlztD6yfZrnEKU5AxE=.2f31de8e-5ea2-4b2e-a9c2-48da6b55a8d0@github.com>

On Wed, 30 Oct 2024 12:25:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/Console.java line 184:
>> 
>>> 182:      */
>>> 183:     @PreviewFeature(feature = PreviewFeature.Feature.IMPLICIT_CLASSES)
>>> 184:     public Console println() {
>> 
>> Hello Jan, with the introduction of the simplified `java.io.IO` class, some of whose APIs are wrappers around the `java.io.Console` class APIs, it's understandable that we will start seeing new methods being introduced on the `Console` class.
>> 
>> For this specific new `println()` method on the `Console` class, do you think this method will/should be introduced irrespective of the `IO` class usage? In other words, considering a theoretic case where there may be a situation to abandon the implicit classes preview feature or do it in a different way, would we still want this `println()` method to stay on the `Console`? If yes, then perhaps we should drop the `@PreviewFeature` annotation from this new method and introduce it as a regular new API? Same question for the new `readln()` method on the `Console`.
>
> I don't think this PR is the right place to add the methods permanently to `Console`. I am not objecting to that, but it seems the if those would be added independently of `java.io.IO`, it needs a separate discussion and decision. And I believe that, if needed, that should be done outside of and independently on the framework of `java.io.IO` and JEP 495, as both of these are preview features.

Hello Jan, I agree that if we are going to introduce the parameter-less `println()` and `readln()` APIs on `Console` class independently of the preview feature, then it should be done in a separate PR and with a separate discussion. I was going to suggest that we should probably do that, but I notice that the existing `readln` and `println` methods which take a parameter are already marked preview feature methods in Java 23 https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/io/Console.html#preview-println(java.lang.Object). Given that, I believe what you have here in this PR - marking these new parameter-less methods on `Console` as preview feature, is the right thing to do.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21693#discussion_r1826918451

From dfuchs at openjdk.org  Sun Nov  3 11:28:10 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Sun, 3 Nov 2024 11:28:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
Message-ID: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>

On Sat, 2 Nov 2024 22:25:06 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Modify three RMI tests to work without the security manager:
>>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>>    Also remove them from the problem list.
>>  - Remove two obsolete RMI tests:
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>>    Adjust two tests to run without the Security Manager:
>>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>>    Remove all of these tests from the problem list.
>>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>>    grants no permissions. A few other small changes to Policy and PD.
>>  - Merge branch 'master' into jep486
>>  - JAXP tests: organize imports of a few tests
>>  - Improve description of Executors.privilegedThreadFactory
>>  - rename TestAppletLoggerContext.java as suggested in util test review
>>  - clientlibs: Javadoc cleanup
>>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b
>
> src/java.base/share/classes/java/lang/System.java line 1364:
> 
>> 1362:      * <br>
>> 1363:      * It is the responsibility of the provider of
>> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that
> 
> This is?still a?part of?the?paragraph related to?the?security?manager.

Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826959976

From alanb at openjdk.org  Sun Nov  3 12:36:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 3 Nov 2024 12:36:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
 <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
Message-ID: <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>

On Sun, 3 Nov 2024 11:25:13 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/System.java line 1364:
>> 
>>> 1362:      * <br>
>>> 1363:      * It is the responsibility of the provider of
>>> 1364:      * the concrete {@code LoggerFinder} implementation to ensure that
>> 
>> This is?still a?part of?the?paragraph related to?the?security?manager.
>
> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.

Removed in jep486 branch in sandbox so will get picked up when PR is refreshed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826972198

From dl at openjdk.org  Sun Nov  3 17:35:06 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 3 Nov 2024 17:35:06 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v16]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <nYSC8QRMQbUZtR1PPeKeMse_HKqFUR08rw64DBUIPH8=.ce9fde4b-94e3-4fd8-8383-2cb9b1719543@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Don't report termination while cancellations in progress

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/5cebdb12..15793afa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=14-15

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

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

From jiangli at openjdk.org  Sun Nov  3 20:26:33 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Sun, 3 Nov 2024 20:26:33 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
Message-ID: <QTb-tea1pfPsfImYqrkNr_6WmSq5hLt6d57zZ4Q4Uf0=.b6cdbf11-a7f0-4a6d-8d66-54d35523f33f@github.com>

On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into static-jdk-image
>  - Fix bug in filtering out -Wl,--exclude-libs,ALL
>  - Don't hardcode server variant
>  - Setup LDFLAGS_STATIC_JDK
>  - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>  - Add lookup asserts
>  - Remove superfluous SRC.
>  - Merge branch 'master' into static-jdk-image
>  - Makefile changes needed for static-launcher and static-jdk-image targets
>  - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher

https://github.com/openjdk/jdk/pull/21861 for adding DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2453565591

From swen at openjdk.org  Sun Nov  3 23:24:38 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 3 Nov 2024 23:24:38 GMT
Subject: RFR: 8343500: Optimize ArrayClassDescImpl computeDescriptor
Message-ID: <17-2o2dXFqtL40ZGfMB0byqtSWJ6YWYPCW6gf3TvR60=.90d252e2-ad7d-411c-ad4b-4ea14021da93@github.com>

A small improvement to ArrayClassDescImpl#computeDescriptor that avoids intermediate object allocation in the common rank 1 scenario.

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

Commit messages:
 - optimize computeDescriptor

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

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

From dholmes at openjdk.org  Mon Nov  4 02:18:55 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Nov 2024 02:18:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

src/hotspot/share/classfile/javaClasses.cpp line 2107:

> 2105: 
> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
> 2107:   return vthread->long_field(_timeout_offset);

Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827128518

From dholmes at openjdk.org  Mon Nov  4 02:37:40 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Nov 2024 02:37:40 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Changes requested by dholmes (Reviewer).

src/hotspot/share/adlc/adlc.hpp line 43:

> 41: 
> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */
> 43: #ifdef _WIN32

As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct.

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412031267
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827135809

From mchung at openjdk.org  Mon Nov  4 02:58:29 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Mon, 4 Nov 2024 02:58:29 GMT
Subject: RFR: 8336267: Method and Constructor signature parsing can be
 shared on the root object [v5]
In-Reply-To: <5NtUvRHgrLEtR7he8YV4SJ48w71xOdKZIRvmgIIZXls=.3c60307d-cbc4-493a-9b3a-d762ff98b0cd@github.com>
References: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
 <5NtUvRHgrLEtR7he8YV4SJ48w71xOdKZIRvmgIIZXls=.3c60307d-cbc4-493a-9b3a-d762ff98b0cd@github.com>
Message-ID: <OU4FSojTlnzDzBwLrGw2RZIQuQhXl6tLscNMKi7cXd4=.8c8801c8-6c27-438e-b922-c5798f60d16e@github.com>

On Wed, 30 Oct 2024 16:42:18 GMT, Chen Liang <liach at openjdk.org> wrote:

>> A straightforward optimization, to share the signature parsing of method, constructor, and field between the root and the copied objects, like how method handle accessors are shared.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Move hash cache out of shared states section
>   
>   Co-authored-by: Mandy Chung <mandy.chung at oracle.com>

Marked as reviewed by mchung (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/20179#pullrequestreview-2412041512

From iklam at openjdk.org  Mon Nov  4 03:10:38 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 4 Nov 2024 03:10:38 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v6]
In-Reply-To: <qM3nz9qI10MFZ14TlthOJERSf2LhhYCcIz5LpZvB8P8=.ad19e9dc-369b-40f9-b425-b682ec0202c6@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <Wa16sMIw3k7Ad2Fxj3OYhaxYzHsA0nZCYuRkmiUmSbg=.b2d64b08-8edb-47f4-9ab7-6e332950536c@github.com>
 <qM3nz9qI10MFZ14TlthOJERSf2LhhYCcIz5LpZvB8P8=.ad19e9dc-369b-40f9-b425-b682ec0202c6@github.com>
Message-ID: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com>

On Fri, 1 Nov 2024 03:54:24 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fixed whitespace; fixed minimal build
>
> src/hotspot/share/cds/aotClassInitializer.cpp line 348:
> 
>> 346:     }
>> 347:     JavaValue result(T_VOID);
>> 348:     JavaCalls::call_static(&result, ik,
> 
> Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup?
> 
> I think we do to be consistent with the non-AOTCache run as there is a fence after `<clinit>` (when this code would normally run) due to the initialization lock.

I think this is already done:

`runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. 

https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1827146321

From iklam at openjdk.org  Mon Nov  4 03:15:25 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 4 Nov 2024 03:15:25 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v7]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <mkTCxxPfBA3U7C1sNcfEWrmMpZsTWal8EeFftpoi6DU=.e4335abb-bc27-44d3-97bb-268c1332d059@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits:

 - fixed merge
 - Merge branch 'master' into jep-483-candidate
 - 8343493: Perform module checks during MetaspaceShared::map_archives()
 - reverted changes in modules.cpp to make it easy to merge with mainline
 - Fixed whitespace; fixed minimal build
 - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity"
 - fixed comments
 - @ashu-mehra comment - renamed function to SystemDictionaryShared::should_be_excluded(); added comments and asserts; make sure the class is indeed checked
 - Backed out 58233cc20fa22abfd711bb59aafb78e20fabc195
 - @ashu-mehra comment - rename/comment AOTClassLinker::add_new_candidate() and added asserts for thread safety
 - ... and 162 more: https://git.openjdk.org/jdk/compare/29882bfe...935dcc68

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

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=06
  Stats: 7256 lines in 105 files changed: 6408 ins; 519 del; 329 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

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

From liach at openjdk.org  Mon Nov  4 05:19:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Nov 2024 05:19:26 GMT
Subject: RFR: 8343500: Optimize ArrayClassDescImpl computeDescriptor
In-Reply-To: <17-2o2dXFqtL40ZGfMB0byqtSWJ6YWYPCW6gf3TvR60=.90d252e2-ad7d-411c-ad4b-4ea14021da93@github.com>
References: <17-2o2dXFqtL40ZGfMB0byqtSWJ6YWYPCW6gf3TvR60=.90d252e2-ad7d-411c-ad4b-4ea14021da93@github.com>
Message-ID: <G6f6IoDU5Z2ljvlfBp8Bzdki1JnGPIbFTzdZSXTrSjM=.ef1cdfa8-4422-4e93-9efb-13a43797f060@github.com>

On Sat, 2 Nov 2024 22:50:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small improvement to ArrayClassDescImpl#computeDescriptor that avoids intermediate object allocation in the common rank 1 scenario.

Nice simplification.  constant tests pass.

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

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21860#pullrequestreview-2412162817

From alanb at openjdk.org  Mon Nov  4 05:54:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Nov 2024 05:54:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
 <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>
Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com>

On Mon, 4 Nov 2024 02:12:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lazySubmitRunContinuation when blocking
>
> src/hotspot/share/classfile/javaClasses.cpp line 2107:
> 
>> 2105: 
>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>> 2107:   return vthread->long_field(_timeout_offset);
> 
> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827219720

From jwaters at openjdk.org  Mon Nov  4 06:03:32 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Nov 2024 06:03:32 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v4]
In-Reply-To: <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
Message-ID: <PHGrZHEJO48evK4fd7QFr3wBzlzAo-xDUVKzJ2R5oIk=.5c76ef3a-5fd6-4353-94c8-318b8577f9cd@github.com>

On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove global memHandle, would've liked to keep it as a comment :(

@alexeysemenyukoracle Sorry for the page, needed a reviewer for jpackage. Is jpackage good to go?

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

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2453881416

From jwaters at openjdk.org  Mon Nov  4 06:05:29 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 4 Nov 2024 06:05:29 GMT
Subject: RFR: 8342868: Errors related to unused code on Windows after
 8339120 in core libs [v2]
In-Reply-To: <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
References: <otTjiRgCFQEeUbpfFTMzhXUVBU1cal8q_i7IrGs_n94=.c2f02ad8-6b0c-4daa-9995-8e4b42131eb4@github.com>
 <vT6zJlWPUg235GuAHNJbyAxkoONF2vljAuFTVygBoGk=.05690f62-9641-4990-855a-c908df24e064@github.com>
Message-ID: <SISGIzeBVerZ_M9bBk4gV32GisaUXMUqUpPk-ZlMqy8=.182195cb-6055-4361-b1b9-f96f587f1329@github.com>

On Thu, 31 Oct 2024 05:43:11 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove the got local

Thanks for the reviews! I would delete them entirely, but I don't want to invalidate the existing reviews and force you guys to re-approve again :(

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

PR Comment: https://git.openjdk.org/jdk/pull/21654#issuecomment-2453883009

From asotona at openjdk.org  Mon Nov  4 07:22:31 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Nov 2024 07:22:31 GMT
Subject: Integrated: 8343436: Regression in StackMapGenerator after JDK-8339205
In-Reply-To: <6RSxcb_9ZihmeSIp78EF85MF0BOiRZ4resuNOfS_qnk=.9790d2ad-9f8a-4639-b340-0744c7ac2762@github.com>
References: <6RSxcb_9ZihmeSIp78EF85MF0BOiRZ4resuNOfS_qnk=.9790d2ad-9f8a-4639-b340-0744c7ac2762@github.com>
Message-ID: <S2ZmJjRVxhp9wJ3tdOMgWTS0MFZPrSaV8D1KtQ1OQME=.0c5b2f8f-40d4-4083-bc3d-da4313f4ee5a@github.com>

On Fri, 1 Nov 2024 15:03:51 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> JDK-8339205 introduced multiple regressions in StackMapGenerator and added a lot of new untested code.
> 
> This patch reverts StackMapGenerator to the state before JDK-8339205 and adds one regression test.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: f9e1c62d
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f9e1c62dcd2279cbe5a93a2b19a492cb5b087719
Stats:     354 lines in 2 files changed: 52 ins; 223 del; 79 mod

8343436: Regression in StackMapGenerator after JDK-8339205

Reviewed-by: liach

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

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

From aboldtch at openjdk.org  Mon Nov  4 07:23:51 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Mon, 4 Nov 2024 07:23:51 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
Message-ID: <XEofzXZ0eXgcHM6YxuJdJ9O2AKPkJIoK11pvwUYGb8c=.dcca51cf-3420-4066-b3a6-71c58041c173@github.com>

On Fri, 1 Nov 2024 19:37:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use lazySubmitRunContinuation when blocking

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:

> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
> 61:         MONITOR(3, "Monitor held"),
> 62:         CRITICAL_SECTION(4, "In critical section");

Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 

I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764

From alanb at openjdk.org  Mon Nov  4 08:02:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Nov 2024 08:02:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <XEofzXZ0eXgcHM6YxuJdJ9O2AKPkJIoK11pvwUYGb8c=.dcca51cf-3420-4066-b3a6-71c58041c173@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
 <XEofzXZ0eXgcHM6YxuJdJ9O2AKPkJIoK11pvwUYGb8c=.dcca51cf-3420-4066-b3a6-71c58041c173@github.com>
Message-ID: <BkN1BsPeLLAq5jaNhuPg6jhdvE5gOtPxRWJFlcHI06s=.b0ef271e-eb4e-4bad-a5d6-da42fb6186f6@github.com>

On Mon, 4 Nov 2024 07:21:19 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use lazySubmitRunContinuation when blocking
>
> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:
> 
>> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
>> 61:         MONITOR(3, "Monitor held"),
>> 62:         CRITICAL_SECTION(4, "In critical section");
> 
> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 
> 
> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue.

Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145

From alanb at openjdk.org  Mon Nov  4 08:09:28 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Nov 2024 08:09:28 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers
In-Reply-To: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
Message-ID: <adfKMfrf2qy4AxqN35fqCo7aMUj-Q39Omgl6usxSEV4=.508d84b3-cd62-46fc-afef-a0aa3c69c3e4@github.com>

On Thu, 31 Oct 2024 21:33:11 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
> Unit tests was not affected:
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp                                     516   516     0     0
>    jtreg:test/jdk/javax/xml                             70    70     0     0
> ==============================
> TEST SUCCESS
> 
> The tier1 is OK too.

Could this code be converted to use a j.u.c.Semaphore with a single permit? It has the tryAcquire/release that appears to be needed here.

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

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2454046752

From pminborg at openjdk.org  Mon Nov  4 08:11:27 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Nov 2024 08:11:27 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v8]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

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

 - Rephrase liker arg requirements
 - Merge branch 'master' into linker-padding-layout-only
 - Add rule checkings in AbstractLinker and add tests
 - Merge branch 'master' into linker-padding-layout-only
 - Update Linker docs
 - Merge branch 'master' into linker-padding-layout-only
 - Reword doce
 - Add to specification and refine detection of PL GLs
 - Add specific message for group layouts with only padding layouts
 - Merge branch 'master' into linker-padding-layout-only
 - ... and 7 more: https://git.openjdk.org/jdk/compare/77b221ef...0f4e93ff

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/8e4ee286..0f4e93ff

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

  Stats: 62307 lines in 1174 files changed: 16151 ins; 41965 del; 4191 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

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

From kbarrett at openjdk.org  Mon Nov  4 09:03:42 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 4 Nov 2024 09:03:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
Message-ID: <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>

On Mon, 4 Nov 2024 02:34:13 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize
>
> src/hotspot/share/adlc/adlc.hpp line 43:
> 
>> 41: 
>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */
>> 43: #ifdef _WIN32
> 
> As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct.

The deletion is apparently working, else we'd be getting build failures. So
while there are some potential issues and opportunities for further cleanup in
this file, I think they ought to be addressed separately from this PR. See
new https://bugs.openjdk.org/browse/JDK-8343530.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827395928

From dholmes at openjdk.org  Mon Nov  4 09:13:43 2024
From: dholmes at openjdk.org (David Holmes)
Date: Mon, 4 Nov 2024 09:13:43 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
 <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
Message-ID: <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>

On Mon, 4 Nov 2024 09:00:59 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> src/hotspot/share/adlc/adlc.hpp line 43:
>> 
>>> 41: 
>>> 42: /* Make sure that we have the intptr_t and uintptr_t definitions */
>>> 43: #ifdef _WIN32
>> 
>> As this is a synonym for `_WINDOWS` it is not obvious this deletion is correct.
>
> The deletion is apparently working, else we'd be getting build failures. So
> while there are some potential issues and opportunities for further cleanup in
> this file, I think they ought to be addressed separately from this PR. See
> new https://bugs.openjdk.org/browse/JDK-8343530.

There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827408129

From stuefe at openjdk.org  Mon Nov  4 09:24:58 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 4 Nov 2024 09:24:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

Can we get rid of `JNICALL` too, please? 

Or would that change be too big?

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454188077

From stefank at openjdk.org  Mon Nov  4 09:26:55 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Mon, 4 Nov 2024 09:26:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
 <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@github.com>
Message-ID: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.074f9493-482c-4fdb-81d8-d148d25b5c61@github.com>

On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.
>
> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore.

This code in `StackChunkAllocator::initialize` mimics the clearing code in:

void MemAllocator::mem_clear(HeapWord* mem) const {
  assert(mem != nullptr, "cannot initialize null object");
  const size_t hs = oopDesc::header_size();
  assert(_word_size >= hs, "unexpected object size");
  oopDesc::set_klass_gap(mem, 0);
  Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
}


but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:

  if (oopDesc::has_klass_gap()) {
    oopDesc::set_klass_gap(mem, 0);
  }


So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227

From alanb at openjdk.org  Mon Nov  4 09:31:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 4 Nov 2024 09:31:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
Message-ID: <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>

On Mon, 4 Nov 2024 09:21:52 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Can we get rid of `JNICALL` too, please?
> 
> Or would that change be too big?

There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454201348

From fabian at buildbuddy.io  Mon Nov  4 09:38:11 2024
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Mon, 4 Nov 2024 10:38:11 +0100
Subject: Allowing apps to force sun.jnu.encoding = "UTF-8" on Windows
In-Reply-To: <440fa736-4282-40ca-a084-aba1e14ab574@oracle.com>
References: <mailman.17375.1730309194.124.core-libs-dev@openjdk.org>
 <CAHY-eHva4JsvMfh18PxLp6jA9G254dB4a2EDT5xFr44s6rZHng@mail.gmail.com>
 <440fa736-4282-40ca-a084-aba1e14ab574@oracle.com>
Message-ID: <CAHY-eHv2H3SeT_UCUVj=z6=RJsnF17FLgYEmu1ZhPvvC-_ETBw@mail.gmail.com>

On Thu, Oct 31, 2024 at 11:26?PM Naoto Sato <naoto.sato at oracle.com> wrote:
> >> This has been discussed when we did JEP 400: UTF-8 by Default and
> >> decided not to do it, mainly because it affects filename/path encoding.
> >> Changing `sun.jnu.encoding` apart from Windows system encoding will make
> >> apps not being able to access those files/directories (e.g. home
> >> directory) if the path/name contains characters with different encodings.
> >
> > Based on grepping the source, it looks like the JDK (almost?)
> > exclusively uses the -W Windows APIs to interface with the file
> > system, with the active code page only being relevant for the internal
> > conversion between Java strings and platform UTF-16 strings through
> > `MultiByteToWideChar` and `WideCharToMultiByte` (via `CP_ACP`).
>
> I don't believe this assumption is correct. Java runtime is implicitly
> using Win32 ANSI calls, as it is not entirely compiled with `UNICODE`
> flag. Those calls would fail if ANSI code page differs from UTF-8.

I see, thank you for making me aware of this.

Would contributions in this area be welcome? If it is possible to get
to a state where this assumption does hold via incremental, behavior
preserving changes to the native Windows parts of the Java runtime,
that would potentially allow the codepage to be made configurable from
the java.exe command line in the future.

Fabian

From stuefe at openjdk.org  Mon Nov  4 09:44:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 4 Nov 2024 09:44:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
Message-ID: <S3to4nvu45BtZKorVzUHq4daKm1C0J9261npLggqSKY=.76940878-b961-4add-9e73-1db9cf1439b4@github.com>

On Fri, 1 Nov 2024 16:04:55 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize

This is a very nice reduction in complexity. As I wrote before, removing windows 32-bit removes the need for calling convention definition, so I think we could get rid of JNICALL in addition to anything stdcall/fastcall related.

I had a close look at hotspot os and os_cpu changes, cursory glances at other places, all looked fine.

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

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2412592195

From stuefe at openjdk.org  Mon Nov  4 09:47:41 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Mon, 4 Nov 2024 09:47:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
 <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
Message-ID: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>

On Mon, 4 Nov 2024 09:28:50 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Can we get rid of `JNICALL` too, please?
> > Or would that change be too big?
> 
> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.

Yeah. I count >8000 places in total...

Maybe just define JNICALL to be empty in jni_md.h for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2454234501

From kbarrett at openjdk.org  Mon Nov  4 10:01:45 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Mon, 4 Nov 2024 10:01:45 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
 <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
 <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>
Message-ID: <zXC1JUt1iWIVVKTAu6zq-g56ukWeObhMwwsXsiY4Uw4=.dfc3394c-c61b-4dda-809c-dd810ca64b83@github.com>

On Mon, 4 Nov 2024 09:11:16 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The deletion is apparently working, else we'd be getting build failures. So
>> while there are some potential issues and opportunities for further cleanup in
>> this file, I think they ought to be addressed separately from this PR. See
>> new https://bugs.openjdk.org/browse/JDK-8343530.
>
> There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR.

"using namespace std;" in a header is generally a bad idea. It brings all
kinds of stuff into scope, potentially leading to name conflicts down the
road.  And seems like a strange thing to do only for windows.

Removal of the strdup macro is covered by the NONSTDC macros added at build
time.  It's not a 32bit cleanup either, and you suggested it.

Removal of [u]intptr_t definitions will cause a build failure if it results in
them being undefined. And getting an incorrect definition from elsewhere seems
implausible. I claim this all just isn't needed anymore and can be removed in
this PR, just as you suggested for the strdup macro. The 64bit definitions
could be added back in this PR (to be removed later by JDK-8343530), but that
just seems like useless churn.

So I'm happy with the current removal of the entire chunk.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827469354

From mcimadamore at openjdk.org  Mon Nov  4 10:15:34 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 4 Nov 2024 10:15:34 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
 <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
Message-ID: <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>

On Fri, 1 Nov 2024 10:05:22 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 90:
>> 
>>> 88:         }
>>> 89: 
>>> 90:         STATE.setOpaque(this, CLOSED);
>> 
>> Why are we using opaque semantics here and not volatile?
>
> Because this variable is not used as a synchronization device, so a stronger order is unnecessary. We still need the store to be observed by other threads when they fail an `acquire` or a `close` so opaque is appropriate here.

I'm dubious about this. Typically these modes work in a symmetric way - if you `setOpaque` you need to `getOpaque`. From [this](https://gee.cs.oswego.edu/dl/html/j9mm.html):

> Opaque mode, obtained using VarHandle getOpaque and setOpaque, adds constraints over Plain mode that provide minimal awareness of a variable that is subject to interthread access, **when all accesses use Opaque (or stronger) mode**

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1827487516

From mcimadamore at openjdk.org  Mon Nov  4 10:17:32 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 4 Nov 2024 10:17:32 GMT
Subject: RFR: 8343188: Investigate ways to simplify MemorySegment::ofBuffer
 [v6]
In-Reply-To: <pVYGX6wZmTuYHmal4WosdcjOnGkQ8HaMJGsRhOiLmIo=.6ce2983d-ccc8-4170-b27f-88b8c513bacb@github.com>
References: <iSRWOFr_KAHjpsaBWNQAD4DWYjpIeVkVZ7IsfXWuQcc=.9eff90a5-396f-40d4-a4ba-e7463cf35120@github.com>
 <pVYGX6wZmTuYHmal4WosdcjOnGkQ8HaMJGsRhOiLmIo=.6ce2983d-ccc8-4170-b27f-88b8c513bacb@github.com>
Message-ID: <MaJutC6qL8rjE_xkNyFXvAu6TtfRGOHBJG027teASCc=.3ee0427f-c8f4-4a0a-a49f-156f889443c3@github.com>

On Fri, 1 Nov 2024 07:53:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to improve `MemorySegment::ofBuffer` making it more amenable to inlining and generally improving performance.
>> 
>> Testing successfully on tier1-6
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename methods

Marked as reviewed by mcimadamore (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21764#pullrequestreview-2412663461

From sgehwolf at openjdk.org  Mon Nov  4 10:38:47 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Nov 2024 10:38:47 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v40]
In-Reply-To: <nLafZx6UtWkuVSf3CNi_vi0AWRpGsy4LLqS8fwpJt4E=.3d64536a-8d44-4074-8577-fb527888c9f1@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <dzvJywrIZpOXOPMf8qqB4yBEdjZCQrVMStCpvvY7d3A=.94956783-7874-4dfd-a449-c6d379620af2@github.com>
 <KZP1m6p2Y3tAiSbpXcK-TRO7fL9Oegq2pg6WMoNAUxk=.70dcbe9f-1682-4f67-8f7c-4bc79d8158b8@github.com>
 <Q1KN8YsZRb1YlcnYfRetYBoutIHAqSD4fGg1wFZpyEU=.a7be37d6-3589-4657-9c27-1ba8284192de@github.com>
 <nLafZx6UtWkuVSf3CNi_vi0AWRpGsy4LLqS8fwpJt4E=.3d64536a-8d44-4074-8577-fb527888c9f1@github.com>
Message-ID: <mJTtR5XCSDsnEJ6nwpWQSSzJc6OV9C7XsqRDjq6R2sM=.d95f5a7d-96e2-488b-8784-297b1a7e93b5@github.com>

On Thu, 31 Oct 2024 21:59:27 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> > OK. It's currently part of the JEP, though which should explain what it does. Open for suggestions, though. I've taken inspiration from JVM features which use a similar `+/-` model.
> 
> I think it'd better to make this message human-understandable so that users do not need to read the JEP to find out what it means. What about:
> 
> ```
> Capabilities:
>    Run-time image linking enabled
> ```
> 
> or
> 
> ```
>    Linking from run-time image enabled
> ```
> 
> It also can be a "Capabilities" section, i.e. a line break which can help clearly separate this from the possible options. See what you and others think.

OK. I would prefer:


Capabilities:
    Linking from run-time image enabled


... as it would be more in-line with other wording of the feature.

@mbreinhold @AlanBateman Any preferences?

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2454355765

From pminborg at openjdk.org  Mon Nov  4 11:09:36 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Nov 2024 11:09:36 GMT
Subject: Integrated: 8343188: Investigate ways to simplify
 MemorySegment::ofBuffer
In-Reply-To: <iSRWOFr_KAHjpsaBWNQAD4DWYjpIeVkVZ7IsfXWuQcc=.9eff90a5-396f-40d4-a4ba-e7463cf35120@github.com>
References: <iSRWOFr_KAHjpsaBWNQAD4DWYjpIeVkVZ7IsfXWuQcc=.9eff90a5-396f-40d4-a4ba-e7463cf35120@github.com>
Message-ID: <kRimVpu5gFCqqtOs6UsAr3LQ4uLpBeQj4oHEjAIBmLs=.49be7539-93f3-441d-92b2-18db7b30c60d@github.com>

On Tue, 29 Oct 2024 14:51:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to improve `MemorySegment::ofBuffer` making it more amenable to inlining and generally improving performance.
> 
> Testing successfully on tier1-6

This pull request has now been integrated.

Changeset: f69b6016
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f69b6016d6160d7093c32a806c60d85cf9a02222
Stats:     356 lines in 9 files changed: 292 ins; 51 del; 13 mod

8343188: Investigate ways to simplify MemorySegment::ofBuffer

Reviewed-by: mcimadamore

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

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

From jvernee at openjdk.org  Mon Nov  4 11:17:29 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Nov 2024 11:17:29 GMT
Subject: RFR: 8340307: Add explanation around MemorySegment:reinterpret
 regarding arenas [v5]
In-Reply-To: <g-Ld4Y_Jf6aPeFUOrOz74yER33wYRg0zep4FPeKofPg=.95d19d7e-343d-44f7-b5b4-14017fec6f52@github.com>
References: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
 <g-Ld4Y_Jf6aPeFUOrOz74yER33wYRg0zep4FPeKofPg=.95d19d7e-343d-44f7-b5b4-14017fec6f52@github.com>
Message-ID: <80Iw7SY6RdvKCFDvPK2VtAWLxElPu5PdiAJsPoT6zS8=.5fdba977-b0ec-4718-9db9-1298ecbf20e2@github.com>

On Fri, 1 Nov 2024 09:11:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a small text segment on the `MemorySegment::reinterpret` overloads that takes an Arena stating the responsibility of actually freeing reinterpreted segments lies with the *original* arena.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reword reinterpret docs

Marked as reviewed by jvernee (Reviewer).

src/java.base/share/classes/java/lang/foreign/MemorySegment.java line 819:

> 817:      * that is, if the provided arena is a {@linkplain Arena#ofConfined() confined arena},
> 818:      * the returned segment can only be accessed by the arena's owner thread, regardless
> 819:      * of the confinement restrictions associated with this segment.In other words, this

Suggestion:

     * of the confinement restrictions associated with this segment. In other words, this

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

PR Review: https://git.openjdk.org/jdk/pull/21761#pullrequestreview-2412793690
PR Review Comment: https://git.openjdk.org/jdk/pull/21761#discussion_r1827568119

From mcimadamore at openjdk.org  Mon Nov  4 11:35:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 4 Nov 2024 11:35:30 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
 <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
 <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>
Message-ID: <lAEOqppEUsn93yvkT-tyz1ECFU09KbQqmZXwdmbORfA=.34b48ecd-d51d-4bed-b5b5-3c915749152a@github.com>

On Mon, 4 Nov 2024 10:12:47 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> I'm dubious about this. 

NVM, I see it now -`sharedSessionAlreadyAcquired` uses a `getVolatile` (which has stronger semantics), so we're in the clear.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1827588045

From roland at openjdk.org  Mon Nov  4 12:25:42 2024
From: roland at openjdk.org (Roland Westrelin)
Date: Mon, 4 Nov 2024 12:25:42 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long) [v4]
In-Reply-To: <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <SORE-JaaSAfTlOzjLCzOHgaSIb5Zy03Ri0XhrUzAUkY=.c5dca437-fe98-45fc-853b-e89b88f6ccf2@github.com>
Message-ID: <fGy7mKYzhsZQ-C1BvQAD3-09EqoinFdcDp63Y2_jcvw=.5967af04-5ce9-40f0-9884-6dceeaa4871f@github.com>

On Thu, 17 Oct 2024 10:10:56 GMT, Galder Zamarre?o <galder at openjdk.org> wrote:

>> This patch intrinsifies `Math.max(long, long)` and `Math.min(long, long)` in order to help improve vectorization performance.
>> 
>> Currently vectorization does not kick in for loops containing either of these calls because of the following error:
>> 
>> 
>> VLoop::check_preconditions: failed: control flow in loop not allowed
>> 
>> 
>> The control flow is due to the java implementation for these methods, e.g.
>> 
>> 
>> public static long max(long a, long b) {
>>     return (a >= b) ? a : b;
>> }
>> 
>> 
>> This patch intrinsifies the calls to replace the CmpL + Bool nodes for MaxL/MinL nodes respectively.
>> By doing this, vectorization no longer finds the control flow and so it can carry out the vectorization.
>> E.g.
>> 
>> 
>> SuperWord::transform_loop:
>>     Loop: N518/N126  counted [int,int),+4 (1025 iters)  main has_sfpt strip_mined
>>  518  CountedLoop  === 518 246 126  [[ 513 517 518 242 521 522 422 210 ]] inner stride: 4 main of N518 strip mined !orig=[419],[247],[216],[193] !jvms: Test::test @ bci:14 (line 21)
>> 
>> 
>> Applying the same changes to `ReductionPerf` as in https://github.com/openjdk/jdk/pull/13056, we can compare the results before and after. Before the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1155
>> long max   1173
>> 
>> 
>> After the patch, on darwin/aarch64 (M1):
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/hotspot/jtreg/compiler/loopopts/superword/ReductionPerf.java
>>                                                          1     1     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> long min   1042
>> long max   1042
>> 
>> 
>> This patch does not add an platform-specific backend implementations for the MaxL/MinL nodes.
>> Therefore, it still relies on the macro expansion to transform those into CMoveL.
>> 
>> I've run tier1 and hotspot compiler tests on darwin/aarch64 and got these results:
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PA...
>
> Galder Zamarre?o has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:
> 
>  - Use same default size as in other vector reduction benchmarks
>  - Renamed benchmark class
>  - Double/Float tests only when avx enabled
>  - Make state class non-final
>  - Restore previous benchmark iterations and default param size
>  - Add clipping range benchmark that uses min/max
>  - Encapsulate benchmark state within an inner class
>  - Avoid creating result array in benchmark method
>  - Merge branch 'master' into topic.intrinsify-max-min-long
>  - Revert "Implement cmovL as a jump+mov branch"
>    
>    This reverts commit 1522e26bf66c47b780ebd0d0d0c4f78a4c564e44.
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/b7ec22c4...0a8718e1

Looks good to me.

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

Marked as reviewed by roland (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20098#pullrequestreview-2412925659

From jvernee at openjdk.org  Mon Nov  4 12:26:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Nov 2024 12:26:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v8]
In-Reply-To: <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>
Message-ID: <g9Uv9uy2Rxwk-ThqQhJbqMKYfgRCuJsPBmfLUSrkONQ=.a21519c6-7733-444a-b29d-b8935f2a90d0@github.com>

On Mon, 4 Nov 2024 08:11:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
> 
>  - Rephrase liker arg requirements
>  - Merge branch 'master' into linker-padding-layout-only
>  - Add rule checkings in AbstractLinker and add tests
>  - Merge branch 'master' into linker-padding-layout-only
>  - Update Linker docs
>  - Merge branch 'master' into linker-padding-layout-only
>  - Reword doce
>  - Add to specification and refine detection of PL GLs
>  - Add specific message for group layouts with only padding layouts
>  - Merge branch 'master' into linker-padding-layout-only
>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7d8aec13...0f4e93ff

src/java.base/share/classes/java/lang/foreign/Linker.java line 245:

> 243:  * <p>
> 244:  * A native linker only supports function descriptors whose argument/return layouts are
> 245:  * <em>well-formed</em> layouts. More formally, a layout `L`is well-formed if:

Suggestion:

 * <em>well-formed</em> layouts. More formally, a layout `L` is well-formed if:

src/java.base/share/classes/java/lang/foreign/Linker.java line 271:

> 269:  * </ul>
> 270:  * <p>
> 271:  * Well-formed layouts in function descriptions consumed by a native linker constitutes

Suggestion:

 * Well-formed layouts in function descriptions consumed by a native linker constitute

src/java.base/share/classes/java/lang/foreign/Linker.java line 278:

> 276:  * member layouts, as well as avoiding padding at the end of the struct layout.
> 277:  * For example:
> 278:   * {@snippet lang = java:

Pre-existing, but, AFAIK "allows to avoid" only works when there is an object between 'allows' and 'to', e.g. "allows _a client_ to avoid".

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 224:

> 222: 
> 223:     // check elements are not all padding layouts and for trailing padding
> 224:     static private void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {

Suggestion:

    private static void checkGroup(GroupLayout gl, long maxUnpaddedOffset) {

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 259:

> 257:     }
> 258: 
> 259:     static void assertIsAlignedBy(GroupLayout gl, long index, PaddingLayout padding, MemoryLayout element) {

Suggestion:

    private static void assertIsAlignedBy(GroupLayout gl, long index, PaddingLayout padding, MemoryLayout element) {

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 270:

> 268:                     " does not align the element " + element +
> 269:                     " (at byte offset " + pos + ")" + inMessage(gl));
> 270:         }

What happens here if an element is already aligned, and `padding.byteSize() == element.byteAlignment()`? e.g. `MemoryLayout.structLayout(MemoryLayout.paddingLayout(4), ValueLayout.JAVA_INT)`?

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 273:

> 271:     }
> 272: 
> 273:     static String inMessage(GroupLayout gl) {

Suggestion:

    private static String inMessage(GroupLayout gl) {

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 282:

> 280:     // checks both that there is no excess padding between 'memberLayout' and
> 281:     // the previous layout
> 282:     static private void checkMemberOffset(StructLayout parent, MemoryLayout memberLayout,

Suggestion:

    private static void checkMemberOffset(StructLayout parent, MemoryLayout memberLayout,

test/jdk/java/foreign/TestLinker.java line 183:

> 181: 
> 182:         var fd = FunctionDescriptor.of(struct, struct, struct);
> 183:         assertThrows(IllegalArgumentException.class, () ->linker.downcallHandle(fd));

Suggestion:

        assertThrows(IllegalArgumentException.class, () -> linker.downcallHandle(fd));

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827569106
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827585098
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827646537
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827630470
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827632076
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827636857
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827637004
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827639797
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827643127

From jvernee at openjdk.org  Mon Nov  4 12:26:37 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Nov 2024 12:26:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v8]
In-Reply-To: <g9Uv9uy2Rxwk-ThqQhJbqMKYfgRCuJsPBmfLUSrkONQ=.a21519c6-7733-444a-b29d-b8935f2a90d0@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>
 <g9Uv9uy2Rxwk-ThqQhJbqMKYfgRCuJsPBmfLUSrkONQ=.a21519c6-7733-444a-b29d-b8935f2a90d0@github.com>
Message-ID: <iacWt-7SfGTZ5hBQN0Y7WTm9P2yHEXZYr_nVn_6EAHQ=.13a1962f-e3e5-4fe6-b764-a787199d900f@github.com>

On Mon, 4 Nov 2024 12:13:26 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:
>> 
>>  - Rephrase liker arg requirements
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - Add rule checkings in AbstractLinker and add tests
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - Update Linker docs
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - Reword doce
>>  - Add to specification and refine detection of PL GLs
>>  - Add specific message for group layouts with only padding layouts
>>  - Merge branch 'master' into linker-padding-layout-only
>>  - ... and 7 more: https://git.openjdk.org/jdk/compare/7d8aec13...0f4e93ff
>
> src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 270:
> 
>> 268:                     " does not align the element " + element +
>> 269:                     " (at byte offset " + pos + ")" + inMessage(gl));
>> 270:         }
> 
> What happens here if an element is already aligned, and `padding.byteSize() == element.byteAlignment()`? e.g. `MemoryLayout.structLayout(MemoryLayout.paddingLayout(4), ValueLayout.JAVA_INT)`?

Also, don't we already check the alignment before when calling `checkMemberOffset`? Why is it checked again here?

> test/jdk/java/foreign/TestLinker.java line 183:
> 
>> 181: 
>> 182:         var fd = FunctionDescriptor.of(struct, struct, struct);
>> 183:         assertThrows(IllegalArgumentException.class, () ->linker.downcallHandle(fd));
> 
> Suggestion:
> 
>         assertThrows(IllegalArgumentException.class, () -> linker.downcallHandle(fd));

Could you please check the exception message as well? And in `stackedPadding`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827639666
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1827644509

From qamai at openjdk.org  Mon Nov  4 13:20:31 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Mon, 4 Nov 2024 13:20:31 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <lAEOqppEUsn93yvkT-tyz1ECFU09KbQqmZXwdmbORfA=.34b48ecd-d51d-4bed-b5b5-3c915749152a@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
 <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
 <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>
 <lAEOqppEUsn93yvkT-tyz1ECFU09KbQqmZXwdmbORfA=.34b48ecd-d51d-4bed-b5b5-3c915749152a@github.com>
Message-ID: <qvFBWdanR_WQuUgcbv0k__lfCUprg5bzSGqth5zBP88=.3d47769b-c25b-4814-af92-4c1c793d581c@github.com>

On Mon, 4 Nov 2024 11:32:12 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> I'm dubious about this. Typically these modes work in a symmetric way - if you `setOpaque` you need to `getOpaque`. From [this](https://gee.cs.oswego.edu/dl/html/j9mm.html):
>> 
>>> Opaque mode, obtained using VarHandle getOpaque and setOpaque, adds constraints over Plain mode that provide minimal awareness of a variable that is subject to interthread access, **when all accesses use Opaque (or stronger) mode**
>
>> I'm dubious about this. 
> 
> NVM, I see it now -`sharedSessionAlreadyAcquired` uses a `getVolatile` (which has stronger semantics), so we're in the clear.

`checkValidStateRaw` synchronizes with `justClose` using handshakes so an opaque or higher load is only needed in `sharedSessionAlreadyClosed`. A `getOpaque` would probably be adequate. But I believe there is no formal restriction preventing the load from being hoisted out of the loop, so I decided to go for the strongest ordering in this exception-throwing case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1827717654

From liach at openjdk.org  Mon Nov  4 13:26:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Nov 2024 13:26:34 GMT
Subject: RFR: 8336043: Add quality of implementation discussion to
 Object.{equals, toString, hashCode} [v5]
In-Reply-To: <FlwWE7-b7CjTwMIOp9HsZMorcXwYb-5ZJaVmGcg8vko=.39984b8f-2157-4c76-94b2-4716f83c985f@github.com>
References: <hpG3kh3HNwzo1X2DFDlPTh9OgBWkPqA_puJtYNhCV14=.16432251-e2bd-405a-aab3-f56a2c752ddb@github.com>
 <T74gyqtJGSAYb6eTF--Y0DdYH0ttSf_dT8ARVDizPi8=.d71f44d5-61c6-417f-be4d-4c699895f9ee@github.com>
 <FlwWE7-b7CjTwMIOp9HsZMorcXwYb-5ZJaVmGcg8vko=.39984b8f-2157-4c76-94b2-4716f83c985f@github.com>
Message-ID: <VmmNoaG0Y_4jw7tgs4DiarUgvmdBIWGvwXaIX8UosYI=.36a7bdc9-83df-4265-86e8-8139c6dc844d@github.com>

On Fri, 4 Oct 2024 04:25:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
>> 
>>  - Fix typo found in code review.
>>  - Merge branch 'master' into JDK-8336043
>>  - Merge branch 'master' into JDK-8336043
>>  - Respond to review feedback.
>>  - Merge branch 'master' into JDK-8336043
>>  - Appease jcheck.
>>  - JDK-8336043: Add quality of implementation discussion to Object.{equals, toString, hashCode}
>
> src/java.base/share/classes/java/lang/Object.java line 211:
> 
>> 209:      * @see     #hashCode()
>> 210:      * @see     java.util.HashMap
>> 211:      * @see     ##objectOverrides Guidance for overriding {@code Object} methods
> 
> Is this rendered as code font? I think only `<`-starting text is not rendered as code font.

Update: I used the same pattern elsewhere and this code tag does work as intended,

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20128#discussion_r1827726090

From liach at openjdk.org  Mon Nov  4 13:27:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Nov 2024 13:27:39 GMT
Subject: Integrated: 8336267: Method and Constructor signature parsing can be
 shared on the root object
In-Reply-To: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
References: <X_X8E3QxD0XAudMJF3aepYInLheouqWsLWOadsW52eA=.88854049-e796-4e7c-ac43-673fb686d370@github.com>
Message-ID: <FLK_JMCu6QIB7L2mwOD87Yo9MwEIEdZhvW7Rpb_V5xk=.4651d226-e664-4caf-955f-97e5042cb237@github.com>

On Mon, 15 Jul 2024 04:05:55 GMT, Chen Liang <liach at openjdk.org> wrote:

> A straightforward optimization, to share the signature parsing of method, constructor, and field between the root and the copied objects, like how method handle accessors are shared.

This pull request has now been integrated.

Changeset: 8d6cfba3
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d6cfba37fe641e35886fdba536f5b2f1709e87b
Stats:     83 lines in 3 files changed: 11 ins; 26 del; 46 mod

8336267: Method and Constructor signature parsing can be shared on the root object

Reviewed-by: mchung

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

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

From liach at openjdk.org  Mon Nov  4 13:26:34 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Nov 2024 13:26:34 GMT
Subject: Integrated: 8343437: ClassDesc.of incorrectly permitting empty names
In-Reply-To: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
References: <_UnDVvNCr0pDmJO7S8QQkngvliI914yBs8EqY4lifnY=.fd9557a3-087c-457c-935b-6149fc19a7cb@github.com>
Message-ID: <lBCWkvDB8jEAV2THJvj3iIA6NS_q7Hjo33kNybn3cYA=.eb0dc6f2-9984-44de-aa72-b27ad5ff36b4@github.com>

On Fri, 1 Nov 2024 13:58:01 GMT, Chen Liang <liach at openjdk.org> wrote:

> In the patch for [JDK-8338544](https://bugs.openjdk.org/browse/JDK-8338544) #20665, the validation methods `validateBinaryClassName` and `validateInternalClassName` only checks if a separator char is the initial or final char, or if it immediately follows another chars.  This omitted the case of empty strings, and allowed creation of invalid ClassDesc with empty binary name, which is otherwise rejected by `ofDescriptor`.
> 
> To better check for the separator char, the tracking mechanism is updated to indicate a position where a separator char shouldn't appear, or where the name string should not terminate.  This is initially set to the initial position 0, and upon each time of encountering a separator, this is updated to the next char.
> 
> This logic is similar to the existing one in `skipOverFieldSignature`, which uses a boolean `legal` variable.  Both reject empty strings, leading and trailing separators, or consecutive separators.  The new logic, however, does not require repeated updates to the new `afterSeparator` variable upon scanning each character.
> 
> In addition, I noted the package name validation erroneously does not prohibit leading, trailing, or consecutive separator chars.  (Package names are derived from class or interface names, so the same restrictions shall apply)  This patch also makes package name validation reuse class or interface name validation in non-empty (unnamed package) cases, and added those cases to the test suite.

This pull request has now been integrated.

Changeset: 1f7d524f
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1f7d524fd3ecd932deb44b6fafdaa36c6bba4cb4
Stats:     109 lines in 5 files changed: 49 ins; 29 del; 31 mod

8343437: ClassDesc.of incorrectly permitting empty names

Reviewed-by: mchung

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

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

From pkoppula at openjdk.org  Mon Nov  4 13:28:23 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Mon, 4 Nov 2024 13:28:23 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v6]
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <voVtgoetIIqgzKRBJoFc18niFwRZWNyFTeF8W2SMvas=.80c02c7d-0c1a-4cfc-b5be-a840a30fdc81@github.com>

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  Handled nested wrappers around FileInputStream

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/6a015262..57e5936c

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

  Stats: 211 lines in 12 files changed: 44 ins; 91 del; 76 mod
  Patch: https://git.openjdk.org/jdk/pull/20414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20414/head:pull/20414

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

From ihse at openjdk.org  Mon Nov  4 13:47:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 13:47:56 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
Message-ID: <Y8kvmUtnCezhvB1jljWOqH9VpcbI3s6zoEnwil5vioo=.359da05a-afcb-4cfe-afe5-c1f5e63ae767@github.com>

On Thu, 31 Oct 2024 10:52:22 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Some test fixes
>  - Remove period in jlink.properties
>  - Revert changes to ResourcePoolEntry
>  - Fix comment in RuntimeImageLinkException
>  - Remove ImageReader (like JmodsReader)
>  - More comment fixes (JlinkTask)
>  - Move some comments around
>  - More comment fix-ups (JRTArchive)
>  - Fix description of configure option
>  - ... and 162 more: https://git.openjdk.org/jdk/compare/c40bb762...b702ba8c

Marked as reviewed by ihse (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2413110115

From fbredberg at openjdk.org  Mon Nov  4 14:00:55 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Mon, 4 Nov 2024 14:00:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
Message-ID: <PEExBTpPubCYRqoBU8sHuhGn7KxgJhWaRkGXiAJ22zA=.20d2683e-a50e-43e4-bc66-12c14540b42c@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269

From pminborg at openjdk.org  Mon Nov  4 14:08:08 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Nov 2024 14:08:08 GMT
Subject: RFR: 8340307: Add explanation around MemorySegment:reinterpret
 regarding arenas [v6]
In-Reply-To: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
References: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
Message-ID: <Bx9JX542CTwrkl0vRVODPbQS-jXmF6GCzYWBfj_Uhj0=.7833cae5-d3f3-4041-8d47-a14f35c43aed@github.com>

> This PR proposes to add a small text segment on the `MemorySegment::reinterpret` overloads that takes an Arena stating the responsibility of actually freeing reinterpreted segments lies with the *original* arena.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
  
  Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21761/files
  - new: https://git.openjdk.org/jdk/pull/21761/files/771804be..838f5138

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

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

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

From jvernee at openjdk.org  Mon Nov  4 14:11:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Nov 2024 14:11:32 GMT
Subject: RFR: 8340307: Add explanation around MemorySegment:reinterpret
 regarding arenas [v6]
In-Reply-To: <Bx9JX542CTwrkl0vRVODPbQS-jXmF6GCzYWBfj_Uhj0=.7833cae5-d3f3-4041-8d47-a14f35c43aed@github.com>
References: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
 <Bx9JX542CTwrkl0vRVODPbQS-jXmF6GCzYWBfj_Uhj0=.7833cae5-d3f3-4041-8d47-a14f35c43aed@github.com>
Message-ID: <8SNqXGAcugUCcBRRXthzKmxsmOoPZ-ITzUJv0sLAxm4=.fab30bb4-1aae-48ab-ab88-bd6b55973e12@github.com>

On Mon, 4 Nov 2024 14:08:08 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a small text segment on the `MemorySegment::reinterpret` overloads that takes an Arena stating the responsibility of actually freeing reinterpreted segments lies with the *original* arena.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/foreign/MemorySegment.java
>   
>   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21761#pullrequestreview-2413171645

From pminborg at openjdk.org  Mon Nov  4 14:15:35 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 4 Nov 2024 14:15:35 GMT
Subject: Integrated: 8340307: Add explanation around MemorySegment:reinterpret
 regarding arenas
In-Reply-To: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
References: <vx53mv8zyo2ZcQUz4TF2zWCzkyZsvdGQ0j0EZXlxUUU=.e2806f27-36b5-434f-9ce3-94cc1f343ce6@github.com>
Message-ID: <uY_nYIoIj-m6GpRy_fd_zbPsgamWtTBtveTxSfEdLSM=.864b3fa6-a15f-40b7-8176-2e4f4ac3e62c@github.com>

On Tue, 29 Oct 2024 12:20:01 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a small text segment on the `MemorySegment::reinterpret` overloads that takes an Arena stating the responsibility of actually freeing reinterpreted segments lies with the *original* arena.

This pull request has now been integrated.

Changeset: 646d64e8
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/646d64e88003ef2a2e1960cef0cc59d1a97bb912
Stats:     34 lines in 2 files changed: 29 ins; 0 del; 5 mod

8340307: Add explanation around MemorySegment:reinterpret regarding arenas

Reviewed-by: jvernee

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

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

From heidinga at openjdk.org  Mon Nov  4 14:23:33 2024
From: heidinga at openjdk.org (Dan Heidinga)
Date: Mon, 4 Nov 2024 14:23:33 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v6]
In-Reply-To: <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <Wa16sMIw3k7Ad2Fxj3OYhaxYzHsA0nZCYuRkmiUmSbg=.b2d64b08-8edb-47f4-9ab7-6e332950536c@github.com>
 <qM3nz9qI10MFZ14TlthOJERSf2LhhYCcIz5LpZvB8P8=.ad19e9dc-369b-40f9-b425-b682ec0202c6@github.com>
 <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com>
Message-ID: <w_FH1vXE90vHr6fftcrH0StwbxMGWWyffYwro_Qe-Yo=.5f4e2de8-7e4f-4471-a9c4-d033dd0139ad@github.com>

On Mon, 4 Nov 2024 03:08:02 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> src/hotspot/share/cds/aotClassInitializer.cpp line 348:
>> 
>>> 346:     }
>>> 347:     JavaValue result(T_VOID);
>>> 348:     JavaCalls::call_static(&result, ik,
>> 
>> Based on the discussions in JDK-8342283, do we need a memory fence after the call to runtimeSetup?
>> 
>> I think we do to be consistent with the non-AOTCache run as there is a fence after `<clinit>` (when this code would normally run) due to the initialization lock.
>
> I think this is already done:
> 
> `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. 
> 
> https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300

I think you're right about the memory fencing being covered there but reading that code shows another potential issue - what if the `runtimeSetup()` call throws an exception?

If I read `InstanceKlass::call_class_initializer()` correctly, an exception from `runtimeSetup()` will lead to marking the class as failing initialization (`initialization_error`) which will be an unexpected outcome as there may be instances of the class in the AOTCache that aren't produced by paths through the `<clinit>` method.

Classes are able to create an instance in `<clinit>` and escape it to other code and then fail initialization.  The instances are left in an odd state where after the `<clinit>` the instance methods can be called but static fields and static methods can't be accessed.

`runtimeSetup()` expands on this corner case which I think is OK for current "crawl" stage of our "crawl-walk-run" approach as its analogous to the existing `<clinit>` behaviour.  It may need refining in the future to abort the VM or do something else (?) in the case of failed `runtimeSetup` calls

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1827813351

From ihse at openjdk.org  Mon Nov  4 16:42:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:42:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v20]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <l_31uZeJj8FS4Ru5W6OcQcMSD8OtSqWIipI-yoUWm_k=.8d78d54c-b9fb-40ed-968a-20c7660eb5e1@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove __stdcall notation

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/d89bc561..fbd91ad0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=18-19

  Stats: 119 lines in 13 files changed: 0 ins; 1 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

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

From vklang at openjdk.org  Mon Nov  4 16:13:30 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Nov 2024 16:13:30 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
Message-ID: <xUT9qSpMQT5u8wCfE5xb0jkOqp4KzctVBpxcz9Osdlw=.35d21dcd-80cc-4e6c-b34c-ceb2ea115e09@github.com>

On Fri, 1 Nov 2024 10:58:09 GMT, kabutz <duke at openjdk.org> wrote:

>> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
>> 
>> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.
>
> Sure, where should I add that test?

@kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.

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

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2455121652

From ihse at openjdk.org  Mon Nov  4 16:11:44 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:11:44 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <Cc1Z7x6SVjqGjBRKwLciK-GnlFF1Xyc76p-4nwcvF4g=.b7e0b372-a2d2-4b61-ae1c-aa1b646700d4@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <5uPCX6VhNrAelasUotfss6G7iKyAHcyz7Fq2WiB8oZI=.db06929c-b219-4969-853f-9f68549723b3@github.com>
 <Cc1Z7x6SVjqGjBRKwLciK-GnlFF1Xyc76p-4nwcvF4g=.b7e0b372-a2d2-4b61-ae1c-aa1b646700d4@github.com>
Message-ID: <fmrIkRBDxIQLLWZkOB684A_agGnxeaOWiv-Eq6sTpBo=.c069a94b-1cb9-4bf9-b691-1bdd2b4ac65f@github.com>

On Sat, 2 Nov 2024 07:51:20 GMT, Alexander Zuev <kizune at openjdk.org> wrote:

>> make/modules/jdk.accessibility/Lib.gmk line 57:
>> 
>>> 55:   TARGETS += $(BUILD_LIBJAVAACCESSBRIDGE)
>>> 56: 
>>> 57:   ##############################################################################
>> 
>> Most of the desktop related changes are related to Assistive Technologies
>> I don't think we currently provide a 32-bit windowsaccessbridge.dll in the 64 bit JDK, but I'd like to be sure I am not forgetting something.
>> The point being windowsaccessbridge.dll is not loaded by the JDK, but by an AT, so traditionally we provided both 32 and 64 bit versions because we don't control that AT.
>> 
>> So I would like Alex Zuev to review these changes. For whatever reason his git hub handle doesn't seem to be found. I think it is something like @azuev-java
>
> We built 32-bit dll in order to provide access to the accessibility interfaces for the legacy 32-bit software that can not load the 32-bit code. We abandoned this practice since at least Java 11 and we had no complaints about it ever since. All the relevant accessibility software we are aware of have 64-bit executable and only support 32-bit operating systems with the legacy versions that are not recommended to use with modern OSes. I do not see any problem in abandoning 32-bit code in windowsaccessbridge.dll.

@azuev-java Thanks! I have one more question for you: To avoid risking breaking any compatibility, the file generated from the source code in `windowsaccessbridge` is still compiled into a file called `windowsaccessbridge-64.dll`.

This is a bit unusual, and requires a quirk in the build system -- normally we assume there is a 1-to-1 relationship between the directory containing the native library source code, and the generated `.dll` file.

Is this file exposed to external parties, that rely on a specific name? Or is it just used internally by the JDK, so we could rename it to `windowsaccessbridge.dll`, and just update our reference to it?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1827989703

From vklang at openjdk.org  Mon Nov  4 16:10:47 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Nov 2024 16:10:47 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v2]
In-Reply-To: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
Message-ID: <3J4BybOBLEvHajoowPmaESUb0lfmWvB51buu68o9mSQ=.78df4cd7-edc2-4ec4-9782-7f2bbf18cd53@github.com>

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Updating copyright years and removing an unneccessary import for Gatherers

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21686/files
  - new: https://git.openjdk.org/jdk/pull/21686/files/194c7695..189f2f85

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

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

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

From asotona at openjdk.org  Mon Nov  4 16:43:33 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Mon, 4 Nov 2024 16:43:33 GMT
Subject: RFR: 8343547: Restore accidentally removed annotations in
 LambdaForm from ClassFile API port
In-Reply-To: <yGA_kbsDxQNHJUnQq25kakeJyeEX89GIIJ6cFcYJ4fo=.fcb5b60b-8bf4-4468-b5d6-3050ddba972a@github.com>
References: <yGA_kbsDxQNHJUnQq25kakeJyeEX89GIIJ6cFcYJ4fo=.fcb5b60b-8bf4-4468-b5d6-3050ddba972a@github.com>
Message-ID: <E1eIyPj3MODTVRVxJ04WQHkG9euxp3-Mjdquexa07D4=.18f47e1a-0e68-42ce-99cc-26134af57fd5@github.com>

On Mon, 4 Nov 2024 15:47:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> These two annotations are found to be lost during the ClassFile API port of LambdaForm generation.  I seem not able to reproduce the master issue in a current build but could reproduce before when the change is first made.  Anyways this restoration is always a right thing, better commit it and further investigate.
> 
> Old Stable on BMH impl class static species field: https://github.com/openjdk/jdk/pull/17108/files#diff-3d6c6bed9cbcb47fe292bdb0c795ab77e56783fdbb144decc6f00857b020c092L612-L615
> 
> Incorrect way to add InjectedProfile annotation: https://github.com/openjdk/jdk/pull/17108/files#diff-3b05b61400e7766115409b3f508d839fb51e450423822252ab2e18543427c764R618

Good catch, thank you!

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

Marked as reviewed by asotona (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21880#pullrequestreview-2413572679

From ihse at openjdk.org  Mon Nov  4 16:53:48 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:53:48 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
 <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
 <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
Message-ID: <dYqkU6p0odvrMTRmYgM5_sSENvyiy7OPTEeWaYps7FA=.5a641a0c-e65a-4ee3-ba35-1e54b76f4b06@github.com>

On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

>>> Can we get rid of `JNICALL` too, please?
>>> 
>>> Or would that change be too big?
>> 
>> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.
>
>> > Can we get rid of `JNICALL` too, please?
>> > Or would that change be too big?
>> 
>> There's >1000 in java.base, lots more elsewhere, so it would be a lot of files and would hide the core changes. So maybe for a follow-up PR that does the one thing.
> 
> Yeah. I count >8000 places in total...
> 
> Maybe just define JNICALL to be empty in jni_md.h for now.

@tstuefe Your comment reminded me of another important cleanup, to remove `__stdcall` (and `_stdcall`, an accepted but not recommended variant) from the code base. This only has meaning on 32-bit Windows.

Furthermore, when searching for this, I found additional code that is looking for symbol names of "__stdcall format", i.e. `<name>@<number>`. This is not needed anymore. I'll delete it where I find it, but there might be other places that I'm missing.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455215002

From duke at openjdk.org  Mon Nov  4 16:17:31 2024
From: duke at openjdk.org (kabutz)
Date: Mon, 4 Nov 2024 16:17:31 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
Message-ID: <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>

On Fri, 1 Nov 2024 10:58:09 GMT, kabutz <duke at openjdk.org> wrote:

>> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
>> 
>> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.
>
> Sure, where should I add that test?

> @kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.

Indeed, I didn't check what happens when we create a spliterator on an empty collection.

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

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2455130638

From weijun at openjdk.org  Mon Nov  4 16:16:04 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Mon, 4 Nov 2024 16:16:04 GMT
Subject: RFR: 8343549: SeededSecureRandomTest needn't be in a package
Message-ID: <p-XvBPOkbxJ8BhZvjMGtX29wGcwB7ws1THcgxxiJPqM=.60f7d3a5-84c2-4770-b4cf-4773b5c52469@github.com>

The test was mistakenly put in a package as the library class it's testing. This is unnecessary since there is no internal field/method it needs access to.

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

Commit messages:
 - 8343549: SeededSecureRandomTest needn't be in a package

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

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

From ihse at openjdk.org  Mon Nov  4 16:23:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:23:06 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v18]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <BnN2NNTPOoC5clxA5LEplx4qwv2F0N2o_szfhAzHH2U=.c4c53af3-659f-4c70-91f0-61f802a56536@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore code in adlc.hpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/68d6fe5a..c6dce38d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=16-17

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

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

From ihse at openjdk.org  Mon Nov  4 16:23:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:23:06 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v18]
In-Reply-To: <zXC1JUt1iWIVVKTAu6zq-g56ukWeObhMwwsXsiY4Uw4=.dfc3394c-c61b-4dda-809c-dd810ca64b83@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <gjEMTecx6yY7x12uFt4K-dMFThNk9Rl_7cE23aKezvc=.8a00c542-3944-4011-b0ca-9ce67b975311@github.com>
 <DzEnHifh8q4ADSJbXZIjntch5ymH57Lvr2RltR44ku0=.adf8a552-8aa6-41a9-b356-c3011027cd14@github.com>
 <Z37DIH1Wux7LJ268nxu7MiB0v3RXMbsVmxasf3AN-8c=.1aaaaf2e-c017-4d51-b3f0-30f3602b439b@github.com>
 <zXC1JUt1iWIVVKTAu6zq-g56ukWeObhMwwsXsiY4Uw4=.dfc3394c-c61b-4dda-809c-dd810ca64b83@github.com>
Message-ID: <ne3jiyOsMfrRR78dRubq7XYN1IWPeB0yrRNaHfx32t8=.50e2fd0d-245b-4ba5-ac0b-788ad46a993b@github.com>

On Mon, 4 Nov 2024 09:58:49 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> There is a difference between "working" and not causing a build failure. I suspect none of that code is actually needed these days, but I'm not sure. As deleting the entire section goes beyond deleting 32-bit code, I would expect it to be partially restored in this PR and then cleaned up in a later PR.
>
> "using namespace std;" in a header is generally a bad idea. It brings all
> kinds of stuff into scope, potentially leading to name conflicts down the
> road.  And seems like a strange thing to do only for windows.
> 
> Removal of the strdup macro is covered by the NONSTDC macros added at build
> time.  It's not a 32bit cleanup either, and you suggested it.
> 
> Removal of [u]intptr_t definitions will cause a build failure if it results in
> them being undefined. And getting an incorrect definition from elsewhere seems
> implausible. I claim this all just isn't needed anymore and can be removed in
> this PR, just as you suggested for the strdup macro. The 64bit definitions
> could be added back in this PR (to be removed later by JDK-8343530), but that
> just seems like useless churn.
> 
> So I'm happy with the current removal of the entire chunk.

It was already quite tangential to the 32-bit windows removal effort. I've restored the original code (with the exception of the 32-bit Windows part) in this PR, so we don't have to argue about that. 

Let's remove this as a separate effort, presumably as part of JDK-8343530.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828003651

From ihse at openjdk.org  Mon Nov  4 16:23:06 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:23:06 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <dz67TFQIBrBwPO6xTUDbCV6JLG1jFntwVLsFtrjva3Y=.bf0c5bb8-8a77-4958-8166-a42717e09406@github.com>
 <Hd4towfj4MBGQL2gyrVDzsD9bdp3iqQ5VG6xOtfB5LA=.e5f13f6d-b354-486a-aca6-57968ef57ae2@github.com>
 <7TqkESttaCcs6m24LxWAp2Z5xoOARCTJfvH6GBMA5vw=.4076d8a2-48b9-4368-a5c8-3b48a09716dc@github.com>
Message-ID: <wusCVNALP98v4yha8evAdBZUokZY5sEhJ5Eo2zx8n70=.7ff6d430-0b29-4eb9-a89b-38fef3a933de@github.com>

On Mon, 4 Nov 2024 09:45:05 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> Can we get rid of `JNICALL` too, please?

That we can never do, since it is part of jni.h which are imported in likely millions of JNI projects. But we can replace it with an empty define. And we can document it as not needed anymore, and start removing it from our own call sites.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455142166

From vklang at openjdk.org  Mon Nov  4 15:43:31 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 4 Nov 2024 15:43:31 GMT
Subject: RFR: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <1Q6wo6OX55b9sQLmblNwQsP8WtssXu9xKsb_h0RuMfY=.004df1a6-5914-4525-87c1-df87d64df03f@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

@kabutz This should now be ready to integrate ?

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

PR Comment: https://git.openjdk.org/jdk/pull/21783#issuecomment-2455046625

From naoto at openjdk.org  Mon Nov  4 17:03:34 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Nov 2024 17:03:34 GMT
Subject: RFR: 8333582: Update CLDR to Version 46.0 [v2]
In-Reply-To: <vwyPn_mWPIeHvteo6lmkD5H27EJRXjdQlBiBKVfkbcY=.597a468f-f00b-440a-bc1e-ebbe1b20b8b2@github.com>
References: <BC9maq8cicKr97KrRECyl-I_IulD7I4N07p2hmkACuo=.217bf2ae-9a89-4e88-b7d7-78de0aa2ce89@github.com>
 <vwyPn_mWPIeHvteo6lmkD5H27EJRXjdQlBiBKVfkbcY=.597a468f-f00b-440a-bc1e-ebbe1b20b8b2@github.com>
Message-ID: <0zYQ9HaoqGWKd2ujs7BtystGLV6pYBeWg1VoGkzbfa4=.31cdb5ca-c1bc-4c17-a1e3-468ed91cccf4@github.com>

On Thu, 31 Oct 2024 20:06:24 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Upgrading the CLDR to version 46.0. A corresponding CSR has also been drafted.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Addresses review comments

Thank you for your reviews!

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

PR Comment: https://git.openjdk.org/jdk/pull/21772#issuecomment-2455235506

From naoto at openjdk.org  Mon Nov  4 17:03:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 4 Nov 2024 17:03:35 GMT
Subject: Integrated: 8333582: Update CLDR to Version 46.0
In-Reply-To: <BC9maq8cicKr97KrRECyl-I_IulD7I4N07p2hmkACuo=.217bf2ae-9a89-4e88-b7d7-78de0aa2ce89@github.com>
References: <BC9maq8cicKr97KrRECyl-I_IulD7I4N07p2hmkACuo=.217bf2ae-9a89-4e88-b7d7-78de0aa2ce89@github.com>
Message-ID: <wKo8yGcB_PuBErspWVxUY3F12FMPCo7eN3OA4OcSuu8=.f8692184-8fb7-406c-b10e-b46bdf247bbf@github.com>

On Tue, 29 Oct 2024 18:12:43 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Upgrading the CLDR to version 46.0. A corresponding CSR has also been drafted.

This pull request has now been integrated.

Changeset: 1c448347
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1c4483473d878bb4c41e66f27fea84ef81ede8c9
Stats:     114740 lines in 290 files changed: 91794 ins; 7333 del; 15613 mod

8333582: Update CLDR to Version 46.0

Reviewed-by: joehw, srl, jlu

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

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

From ihse at openjdk.org  Mon Nov  4 15:45:36 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 15:45:36 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <vxhfWryABYSWDMPG3TTmQBUoi-z5OkhPUF0bQ64blBU=.b74728ed-dae2-4553-9891-0cbc0f04b4a4@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
 <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>
 <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com>
 <zuGp6ZwW6hvpfdwvlHMmHfnsa2hVkVaMOYKMp872ZIA=.9c95a697-5fc3-4104-89bc-3ad637ed72f3@github.com>
 <vxhfWryABYSWDMPG3TTmQBUoi-z5OkhPUF0bQ64blBU=.b74728ed-dae2-4553-9891-0cbc0f04b4a4@github.com>
Message-ID: <uafaHSc5vudgReFhOKcGwa6yB1YvX50hImvxj3PoH3c=.a1e2fa2f-b15e-4bf2-b0b8-e68de5f7e6d5@github.com>

On Sun, 3 Nov 2024 05:06:04 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> Please fix the debugging symbol issue in your PR.

That is a request with most likely a whole other magnitude of difficulty. Our handling of debug symbols and all its intricacies is tightly coupled to the existing dynamic linking process. I suggest handling that as a follow-up PR.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455052907

From ihse at openjdk.org  Mon Nov  4 15:45:35 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 15:45:35 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <QTb-tea1pfPsfImYqrkNr_6WmSq5hLt6d57zZ4Q4Uf0=.b6cdbf11-a7f0-4a6d-8d66-54d35523f33f@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <QTb-tea1pfPsfImYqrkNr_6WmSq5hLt6d57zZ4Q4Uf0=.b6cdbf11-a7f0-4a6d-8d66-54d35523f33f@github.com>
Message-ID: <YhJAMueYTwUslag0LiYIW2IfpVDVjRobbOOmWDK8yJw=.cab87631-4293-4bec-898c-f9f68cbef163@github.com>

On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into static-jdk-image
>>  - Fix bug in filtering out -Wl,--exclude-libs,ALL
>>  - Don't hardcode server variant
>>  - Setup LDFLAGS_STATIC_JDK
>>  - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>>  - Add lookup asserts
>>  - Remove superfluous SRC.
>>  - Merge branch 'master' into static-jdk-image
>>  - Makefile changes needed for static-launcher and static-jdk-image targets
>>  - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher
>
> https://github.com/openjdk/jdk/pull/21861 for adding DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries.

@jianglizhou I'm trying to follow your comments here... Am I correct in understanding that you are saying that the missing DEF_STATIC_JNI_OnLoad is not, in fact, the problem that causes .java files to not load? Because I tried applying your patch from #21861, and it did not help.

> I think we would need to decide what is the `dll_dir` with the static JDK support and hermetic support.

Do you mean that this the core issue related to the .java launching failure? 

I also find it curious that it does work on macOS, but not on Linux. This indicates, to me, that there is some difference in platform-dependent code that is different between Linux and mac, and there is not much such code in this PR. So maybe it is some pre-existing difference in code that provokes this difference in behavior.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455046552

From ihse at openjdk.org  Mon Nov  4 16:28:14 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:28:14 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v19]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <ry3di_toZWQQc2kWuGeEKSqjCZgcx4JnV6qdRSadSqA=.d3586b29-650d-41e2-bbc8-4a6ec16da688@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Make JNICALL an empty define on all platforms

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/c6dce38d..d89bc561

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=17-18

  Stats: 7 lines in 3 files changed: 2 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

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

From kvn at openjdk.org  Mon Nov  4 17:04:43 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 4 Nov 2024 17:04:43 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
Message-ID: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>

On Mon, 4 Nov 2024 16:04:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?

Yes, I completely agree to do such clean up in separate RFE. Please, file one.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455239110

From liach at openjdk.org  Mon Nov  4 15:51:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Nov 2024 15:51:40 GMT
Subject: RFR: 8343547: Restore accidentally removed annotations in LambdaForm
 from ClassFile API port
Message-ID: <yGA_kbsDxQNHJUnQq25kakeJyeEX89GIIJ6cFcYJ4fo=.fcb5b60b-8bf4-4468-b5d6-3050ddba972a@github.com>

These two annotations are found to be lost during the ClassFile API port of LambdaForm generation.  I seem not able to reproduce the master issue in a current build but could reproduce before when the change is first made.  Anyways this restoration is always a right thing, better commit it and further investigate.

Old Stable on BMH impl class static species field: https://github.com/openjdk/jdk/pull/17108/files#diff-3d6c6bed9cbcb47fe292bdb0c795ab77e56783fdbb144decc6f00857b020c092L612-L615

Incorrect way to add InjectedProfile annotation: https://github.com/openjdk/jdk/pull/17108/files#diff-3b05b61400e7766115409b3f508d839fb51e450423822252ab2e18543427c764R618

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

Commit messages:
 - 8343547: Restore accidentally removed annotations in LambdaForm from ClassFile API port

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

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

From ihse at openjdk.org  Mon Nov  4 17:11:42 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 17:11:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
 <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
Message-ID: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>

On Mon, 4 Nov 2024 17:01:33 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
> 
> Yes, I completely agree to do such clean up in separate RFE. Please, file one.

Good. I filed https://bugs.openjdk.org/browse/JDK-8343553.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455256779

From sgehwolf at openjdk.org  Mon Nov  4 17:12:48 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Nov 2024 17:12:48 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v41]
In-Reply-To: <u3QCQVCYbEQD9OJUmJ3iyBJaPEyUf3Icx6lOPRB0dYI=.fccd5f9b-9c67-4cf7-8987-f4bee65ddf41@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <mnrlicciszRsr_gfxAwe1NoDMchShnACmKomUdG0W0E=.83ad3034-1a15-46e9-aaa6-4bff5ef74547@github.com>
 <u3QCQVCYbEQD9OJUmJ3iyBJaPEyUf3Icx6lOPRB0dYI=.fccd5f9b-9c67-4cf7-8987-f4bee65ddf41@github.com>
Message-ID: <2GSl3m0s1YFbwJkOLF_wdIcL5AU-lIR2KfIK_wRyBo4=.b7cfb2be-663a-40b5-9f05-a5646d84d218@github.com>

On Wed, 30 Oct 2024 22:41:49 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with 20 additional commits since the last revision:
>> 
>>  - Some test fixes
>>  - Remove period in jlink.properties
>>  - Revert changes to ResourcePoolEntry
>>  - Fix comment in RuntimeImageLinkException
>>  - Remove ImageReader (like JmodsReader)
>>  - More comment fixes (JlinkTask)
>>  - Move some comments around
>>  - More comment fix-ups (JRTArchive)
>>  - Fix description of configure option
>>  - Some more wording updates
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/83a86d06...e6b3aeb1
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 195:
> 
>> 193:             plugins.storeFiles(allContent.resourcePool(), result, writer);
>> 194:         } catch (RuntimeImageLinkException e) {
>> 195:             throwRuntimeLinkFailure(e);
> 
> Curious why this is a special case.  Would it be useful for debugging if this throws `new IOException(e)` the same way as other exceptions (line 196-200) so RILE is a cause?

This is in fact not needed. I've removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1828083387

From kvn at openjdk.org  Mon Nov  4 17:20:04 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 4 Nov 2024 17:20:04 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
 <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
 <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>
Message-ID: <RUDYCsjg6mr_MGqrram9-Soh9YmYallGgR1mOIdCB7M=.a59b1627-2588-4ae4-b23d-6033257219d3@github.com>

On Mon, 4 Nov 2024 17:08:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
>> 
>> Yes, I completely agree to do such clean up in separate RFE. Please, file one.
>
>> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
>> 
>> Yes, I completely agree to do such clean up in separate RFE. Please, file one.
> 
> Good. I filed https://bugs.openjdk.org/browse/JDK-8343553.

@magicus
Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ?

I see only few uses of `#ifdef WIN32`  in HotSpot which can be replaced with `#ifdef _WINDOWS`:

src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32


Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455274589

From sgehwolf at openjdk.org  Mon Nov  4 17:21:54 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Nov 2024 17:21:54 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v41]
In-Reply-To: <u3QCQVCYbEQD9OJUmJ3iyBJaPEyUf3Icx6lOPRB0dYI=.fccd5f9b-9c67-4cf7-8987-f4bee65ddf41@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <mnrlicciszRsr_gfxAwe1NoDMchShnACmKomUdG0W0E=.83ad3034-1a15-46e9-aaa6-4bff5ef74547@github.com>
 <u3QCQVCYbEQD9OJUmJ3iyBJaPEyUf3Icx6lOPRB0dYI=.fccd5f9b-9c67-4cf7-8987-f4bee65ddf41@github.com>
Message-ID: <mY-SgxVnyB4y3KkwKH6Rrvar1rE2sMovwPsJ7wD67-g=.02e0f7d0-b9d5-45b8-abc2-8db260a90f22@github.com>

On Wed, 30 Oct 2024 22:44:45 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with 20 additional commits since the last revision:
>> 
>>  - Some test fixes
>>  - Remove period in jlink.properties
>>  - Revert changes to ResourcePoolEntry
>>  - Fix comment in RuntimeImageLinkException
>>  - Remove ImageReader (like JmodsReader)
>>  - More comment fixes (JlinkTask)
>>  - Move some comments around
>>  - More comment fix-ups (JRTArchive)
>>  - Fix description of configure option
>>  - Some more wording updates
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/83a86d06...e6b3aeb1
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 255:
> 
>> 253:         } catch (RuntimeImageLinkException re) {
>> 254:             // Might be thrown when linking from the current run-time image.
>> 255:             // Populate the actual reason.
> 
> `// Populate the actual reason.`  - this comment no longer applies?

Indeed. This isn't needed as it's handled closer to when the exception actually happens. I've removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1828095360

From ihse at openjdk.org  Mon Nov  4 16:06:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 16:06:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
Message-ID: <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>

On Fri, 1 Nov 2024 18:11:13 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove superfluous check for 64-bit on Windows in MacroAssembler::call_clobbered_xmm_registers
>>  - Remove windows-32-bit code in CompilerConfig::ergo_initialize
>
> Okay, I am confuse about `_WIN32` vs `WIN32`. 
> 
> You are saying that "_WIN32 is still defined on 64-bit Windows" but you are removing code guarded by `#ifdef _WIN32`
> And our make files defines `WIN32` for all Windows OSs: https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470

@vnkozlov 

> * There is use of `WIN32` instead of `_WIN32`.
> 
> * There are comments referencing `Win32` which we need to rename to `Windows` to avoid confusion.
> 
> * There is `class os::win32` in `os_windows.hpp` which is batter to rename to avoid confusion. Could be done in separate RFE.
> 
> * "Note that, oddly enough, _WIN32 is still defined on 64-bit Windows". If it is really true, I would still suggest to use our variable `_WINDOWS` for that.

Ok. Let's start with being on the same page about the meaning of "win32". This is what Microsoft has to say about it:

"The Win32 API (also called the Windows API) is the native platform for Windows apps. [T]he same functions are generally supported on 32-bit and 64-bit Windows." 

https://learn.microsoft.com/en-us/windows/win32/apiindex/api-index-portal#win32-windows-api

I'd say that they are the authoritative source on the subject. :-)

So technically there is nothing **wrong** with stuff targeting Windows being called "win32", even if we only support 64-bit Windows going forward. 

With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?

I will, however, do an additional round of checking all the grep hits on "win32" left to double-and-triple check that they indeed are not 32-bit specific.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455104589

From ihse at openjdk.org  Mon Nov  4 17:31:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 17:31:00 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v21]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/fbd91ad0..dccf1a1d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=19-20

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

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

From ihse at openjdk.org  Mon Nov  4 17:31:00 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 17:31:00 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v17]
In-Reply-To: <RUDYCsjg6mr_MGqrram9-Soh9YmYallGgR1mOIdCB7M=.a59b1627-2588-4ae4-b23d-6033257219d3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <744vRgDE2j7k5m3fmY1VMRi9RfCp-Zv8S5E8fFTZjUM=.350bd708-835b-47c5-a2a0-6305532e504c@github.com>
 <QDUDAiuOeTPy0T1QvkvOGujm-UyJ9lWrJgVpk61vGNw=.a601eae9-f20f-4d66-86c9-bc04ef6a3fc6@github.com>
 <zB_PvD6pSU3OI_n9QFm1coJL_J5GKbh5CxqEJKe8_BI=.4a67ca59-6f11-4fa9-b559-e7d53afd641d@github.com>
 <983rSW6uDF8scEsxAYntO_WksMrncX4VHtz4IH4HDpQ=.ada7fe61-1778-4f5f-bbf5-81d95bf59c2c@github.com>
 <2rYz-9j1EvPFwZilHh5ac_zn6TJX9fZRacU4Bl9k9u0=.21cd45d6-873f-404b-ac9b-c66b071eb631@github.com>
 <RUDYCsjg6mr_MGqrram9-Soh9YmYallGgR1mOIdCB7M=.a59b1627-2588-4ae4-b23d-6033257219d3@github.com>
Message-ID: <5af9UbiLlBKx6KCuroe94EZxYiD0d9jqmt6TSgYp4XM=.e1b42d0c-4d70-46c6-9e00-bc3e102bf9ec@github.com>

On Mon, 4 Nov 2024 17:16:49 GMT, Vladimir Kozlov <kvn at openjdk.org> wrote:

>>> > With that said, it is sure as heck confusing! Which also apparently Microsoft acknowledges by phasing in the term "Windows API". So I agree that we should try to rename everything currently called "win32" into "windows". But I'd rather see such a global rename refactoring, that will also affect the 64-bit Windows platforms, to be done as a separate, follow-up PR. Are you okay with that?
>>> 
>>> Yes, I completely agree to do such clean up in separate RFE. Please, file one.
>> 
>> Good. I filed https://bugs.openjdk.org/browse/JDK-8343553.
>
> @magicus
> Back to my question about https://github.com/openjdk/jdk/blob/master/make/autoconf/flags-cflags.m4#L470 ?
> 
> I see only few uses of `#ifdef WIN32`  in HotSpot which can be replaced with `#ifdef _WINDOWS`:
> 
> src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
> src/hotspot/share/runtime/sharedRuntimeTrans.cpp:#ifdef WIN32
> 
> 
> Note, there are a lot more usages of `WIN32` in JDK libraries native code which we may consider renaming later.

@vnkozlov I have now looked at all ~1800 case-independent hits of "win32" in the `src` directory. All of them is referring to the general Windows API, and not any 32-bit specific code, as far as I can tell from the filename and local context.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455296938

From syan at openjdk.org  Mon Nov  4 15:06:39 2024
From: syan at openjdk.org (SendaoYan)
Date: Mon, 4 Nov 2024 15:06:39 GMT
Subject: RFR: 8341585: Test java/foreign/TestUpcallStress.java should mark
 as /native
In-Reply-To: <1wdAhGmXZSblEkHkYVZYImVRhvaMUklYV0Tba2-RxFs=.42420c1b-6975-488a-af3a-602f4354c851@github.com>
References: <1wdAhGmXZSblEkHkYVZYImVRhvaMUklYV0Tba2-RxFs=.42420c1b-6975-488a-af3a-602f4354c851@github.com>
Message-ID: <9Edh3mxZr9a9NNLPh5nURV0mWkAHjvFnFb2Iy9tZcxI=.de721c04-a90e-494a-acbb-e7d7c56c4532@github.com>

On Sun, 6 Oct 2024 02:35:45 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The newly added test `java/foreign/TestUpcallStress.java` call `System.loadLibrary("TestUpcall")` load native library, so this test should mark as `/native`.
> The change has been verified locally, trivial fix, no risk.

Hi, can anyone take look this PR

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

PR Comment: https://git.openjdk.org/jdk/pull/21374#issuecomment-2454952884

From kvn at openjdk.org  Mon Nov  4 17:49:43 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Mon, 4 Nov 2024 17:49:43 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v21]
In-Reply-To: <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <4KQSjDq_ocYrb8cb81S57U_DtDcuRNcyUfeoQz4a6As=.11d47b0f-381e-4159-85e5-6f95ce742619@github.com>
Message-ID: <UCODrURe99cINxVpVWuWvlF5pHBHbtUEMZNTi8fmHYY=.4c0f7994-cc3b-473b-8f2e-a7e320838813@github.com>

On Mon, 4 Nov 2024 17:31:00 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp

HotSpot VM changes are good for me.

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

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2413705033

From sgehwolf at openjdk.org  Mon Nov  4 18:14:50 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Nov 2024 18:14:50 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v41]
In-Reply-To: <u3QCQVCYbEQD9OJUmJ3iyBJaPEyUf3Icx6lOPRB0dYI=.fccd5f9b-9c67-4cf7-8987-f4bee65ddf41@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <mnrlicciszRsr_gfxAwe1NoDMchShnACmKomUdG0W0E=.83ad3034-1a15-46e9-aaa6-4bff5ef74547@github.com>
 <u3QCQVCYbEQD9OJUmJ3iyBJaPEyUf3Icx6lOPRB0dYI=.fccd5f9b-9c67-4cf7-8987-f4bee65ddf41@github.com>
Message-ID: <sxuZfkLhuZusU6BNM7A7UesMM5aA3WWoGLTrXnR-aUA=.f5281fcd-21cf-47ce-b1b5-6a750788198d@github.com>

On Wed, 30 Oct 2024 23:23:11 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with 20 additional commits since the last revision:
>> 
>>  - Some test fixes
>>  - Remove period in jlink.properties
>>  - Revert changes to ResourcePoolEntry
>>  - Fix comment in RuntimeImageLinkException
>>  - Remove ImageReader (like JmodsReader)
>>  - More comment fixes (JlinkTask)
>>  - Move some comments around
>>  - More comment fix-ups (JRTArchive)
>>  - Fix description of configure option
>>  - Some more wording updates
>>  - ... and 10 more: https://git.openjdk.org/jdk/compare/83a86d06...e6b3aeb1
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/ImageFileCreator.java line 399:
> 
>> 397:             String mResource = String.format(DIFF_PATH, module);
>> 398:             List<ResourceDiff> diff = perModDiffs.get(module);
>> 399:             if (diff == null) {
> 
> Can `diff` ever be null?   ` preparePerModuleDiffs` ensures that the return map has one entry for each module and empty list if no diff.
> 
> For the case with no diff, do you expect EMPTY_RESOURCE_BYTES or a `ResourceDiff` content with header & zero entry?
> 
> Perhaps line 377-386 in `preparePerModuleDiffs` can simply be removed and let `addDiffResourcesFiles` to handle no resource diff case as it does now.
> 
> 
>         Map<String, List<ResourceDiff>> allModsToDiff = new HashMap<>();
>         modules.stream().forEach(m -> {
>             List<ResourceDiff> d = modToDiff.get(m);
>             if (d == null) {
>                 // Not all modules will have a diff
>                 allModsToDiff.put(m, Collections.emptyList());
>             } else {
>                 allModsToDiff.put(m, d);
>             }
>         });
>         return allModsToDiff;

The diff can never be null. `ReasourceDiff.read(InputStream)` expects at least a proper header. So for a module without diff there will be small files with two integers, the magic and `0` (number of items). I've changed this code to no longer check for `null` and expanded the comment. Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1828178083

From pchilanomate at openjdk.org  Mon Nov  4 18:18:23 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:18:23 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - Update comment block in objectMonitor.cpp
 - Fix issue with unmounted virtual thread when dumping heap
 - Remove ThawBase::possibly_adjust_frame()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/52c26642..11396312

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=27-28

  Stats: 349 lines in 14 files changed: 219 ins; 101 del; 29 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Mon Nov  4 18:21:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:21:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>
Message-ID: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@github.com>

On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.
>
> Here's my suggested C2 change:
> 
> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
> index d9c77a2f529..1e99db191ae 100644
> --- a/src/hotspot/cpu/aarch64/aarch64.ad
> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
> @@ -3692,14 +3692,13 @@ encode %{
>        __ post_call_nop();
>      } else {
>        Label retaddr;
> +      // Make the anchor frame walkable
>        __ adr(rscratch2, retaddr);
> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>        __ lea(rscratch1, RuntimeAddress(entry));
> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>        __ blr(rscratch1);
>        __ bind(retaddr);
>        __ post_call_nop();
> -      __ add(sp, sp, 2 * wordSize);
>      }
>      if (Compile::current()->max_vector_size() > 0) {
>        __ reinitialize_ptrue();

Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
@RealFYang I made the equivalent change for riscv, could you verify it's okay?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069

From pchilanomate at openjdk.org  Mon Nov  4 18:21:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:21:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <5p5ZR8m0OB0ZZQMgKN4-itJXsTvaP_WUbivgnIhNQSQ=.43607f75-eb3c-4f20-a7a0-691b83a27cf1@github.com>
Message-ID: <TWEXqyc2FnVrOO5eN1HMJQvlW9EoSrPVA8KntfcJOa8=.52901d8f-526e-4236-8c36-82bcdac14584@github.com>

On Tue, 29 Oct 2024 22:58:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix comment in VThreadWaitReenter
>
> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316:
> 
>> 314:     pc = ContinuationHelper::return_address_at(
>> 315:            sp - frame::sender_sp_ret_address_offset());
>> 316:   }
> 
> You could do this with an overload instead:
> 
> static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) {
>   assert(pc != nullptr, "");
>   [...]
> }
> static void set_anchor(JavaThread* thread, intptr_t* sp) {
>   address pc = ContinuationHelper::return_address_at(
>     sp - frame::sender_sp_ret_address_offset());
>   set_anchor(thread, sp, pc);
> }
> 
> but the compiler probably optmizes the above check just fine.

Added an overload method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178

From sgehwolf at openjdk.org  Mon Nov  4 18:22:53 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Nov 2024 18:22:53 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <LHdUgG-I0a28i0ja9uAcEhHi3yn1AP6_Jhso0y1HSRM=.744de79a-528e-4c80-9197-31291915d6ca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <LHdUgG-I0a28i0ja9uAcEhHi3yn1AP6_Jhso0y1HSRM=.744de79a-528e-4c80-9197-31291915d6ca@github.com>
Message-ID: <dBtCZ3sA9ezmEqBX_j6YxXdMCoL9ltMSAEr579BgZF0=.a8194995-a7df-40b5-b0ab-5f50c4f2e08f@github.com>

On Thu, 31 Oct 2024 17:53:01 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits:
>> 
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Some test fixes
>>  - Remove period in jlink.properties
>>  - Revert changes to ResourcePoolEntry
>>  - Fix comment in RuntimeImageLinkException
>>  - Remove ImageReader (like JmodsReader)
>>  - More comment fixes (JlinkTask)
>>  - Move some comments around
>>  - More comment fix-ups (JRTArchive)
>>  - Fix description of configure option
>>  - ... and 162 more: https://git.openjdk.org/jdk/compare/c40bb762...b702ba8c
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 229:
> 
>> 227:                                 throw new RuntimeImageLinkException(msg);
>> 228:                             } else {
>> 229:                                 // System.err vs taskHelper.warning?
> 
> It's my leftover comment.   I think this error or warning message should be localized.   But this would require to access `JlinkTask::taskHelper`.    This needs to consider what is the better way (possibly some other existing cases too) and okay to leave it as is. 
> 
> Suggest to move this comment in line 224 and something like:
> `// need to consider if this error or message should be localized`

This should be localized, indeed. I've gone ahead and passed a taskHelper instance down to `JRTArchive` which should solve this problem. `RuntimeImageLinkException` now doesn't contain any localized strings anymore, but sufficient info to do the localization elsewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1828187603

From nbenalla at openjdk.org  Mon Nov  4 18:23:09 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 4 Nov 2024 18:23:09 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v5]
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <4-lQd203dPu_BrGHaQurU5SI7TC0BK2h0ACqRNNbH_4=.2582d879-b8c6-40b9-88af-123d476de853@github.com>

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Rename tests and directories under modules dir

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21542/files
  - new: https://git.openjdk.org/jdk/pull/21542/files/e973302b..dda5f1b6

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

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

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

From pchilanomate at openjdk.org  Mon Nov  4 18:28:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:28:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
Message-ID: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876

From pchilanomate at openjdk.org  Mon Nov  4 18:28:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:28:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
Message-ID: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>

On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
>> 
>> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)
>
> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>
I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725

From pchilanomate at openjdk.org  Mon Nov  4 18:28:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:28:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <SM504TzexcuCwSNOScAbu1GjkUX4Jc1e4doztojHRiU=.59a30ae5-9cc0-472a-b807-1cf190ee5775@github.com>
Message-ID: <3ThzYwhF_zfOZCcLiTcQIYjPtA5mNuUYZLWjiH3zJGE=.a4c97906-8a38-4af9-9cee-2c26b1f35271@github.com>

On Fri, 25 Oct 2024 04:40:24 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - Rename set/has_owner_anonymous to set/has_anonymous_owner
>>  - Fix comments in javaThread.hpp and Thread.java
>>  - Rename nonce/nounce to seqNo in VirtualThread class
>>  - Remove ObjectMonitor::set_owner_from_BasicLock()
>
> src/hotspot/share/runtime/objectMonitor.cpp line 132:
> 
>> 130: 
>> 131: // -----------------------------------------------------------------------------
>> 132: // Theory of operations -- Monitors lists, thread residency, etc:
> 
> This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage

Updated comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851

From liach at openjdk.org  Mon Nov  4 18:29:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 4 Nov 2024 18:29:31 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v2]
In-Reply-To: <zvOlVozGs_y3wT3BPPdVPSG-pMZSon_S9jkoDYObhN4=.0b54a387-3926-460a-90a2-3a98cbc41ff1@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <zvOlVozGs_y3wT3BPPdVPSG-pMZSon_S9jkoDYObhN4=.0b54a387-3926-460a-90a2-3a98cbc41ff1@github.com>
Message-ID: <cN9PxkA-TmCSKrHxXRSaZvGeZv5s0nafAQEDZaB0Wzs=.0cb21a43-1493-4f49-8922-2b42eb918f70@github.com>

On Sun, 3 Nov 2024 03:13:25 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Update copyright years.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove unnecessary @SuppressWarnings annotations.

java.lang.invoke/reflect and jdk.internal.classfile changes look good.

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

PR Review: https://git.openjdk.org/jdk/pull/21852#pullrequestreview-2413824024

From nbenalla at openjdk.org  Mon Nov  4 18:30:50 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 4 Nov 2024 18:30:50 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v6]
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <fBPuS7YR_HLfktERI27HgDiEpp1SiV42VXSCfBcP450=.10284966-be20-4c6f-a35c-ae2f3e961677@github.com>

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  tiny change in test summary

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21542/files
  - new: https://git.openjdk.org/jdk/pull/21542/files/dda5f1b6..07530dec

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

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

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

From sgehwolf at openjdk.org  Mon Nov  4 18:32:54 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Nov 2024 18:32:54 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <LHdUgG-I0a28i0ja9uAcEhHi3yn1AP6_Jhso0y1HSRM=.744de79a-528e-4c80-9197-31291915d6ca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <LHdUgG-I0a28i0ja9uAcEhHi3yn1AP6_Jhso0y1HSRM=.744de79a-528e-4c80-9197-31291915d6ca@github.com>
Message-ID: <3MFZydlkSCopgoomZS7hg8MaZrOHy7RZvowUcjv4-7U=.7cba287e-4c76-475b-a909-8174b7f5d858@github.com>

On Thu, 31 Oct 2024 18:20:36 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits:
>> 
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Some test fixes
>>  - Remove period in jlink.properties
>>  - Revert changes to ResourcePoolEntry
>>  - Fix comment in RuntimeImageLinkException
>>  - Remove ImageReader (like JmodsReader)
>>  - More comment fixes (JlinkTask)
>>  - Move some comments around
>>  - More comment fix-ups (JRTArchive)
>>  - Fix description of configure option
>>  - ... and 162 more: https://git.openjdk.org/jdk/compare/c40bb762...b702ba8c
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/LinkableRuntimeImage.java line 77:
> 
>> 75:             }
>> 76:             return null;
>> 77:         }
> 
> the callers of this method catches `IOException` and the handler is different.   It seems to me that this method should just throw IOException.   Returns null only if no diff file for that module is present.

OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1828200301

From pchilanomate at openjdk.org  Mon Nov  4 18:36:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Mon, 4 Nov 2024 18:36:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
Message-ID: <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.cafd8577-6aeb-4d4e-beaf-bc2148f28783@github.com>

On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update comment block in objectMonitor.cpp
>  - Fix issue with unmounted virtual thread when dumping heap
>  - Remove ThawBase::possibly_adjust_frame()

I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391

From sgehwolf at openjdk.org  Mon Nov  4 18:55:47 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 4 Nov 2024 18:55:47 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <LHdUgG-I0a28i0ja9uAcEhHi3yn1AP6_Jhso0y1HSRM=.744de79a-528e-4c80-9197-31291915d6ca@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <LHdUgG-I0a28i0ja9uAcEhHi3yn1AP6_Jhso0y1HSRM=.744de79a-528e-4c80-9197-31291915d6ca@github.com>
Message-ID: <iLd1w2JzRttnEJIrNRtKNVQFXKM4jBdsyuaG1scKHBU=.960bca53-e23a-4bba-abef-72d60d5e9b1a@github.com>

On Thu, 31 Oct 2024 18:37:50 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits:
>> 
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Some test fixes
>>  - Remove period in jlink.properties
>>  - Revert changes to ResourcePoolEntry
>>  - Fix comment in RuntimeImageLinkException
>>  - Remove ImageReader (like JmodsReader)
>>  - More comment fixes (JlinkTask)
>>  - Move some comments around
>>  - More comment fix-ups (JRTArchive)
>>  - Fix description of configure option
>>  - ... and 162 more: https://git.openjdk.org/jdk/compare/c40bb762...b702ba8c
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 123:
> 
>> 121: \ and cannot be used to create another image with the jdk.jlink module
>> 122: err.runtime.link.packaged.mods=--keep-packaged-modules is not allowed. This run-time image capable JDK\
>> 123: \ does not include packaged modules
> 
> I think this error indicates that this JDK does not have any packaged modules, i.e. no default module path `jmods` directory.
> 
> It may be clearer to say:
> 
> Suggestion:
> 
> err.runtime.link.packaged.mods=This JDK has no packaged modules.  --keep-packaged-modules is not supported.

Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1828214396

From mullan at openjdk.org  Mon Nov  4 19:06:28 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 4 Nov 2024 19:06:28 GMT
Subject: RFR: 8343549: SeededSecureRandomTest needn't be in a package
In-Reply-To: <p-XvBPOkbxJ8BhZvjMGtX29wGcwB7ws1THcgxxiJPqM=.60f7d3a5-84c2-4770-b4cf-4773b5c52469@github.com>
References: <p-XvBPOkbxJ8BhZvjMGtX29wGcwB7ws1THcgxxiJPqM=.60f7d3a5-84c2-4770-b4cf-4773b5c52469@github.com>
Message-ID: <LPpfNx2emlTkyNPO8IYDFrRwNC8EPLLxMFNZ6qgzyIo=.e6e3eb36-4890-4095-97f0-70b3158fa31e@github.com>

On Mon, 4 Nov 2024 16:09:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The test was mistakenly put in a package as the library class it's testing. This is unnecessary since there is no internal field/method it needs access to.

Marked as reviewed by mullan (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21881#pullrequestreview-2413892403

From jiangli at openjdk.org  Mon Nov  4 19:08:34 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 4 Nov 2024 19:08:34 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <QTb-tea1pfPsfImYqrkNr_6WmSq5hLt6d57zZ4Q4Uf0=.b6cdbf11-a7f0-4a6d-8d66-54d35523f33f@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <QTb-tea1pfPsfImYqrkNr_6WmSq5hLt6d57zZ4Q4Uf0=.b6cdbf11-a7f0-4a6d-8d66-54d35523f33f@github.com>
Message-ID: <YEF8Ipx1qy0fn-Mg9ke29QN2ln5wUcVT_JMTMf5f3CI=.92198077-acca-4fea-b992-7ee2743cdd70@github.com>

On Sun, 3 Nov 2024 20:23:32 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
>> 
>>  - Merge branch 'master' into static-jdk-image
>>  - Fix bug in filtering out -Wl,--exclude-libs,ALL
>>  - Don't hardcode server variant
>>  - Setup LDFLAGS_STATIC_JDK
>>  - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>>  - Add lookup asserts
>>  - Remove superfluous SRC.
>>  - Merge branch 'master' into static-jdk-image
>>  - Makefile changes needed for static-launcher and static-jdk-image targets
>>  - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher
>
> https://github.com/openjdk/jdk/pull/21861 for adding DEF_STATIC_JNI_OnLoad in libjimage and libsaproc native libraries.

> @jianglizhou I'm trying to follow your comments here... Am I correct in understanding that you are saying that the missing DEF_STATIC_JNI_OnLoad is not, in fact, the problem that causes .java files to not load? Because I tried applying your patch from #21861, and it did not help.

The missing`DEF_STATIC_JNI_OnLoad` in jimage.cpp **is** the cause. With the fix, running `static-jdk/bin/java` with `HelloWorld.java` now works for me without failure:


build/linux-x86_64-server-slowdebug/images/static-jdk$ bin/java ~/tests/HelloWorld.java
HelloWorld


> Because I tried applying your patch from #21861, and it did not help.

Did you do a clean build? I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well. 

Please do `make clean` and rebuild the `images` and `static-jdk-image` to test if you are still running into any failure. If you are still seeing failures, please send me the specific build and run commands.

> 
> > I think we would need to decide what is the `dll_dir` with the static JDK support and hermetic support.
> 
> Do you mean that this the core issue related to the .java launching failure?

No, the `dll_dir` issue that I pointed out earlier was not the cause. 

With static JDK support, `libjimage` is statically linked with  `static-jdk/bin/java`. When `loadLibrary()` is called to "load" the `jimage` native library, the system first looks for built-in `jimage` native library by looking up `JNI_OnLoad_jimage` symbol. If the symbol exists, it means the `libjimage` is built in and there is no need to `dlopen` the native library from `dll_dir`. That's why the `dll_dir` issue is not the root cause.  If it can't find `JNI_OnLoad_jimage` symbol, the system would try to load `libjimage.so` from `dll_dir`. However, that should never happen with static JDK.

`JNI_OnLoad_jimage` symbol is defined by `DEF_STATIC_JNI_OnLoad` macro. That's why the missing `DEF_STATIC_JNI_OnLoad` in jimage.cpp is the root cause of the `loadLibrary()` failure.

> 
> I also find it curious that it does work on macOS, but not on Linux. This indicates, to me, that there is some difference in platform-dependent code that is different between Linux and mac, and there is not much such code in this PR. So maybe it is some pre-existing difference in code that provokes this difference in behavior.

I think the macOS might have other bugs that masks this failure. As we discussed in hermetic Java meetings, let's focus on supporting the Linux platform initially.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455483797

From jiangli at openjdk.org  Mon Nov  4 19:08:35 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 4 Nov 2024 19:08:35 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
Message-ID: <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>

On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into static-jdk-image
>  - Fix bug in filtering out -Wl,--exclude-libs,ALL
>  - Don't hardcode server variant
>  - Setup LDFLAGS_STATIC_JDK
>  - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>  - Add lookup asserts
>  - Remove superfluous SRC.
>  - Merge branch 'master' into static-jdk-image
>  - Makefile changes needed for static-launcher and static-jdk-image targets
>  - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher

Fixed a typo in above comment: **does** should be **doesn't**

> I notice incremental build with your current PR does update `static-jdk/bin/java` properly. This should be fixed as well.

Should be:

I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455487724

From jvernee at openjdk.org  Mon Nov  4 19:13:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Nov 2024 19:13:32 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
Message-ID: <oH_J8_wZzlu_LFf0CX6U6H6x4e9ZTQpPav3iIYOzoNE=.a873fd15-fc91-4492-ae67-14e9377b16cb@github.com>

On Fri, 1 Nov 2024 02:44:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wait for the close operation to complete on acquire failures

src/java.base/share/classes/jdk/internal/foreign/MemorySessionImpl.java line 62:

> 60:     /**
> 61:      * The value of the {@code state} of a {@code MemorySessionImpl}. The only possible transition
> 62:      * is OPEN -> CLOSED. As a result, the states CLOSED and UNCLOSEABLE are stable. This allows us

Suggestion:

     * is OPEN -> CLOSED. As a result, the states CLOSED and NONCLOSEABLE are stable. This allows us

src/java.base/share/classes/jdk/internal/foreign/SharedSession.java line 101:

> 99:         }
> 100:         return alreadyClosed();
> 101:     }

It would be good to add a test that tries to trigger this use case. e.g. have 2 threads which share a shared arena. One will try to close the arena, while the other will try to pass a segment allocated from the arena to a downcall.

test/micro/org/openjdk/bench/java/lang/foreign/LoopOverRandom.java line 65:

> 63:     @Setup
> 64:     public void setup() {
> 65:         indices = new Random().ints(0, ELEM_COUNT).limit(ELEM_COUNT).toArray();

Please use a fixed seed here, to avoid instability due to data being different.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1828237651
PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1828241119
PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1828247752

From jvernee at openjdk.org  Mon Nov  4 19:13:33 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 4 Nov 2024 19:13:33 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <qvFBWdanR_WQuUgcbv0k__lfCUprg5bzSGqth5zBP88=.3d47769b-c25b-4814-af92-4c1c793d581c@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
 <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
 <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>
 <lAEOqppEUsn93yvkT-tyz1ECFU09KbQqmZXwdmbORfA=.34b48ecd-d51d-4bed-b5b5-3c915749152a@github.com>
 <qvFBWdanR_WQuUgcbv0k__lfCUprg5bzSGqth5zBP88=.3d47769b-c25b-4814-af92-4c1c793d581c@github.com>
Message-ID: <XB8L2-EcMcGxNmh2djEvPyCRf71xRJGo83vUMRA_oPA=.d3c6d0d4-bf24-4531-b681-719384298787@github.com>

On Mon, 4 Nov 2024 13:17:23 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> I'm dubious about this. 
>> 
>> NVM, I see it now -`sharedSessionAlreadyAcquired` uses a `getVolatile` (which has stronger semantics), so we're in the clear.
>
> `checkValidStateRaw` synchronizes with `justClose` using handshakes so an opaque or higher load is only needed in `sharedSessionAlreadyClosed`. A `getOpaque` would probably be adequate. But I believe there is no formal restriction preventing the load from being hoisted out of the loop, so I decided to go for the strongest ordering in this exception-throwing case.

Doesn't using `setOpaque` mean that another thread may see the update to `state` before the update to `acquireCount`? i.e. the scope of a memory segment may appear closed, but the segment would still be passable to a downcall?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1828246949

From ihse at openjdk.org  Mon Nov  4 19:27:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:27:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v22]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <x6Pztt-6Gln_n6KupQyMWJz6Hm-T5uEp-X5gvCD9gWo=.99aa2cbd-60c9-400f-b458-780f4b0238ae@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Also remove __cdecl
 - Also remove __stdcall on tests

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/dccf1a1d..82fbc51e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=20-21

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

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

From ihse at openjdk.org  Mon Nov  4 19:35:42 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:35:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v22]
In-Reply-To: <x6Pztt-6Gln_n6KupQyMWJz6Hm-T5uEp-X5gvCD9gWo=.99aa2cbd-60c9-400f-b458-780f4b0238ae@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <x6Pztt-6Gln_n6KupQyMWJz6Hm-T5uEp-X5gvCD9gWo=.99aa2cbd-60c9-400f-b458-780f4b0238ae@github.com>
Message-ID: <z6snV3KAVf4l0V8WVmg-7j-iTvmOHPEc63xaMECNDAs=.d6e8e32a-eeb5-402a-a6b2-cb6f619b19ad@github.com>

On Mon, 4 Nov 2024 19:27:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Also remove __cdecl
>  - Also remove __stdcall on tests

I created https://bugs.openjdk.org/browse/JDK-8343560 to track the possible removal of `JNICALL` in the JDK source. Ultimately, we need to decide if it is worth the churn, or if we should keep it "just in case" some future platform will require a special keyword in that location (utterly unlikely as it might seem). If we go ahead with it, there are additional "downstream" fixes that needs to go with it, I highlighted some in the JBS issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455537378

From ihse at openjdk.org  Mon Nov  4 19:45:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:45:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v23]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <Dpblra5ruIoDlXQ3V4X9fuLO4FZze26zdZ3-VVbenQE=.8cf7fc72-c864-497a-b8cb-a0aa4f5996f8@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/82fbc51e..b5a481db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=21-22

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

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

From naoto.sato at oracle.com  Mon Nov  4 19:46:21 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Mon, 4 Nov 2024 11:46:21 -0800
Subject: Allowing apps to force sun.jnu.encoding = "UTF-8" on Windows
In-Reply-To: <CAHY-eHv2H3SeT_UCUVj=z6=RJsnF17FLgYEmu1ZhPvvC-_ETBw@mail.gmail.com>
References: <mailman.17375.1730309194.124.core-libs-dev@openjdk.org>
 <CAHY-eHva4JsvMfh18PxLp6jA9G254dB4a2EDT5xFr44s6rZHng@mail.gmail.com>
 <440fa736-4282-40ca-a084-aba1e14ab574@oracle.com>
 <CAHY-eHv2H3SeT_UCUVj=z6=RJsnF17FLgYEmu1ZhPvvC-_ETBw@mail.gmail.com>
Message-ID: <d24fd299-3af2-4b5d-aa59-61be6294bcf2@oracle.com>

Hi Fabian,

On 11/4/24 1:38 AM, Fabian Meumertzheim wrote:
> 
> Would contributions in this area be welcome? If it is possible to get
> to a state where this assumption does hold via incremental, behavior
> preserving changes to the native Windows parts of the Java runtime,
> that would potentially allow the codepage to be made configurable from
> the java.exe command line in the future.

I am afraid that the risk that would be involved in configuring 
sun.jnu.encoding exceeds the benefit it would bring, as the encoding is 
so baked in the basis of the Windows Java runtime. Since Microsoft 
itself now recommends users choose UTF-8 as the ANSI code page (over 
changing apps to use -W APIs)[1], I think we would want to wait for that 
glorious day.

Naoto

[1] 
https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page#-a-vs--w-apis

From xuelei at openjdk.org  Mon Nov  4 19:48:37 2024
From: xuelei at openjdk.org (Xue-Lei Andrew Fan)
Date: Mon, 4 Nov 2024 19:48:37 GMT
Subject: RFR: 8315487: Security Providers Filter [v9]
In-Reply-To: <KCl1GCy11MAYdSIVlLQ3P5aVA7r2G-mxixox7ahr9Do=.87cc6cee-369a-48d4-abe2-c8f02b9a7656@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
 <KCl1GCy11MAYdSIVlLQ3P5aVA7r2G-mxixox7ahr9Do=.87cc6cee-369a-48d4-abe2-c8f02b9a7656@github.com>
Message-ID: <IUJhhVA_7JVJc98Uc60Z1uNxjCx8RssVevy7JQT2sUs=.b200e500-ce2d-4399-a290-59a9ba5443ec@github.com>

On Mon, 21 Oct 2024 18:30:50 GMT, Martin Balao <mbalao at openjdk.org> wrote:

>> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
>> 
>> ## ProvidersFilter
>> 
>> ### Filter construction (parser)
>> 
>> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
>> 
>> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
>> 
>> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
>> 
>> ### Filter (structure and behavior)
>> 
>> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an all...
>
> Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains eight commits:
> 
>  - Remove -Xdebug from commented-out debug command
>    
>    This is unnecessary, see 842d6329cf5a3da8df7eddb195b5fcb7baadbdc3.
>  - Merge 'openjdk/master' into JDK-8315487
>    
>    Resolved conflicts:
>      src/java.base/share/classes/java/security/Provider.java
>      src/java.base/share/classes/javax/crypto/Cipher.java
>      src/java.base/share/classes/sun/security/jca/ProviderList.java
>      src/java.base/share/conf/security/java.security
>      src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
>    
>    Additional fixes:
>      src/java.base/share/classes/java/security/Security.java
>        Import sun.security.jca.ProvidersFilter, since the sun.security.jca.*
>        import was removed in c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab.
>      src/java.base/share/classes/sun/security/jca/GetInstance.java
>        Adjust GetInstance::getCipherServices return type to Iterator<Service>.
>      src/java.base/share/classes/sun/security/jca/ProvidersFilter.java
>        Rename CipherServiceList to CipherServiceIterator in comment.
>  - Minor changes to align with the JEP.
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - ProvidersFilterTest extended to cover all JCA service types.
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at openjdk.org>
>  - Support for cipher transformations and JEP alignment
>    of the java.security documentation.
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>
>  - Copyright dates update.
>  - More clear text in invalid pattern exception.
>  - 8315487: Security Providers Filter
>    
>    Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
>    Co-authored-by: Martin Balao <mbalao at redhat.com>

This update is really too big to review in details.  There are 5512 lines changed, 4881 ins and 631 del per the webrev data.  If I read the description and code right, there are three types of update in this PR:
1. bug fixes of the current OpenJDK code.
2. A provider filter API design to check if a service is allowed in a certain circumstances.
3. A provider filter implementation in java.security to perform the service checking.

I may use multiple PR for this purpose:
1. Multiple pull requests to fix bugs.
2. Design a public API to check if a service is allowed and update the JDK code accordingly.  A public API design will allow third party to define their own service restriction policy, without depends on the java.security.
3. Implement the provider filter with java security property.

The 1st and 2nd one should be small enough, straightforward to implementation and easy to integrate.  The 3rd one could big, but it will be an implementation details, and it can even be optional.  As would make it easy to review and backport.

Just for your reference.

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

PR Comment: https://git.openjdk.org/jdk/pull/15539#issuecomment-2455562203

From ihse at openjdk.org  Mon Nov  4 19:58:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 19:58:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v24]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <Ta0FXWyz21fb4BXFGpdid-OOz3Kpx2XGcgela6DPaVI=.890a9ca1-1c20-4212-8430-b64468a94819@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  buildJniFunctionName is now identical on Windows and Unix, so unify it

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/b5a481db..466a1a7a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=22-23

  Stats: 48 lines in 4 files changed: 8 ins; 40 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

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

From ihse at openjdk.org  Mon Nov  4 20:02:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:02:32 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v25]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <iqs_Vw8IIhc7MIkMdLUctlY5D5giJ6CUb-W2bD-o2Ps=.52368e54-2e67-457f-ba81-8a37b3b72afe@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix build_agent_function_name to not handle "@"-stdcall style names

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/466a1a7a..88d89e75

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=23-24

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

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

From ihse at openjdk.org  Mon Nov  4 20:18:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:18:23 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v26]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <3ZIvKBKdzJvYU91TwQcAGKUlDENAC5D5VNUFjI8zQzA=.a81d7ec5-c2ba-4eb0-ba78-c94ef65c8e28@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/88d89e75..6f690d02

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=24-25

  Stats: 21 lines in 3 files changed: 7 ins; 14 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

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

From joehw at openjdk.org  Mon Nov  4 20:20:38 2024
From: joehw at openjdk.org (Joe Wang)
Date: Mon, 4 Nov 2024 20:20:38 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers
In-Reply-To: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
Message-ID: <LjzgJLKLBG0W2UAM0RDYtWGIh2iibywMGLYSrnhzkQ4=.9e5d93be-9328-4db0-a907-883aa7cf07d1@github.com>

On Thu, 31 Oct 2024 21:33:11 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
> Unit tests was not affected:
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp                                     516   516     0     0
>    jtreg:test/jdk/javax/xml                             70    70     0     0
> ==============================
> TEST SUCCESS
> 
> The tier1 is OK too.

Also, could you share the specjvm2008 results before and after the patch, with/without high vCPU numbers?

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

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2455621057

From ihse at openjdk.org  Mon Nov  4 20:21:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:21:09 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v27]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <_PNwSCgsqsInETeof5O-P5dZUGus72uvmtcYomw1QII=.eb53d7ac-250c-40cc-9fb5-68d5d3b15dd6@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  JVM_EnqueueOperation do not need __stdcall name lookup anymore

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/6f690d02..48d722bf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=25-26

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

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

From ihse at openjdk.org  Mon Nov  4 20:23:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:23:56 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v28]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <-YUW42BZ3ZY4k5baNUWfHqBlItoEyoOsXOMPxp_mvyM=.e3f414f4-c1c5-40db-ab72-debeb41968f5@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 33 commits:

 - Merge branch 'master' into impl-JEP-479
 - JVM_EnqueueOperation do not need __stdcall name lookup anymore
 - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them
 - Fix build_agent_function_name to not handle "@"-stdcall style names
 - buildJniFunctionName is now identical on Windows and Unix, so unify it
 - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer
 - Also remove __cdecl
 - Also remove __stdcall on tests
 - Replace WIN32 with _WINDOWS in sharedRuntimeTrans.cpp
 - Remove __stdcall notation
 - ... and 23 more: https://git.openjdk.org/jdk/compare/8b474971...699c641a

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

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27
  Stats: 1885 lines in 84 files changed: 86 ins; 1572 del; 227 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

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

From ihse at openjdk.org  Mon Nov  4 20:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:29:23 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v29]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <EaFAHeLJflBYWwQTxGjCz2ClnvCZwAzU406A_hWCCXA=.18cc681b-0c4b-4e34-a5b3-569b0dc59bd7@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright years

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/699c641a..40291b9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=27-28

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

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

From ihse at openjdk.org  Mon Nov  4 20:38:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:38:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v29]
In-Reply-To: <EaFAHeLJflBYWwQTxGjCz2ClnvCZwAzU406A_hWCCXA=.18cc681b-0c4b-4e34-a5b3-569b0dc59bd7@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <EaFAHeLJflBYWwQTxGjCz2ClnvCZwAzU406A_hWCCXA=.18cc681b-0c4b-4e34-a5b3-569b0dc59bd7@github.com>
Message-ID: <rWM3MMHA1xaK4YTqh9aD2xuAXsZx1xS68U9Je4vTAls=.786b3819-b391-4be0-8e8d-0d0ad076dc1c@github.com>

On Mon, 4 Nov 2024 20:29:23 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright years

I have now searched for `@[0-9]` to find instances of "stdcall-style" symbol names, and fixed those. I have also done a wide sweep of searching for "@" in general over the code base, which (unsurprisingly) generated a sh*tload of hits. I tried to sift through this, using some mental heuristics to skip those that are likely to be irrelevant, and scrutinized some other more carefully, to identify any other code that might be working with name mangling/parsing. I found no such code, outside of what I had already previously located.

At this point, I believe I have resolved all outstanding issues from the reviews, and also finished fixing up the additional removal of the 32-bit Windows calling convention remnants.

>From my PoV, what remains now is for me to repeat the in-depth testing of this PR, and to wait for the JEP to become targeted. 

@shipilev @erikj79 @vnkozlov @kimbarrett I'd appreciate a re-review from you at the current commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455648651
PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2455651750

From ihse at openjdk.org  Mon Nov  4 20:42:59 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 20:42:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  fix: jvm_md.h was included, but not jvm.h...

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/40291b9b..9b10e74c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=28-29

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

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

From sspitsyn at openjdk.org  Mon Nov  4 20:57:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Mon, 4 Nov 2024 20:57:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
Message-ID: <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>

On Mon, 4 Nov 2024 18:18:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
> 
>  - Update comment block in objectMonitor.cpp
>  - Fix issue with unmounted virtual thread when dumping heap
>  - Remove ThawBase::possibly_adjust_frame()

src/hotspot/share/runtime/continuation.cpp line 134:

> 132:   return true;
> 133: }
> 134: #endif // INCLUDE_JVMTI

Could you, please, consider the simplification below?


#if INCLUDE_JVMTI
// return true if started vthread unmount
bool jvmti_unmount_begin(JavaThread* target) {
  assert(!target->is_in_any_VTMS_transition(), "must be");

  // Don't preempt if there is a pending popframe or earlyret operation. This can
  // be installed in start_VTMS_transition() so we need to check it here.
  if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
    JvmtiThreadState* state = target->jvmti_thread_state();
    if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
      return false;
    }
  }
  // Don't preempt in case there is an async exception installed since
  // we would incorrectly throw it during the unmount logic in the carrier.
  if (target->has_async_exception_condition()) {
    return false;
  }
  if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
    JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
  } else {
    target->set_is_in_VTMS_transition(true);
    // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
  }
  return false;
}

static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
  if (target->is_in_VTMS_transition()) {
    // We caught target at the end of a mount transition.
    return false;
  }
  return true;
}
#endif // INCLUDE_JVMTI
...
static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
  assert(java_lang_VirtualThread::is_instance(vthread), "");
  if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
    return false;
  }
  return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
}
...
int Continuation::try_preempt(JavaThread* target, oop continuation) {
  verify_preempt_preconditions(target, continuation);

  if (LockingMode == LM_LEGACY) {
    return freeze_unsupported;
  }
  if (!is_safe_vthread_to_preempt(target, target->vthread())) {
    return freeze_pinned_native;
  }
  JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
  int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
  log_trace(continuations, preempt)("try_preempt: %d", res);
  return res;
}


The following won't be needed:

target->set_pending_jvmti_unmount_event(true);

jvmtiThreadState.cpp:

+  if (thread->pending_jvmti_unmount_event()) {
+    assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted");
+    JvmtiExport::post_vthread_unmount(vthread);
+    thread->set_pending_jvmti_unmount_event(false);
+  }


As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585

From ihse at openjdk.org  Mon Nov  4 21:15:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 21:15:34 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>
Message-ID: <QEyhmjtUis_7E8umUO_S7CpGfLxFMCGcKpkYbqxyR-c=.52160107-9ba4-4884-a6d9-1bc208126e7c@github.com>

On Mon, 4 Nov 2024 19:05:05 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well.

This I fully agree with; it cannot wait for a follow-up PR. I'll look into it as soon as I have gotten back to a working build.

I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455711944

From almatvee at openjdk.org  Mon Nov  4 21:17:30 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 4 Nov 2024 21:17:30 GMT
Subject: RFR: 8343314: Move common properties from jpackage jtreg test
 declarations to TEST.properties file
In-Reply-To: <WlR1qz4C6miTVQz6LotCiEy0oqinc4LxBRbr5wigc0M=.c9a5d80c-3e50-4df8-91fc-06085dbe8d90@github.com>
References: <WlR1qz4C6miTVQz6LotCiEy0oqinc4LxBRbr5wigc0M=.c9a5d80c-3e50-4df8-91fc-06085dbe8d90@github.com>
Message-ID: <eaKugCy6q4Gvp8mJ41EMi9mZ4KhxujkKppodtbCHhNE=.99ca4167-f70f-4ae9-9d9f-a64ecdb3a3c5@github.com>

On Wed, 30 Oct 2024 19:07:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Clean up of jpackage jtreg test declarations:
>  - remove "<span>@</span>modules java.base/jdk.internal.util";
>  - remove `--add-opens` from <span>@</span>run;
>  - replace "<span>@</span>library ../../../../helpers" and "<span>@</span>library ../helpers" with "<span>@</span>library /test/jdk/tools/jpackage/helpers";
>  - remove <span>@</span>library referring to unused libraries;
>  - remove duplicated <span>@</span>build;
>  - add `modules=jdk.jpackage/jdk.jpackage.internal:+open java.base/jdk.internal.util` to jpackage's `TEST.properties` file.
> 
> Most changes were automated with ad-hoc scripts.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21792#pullrequestreview-2414136559

From ihse at openjdk.org  Mon Nov  4 21:27:31 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 21:27:31 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <vxhfWryABYSWDMPG3TTmQBUoi-z5OkhPUF0bQ64blBU=.b74728ed-dae2-4553-9891-0cbc0f04b4a4@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
 <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>
 <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com>
 <zuGp6ZwW6hvpfdwvlHMmHfnsa2hVkVaMOYKMp872ZIA=.9c95a697-5fc3-4104-89bc-3ad637ed72f3@github.com>
 <vxhfWryABYSWDMPG3TTmQBUoi-z5OkhPUF0bQ64blBU=.b74728ed-dae2-4553-9891-0cbc0f04b4a4@github.com>
Message-ID: <lHVW0kOVCGzfanrmrj1WLguu_nzUUcma1kjCihpN2R8=.d3c0b9e8-31d2-474d-b995-272267adadfd@github.com>

On Sun, 3 Nov 2024 05:06:04 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

> There is no `static-jdk/bin/java.debuginfo`. I do see there's a `./support/static-native/launcher/java.debuginfo`.

Ah, I missed that part. So it's just about copying it to the right place? Fine, that is trivial to add. Did you verify that these symbols really worked, though? That is my main concern.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455732445

From ihse at openjdk.org  Mon Nov  4 21:32:32 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 21:32:32 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
Message-ID: <IrLfXDhGpdeC3CUdrf_kUgt0SkoUtGPUi0bM5TRYlY8=.1435dc04-9062-47cf-bf30-7915e4b7c78f@github.com>

On Fri, 1 Nov 2024 16:25:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge branch 'master' into static-jdk-image
>  - Fix bug in filtering out -Wl,--exclude-libs,ALL
>  - Don't hardcode server variant
>  - Setup LDFLAGS_STATIC_JDK
>  - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
>  - Add lookup asserts
>  - Remove superfluous SRC.
>  - Merge branch 'master' into static-jdk-image
>  - Makefile changes needed for static-launcher and static-jdk-image targets
>  - Incorporate changes from leyden/hermetic-java-runtime that allows running a static launcher

Also, the gcc build succeeds as well. I'll definitely have to look into the incremental build part, this was highly annoying.

Anyway, that means we're back in business. I think I ran into this problem when I was working with `LDFLAGS_STATIC_JDK`; I need to to back in the logs to see what I was doing.

Also, there is some additional comments from reviewers (incl Johan Vos) that I need to address.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455738909

From jiangli at openjdk.org  Mon Nov  4 21:32:33 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 4 Nov 2024 21:32:33 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <QEyhmjtUis_7E8umUO_S7CpGfLxFMCGcKpkYbqxyR-c=.52160107-9ba4-4884-a6d9-1bc208126e7c@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>
 <QEyhmjtUis_7E8umUO_S7CpGfLxFMCGcKpkYbqxyR-c=.52160107-9ba4-4884-a6d9-1bc208126e7c@github.com>
Message-ID: <u2fHrEnR89C-zHBHVzzTWT9OxlkbWj-a653OQVhPTt4=.b9bf0775-d5fb-4aa5-b441-d4a8db85b15e@github.com>

On Mon, 4 Nov 2024 21:12:31 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well.

Good.
 
I tested using gcc.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455740530

From ihse at openjdk.org  Mon Nov  4 21:32:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 21:32:33 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <u2fHrEnR89C-zHBHVzzTWT9OxlkbWj-a653OQVhPTt4=.b9bf0775-d5fb-4aa5-b441-d4a8db85b15e@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>
 <QEyhmjtUis_7E8umUO_S7CpGfLxFMCGcKpkYbqxyR-c=.52160107-9ba4-4884-a6d9-1bc208126e7c@github.com>
 <u2fHrEnR89C-zHBHVzzTWT9OxlkbWj-a653OQVhPTt4=.b9bf0775-d5fb-4aa5-b441-d4a8db85b15e@github.com>
Message-ID: <RMacEqw-EG630Un-DYa-lMKkRFNsItFUqzvvRf6dT64=.349aceb7-a266-4fbd-b11f-3420ba56fd81@github.com>

On Mon, 4 Nov 2024 21:29:51 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>>> I notice incremental build with your current PR doesn't update `static-jdk/bin/java` properly. This should be fixed as well.
>> 
>> This I fully agree with; it cannot wait for a follow-up PR. I'll look into it as soon as I have gotten back to a working build.
>> 
>> I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well.
>
>> I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well.
> 
> Good.
>  
> I tested using gcc.

@jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455741013

From ihse at openjdk.org  Mon Nov  4 21:37:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 4 Nov 2024 21:37:12 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v10]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <eszmldpfz0UZiV47vLXcoYZTleKHCH8c9fmHQuzFNp4=.36aabebc-4e0e-40ff-8058-6a512f3c4ec7@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into static-jdk-image
 - Merge branch 'master' into static-jdk-image
 - Fix bug in filtering out -Wl,--exclude-libs,ALL
 - Don't hardcode server variant
 - Setup LDFLAGS_STATIC_JDK
 - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
 - Add lookup asserts
 - Remove superfluous SRC.
 - Merge branch 'master' into static-jdk-image
 - Makefile changes needed for static-launcher and static-jdk-image targets
 - ... and 1 more: https://git.openjdk.org/jdk/compare/825ceb16...f4f6845e

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

Changes: https://git.openjdk.org/jdk/pull/20837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=09
  Stats: 447 lines in 26 files changed: 367 ins; 5 del; 75 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

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

From duke at openjdk.org  Mon Nov  4 22:03:29 2024
From: duke at openjdk.org (ExE Boss)
Date: Mon, 4 Nov 2024 22:03:29 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <XB8L2-EcMcGxNmh2djEvPyCRf71xRJGo83vUMRA_oPA=.d3c6d0d4-bf24-4531-b681-719384298787@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
 <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
 <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>
 <lAEOqppEUsn93yvkT-tyz1ECFU09KbQqmZXwdmbORfA=.34b48ecd-d51d-4bed-b5b5-3c915749152a@github.com>
 <qvFBWdanR_WQuUgcbv0k__lfCUprg5bzSGqth5zBP88=.3d47769b-c25b-4814-af92-4c1c793d581c@github.com>
 <XB8L2-EcMcGxNmh2djEvPyCRf71xRJGo83vUMRA_oPA=.d3c6d0d4-bf24-4531-b681-719384298787@github.com>
Message-ID: <u7vuKgUD2K5j2_aMP7r4q6zR7cUWqJNhnCCUE-qwEBY=.6e5b7e0d-7f61-4528-bca8-33c27b976e43@github.com>

On Mon, 4 Nov 2024 19:08:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> `checkValidStateRaw` synchronizes with `justClose` using handshakes so an opaque or higher load is only needed in `sharedSessionAlreadyClosed`. A `getOpaque` would probably be adequate. But I believe there is no formal restriction preventing the load from being hoisted out of the loop, so I decided to go for the strongest ordering in this exception-throwing case.
>
> Doesn't using `setOpaque` mean that another thread may see the update to `state` before the update to `acquireCount`? i.e. the scope of a memory segment may appear closed, but the segment would still be passable to a downcall?

`acquireCount` is?always?accessed using?`volatile`?semantics by?`SharedSession`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1828442794

From cushon at openjdk.org  Mon Nov  4 22:23:50 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Mon, 4 Nov 2024 22:23:50 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v4]
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <qM415oS2t5vN-3HIkzHd_sQBzqPdDUL3SLeUcOYkzYg=.970db2cc-ce93-4dba-ab32-9ed77b818d6a@github.com>

> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
> 
> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.

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

 - Update another reference to sun.misc.Unsafe
 - Merge remote-tracking branch 'origin/master' into JDK-8332744
 - Migrate another use of sun.misc.Unsafewq
 - Merge remote-tracking branch 'origin/master' into JDK-8332744
 - Merge remote-tracking branch 'origin/master' into JDK-8332744
 - Use jdk.internal.misc.Unsafe instead of sun.misc.Unsafe in microbenchmarks to avoid a sunapi warning
 - [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/19397/files
  - new: https://git.openjdk.org/jdk/pull/19397/files/aa688777..a56bc3a5

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

  Stats: 259097 lines in 2770 files changed: 159963 ins; 73418 del; 25716 mod
  Patch: https://git.openjdk.org/jdk/pull/19397.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19397/head:pull/19397

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

From jiangli at openjdk.org  Mon Nov  4 22:31:30 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Mon, 4 Nov 2024 22:31:30 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v8]
In-Reply-To: <lHVW0kOVCGzfanrmrj1WLguu_nzUUcma1kjCihpN2R8=.d3c0b9e8-31d2-474d-b995-272267adadfd@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <a-3e7WiH3vJefxIDna_2ZpNxzZzN4F9eZeHdXkWl8Ns=.90cb2925-69a2-4997-8289-7199b7340699@github.com>
 <0SV1CZsC4-4qlECRdXAsTtfA4SFMOizXH2pZqYggJtM=.d69355b4-ac64-4a9a-836e-957085f04b09@github.com>
 <-KTe_Kv55w9u0xR8YeEEHDYvYCv3YCUzc9EBac6jL4c=.13b8e842-a9e0-451e-b8c9-6519d9932d57@github.com>
 <zuGp6ZwW6hvpfdwvlHMmHfnsa2hVkVaMOYKMp872ZIA=.9c95a697-5fc3-4104-89bc-3ad637ed72f3@github.com>
 <vxhfWryABYSWDMPG3TTmQBUoi-z5OkhPUF0bQ64blBU=.b74728ed-dae2-4553-9891-0cbc0f04b4a4@github.com>
 <lHVW0kOVCGzfanrmrj1WLguu_nzUUcma1kjCihpN2R8=.d3c0b9e8-31d2-474d-b995-272267adadfd@github.com>
Message-ID: <XV_XLowtVQJ5BuE9VLcEyFyTpstkhqy8ZOdOCpkpjb4=.ae519596-8114-477c-99e9-b1ad4aadc010@github.com>

On Mon, 4 Nov 2024 21:24:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> > There is no `static-jdk/bin/java.debuginfo`. I do see there's a `./support/static-native/launcher/java.debuginfo`.
> 
> Ah, I missed that part. So it's just about copying it to the right place? Fine, that is trivial to add. Did you verify that these symbols really worked, though? That is my main concern.

The `./support/static-native/launcher/java.debuginfo` works. I can use it in `gdb` to step through code.

I haven't specifically looked into how `java.debuginfo` is copied for normal `images/jdk/bin/java`. It's better to handle the  `java.debuginfo` for `images/static-jdk/bin/java` the same. As a related note, with `--with-native-debug-symbols`, I believe there is no external `.debuginfo` file. But as long as the `.debuginfo` file for static build is handle the same as for normal build, it will work automatically.

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

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2455832890

From asmehra at openjdk.org  Mon Nov  4 22:35:37 2024
From: asmehra at openjdk.org (Ashutosh Mehra)
Date: Mon, 4 Nov 2024 22:35:37 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v7]
In-Reply-To: <mkTCxxPfBA3U7C1sNcfEWrmMpZsTWal8EeFftpoi6DU=.e4335abb-bc27-44d3-97bb-268c1332d059@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <mkTCxxPfBA3U7C1sNcfEWrmMpZsTWal8EeFftpoi6DU=.e4335abb-bc27-44d3-97bb-268c1332d059@github.com>
Message-ID: <1wukRI6kmV2-xWutsU-7yRUnYMLAs9jwXIDDlyLj77M=.da0215eb-76bc-4f4c-b3e3-a7b26f642140@github.com>

On Mon, 4 Nov 2024 03:15:25 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 172 commits:
> 
>  - fixed merge
>  - Merge branch 'master' into jep-483-candidate
>  - 8343493: Perform module checks during MetaspaceShared::map_archives()
>  - reverted changes in modules.cpp to make it easy to merge with mainline
>  - Fixed whitespace; fixed minimal build
>  - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity"
>  - fixed comments
>  - @ashu-mehra comment - renamed function to SystemDictionaryShared::should_be_excluded(); added comments and asserts; make sure the class is indeed checked
>  - Backed out 58233cc20fa22abfd711bb59aafb78e20fabc195
>  - @ashu-mehra comment - rename/comment AOTClassLinker::add_new_candidate() and added asserts for thread safety
>  - ... and 162 more: https://git.openjdk.org/jdk/compare/29882bfe...935dcc68

Marked as reviewed by asmehra (Committer).

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

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2414263812

From dl at openjdk.org  Mon Nov  4 22:41:03 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 4 Nov 2024 22:41:03 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v17]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <TS6OyIU9HfttYg9H3Sl8sXHitbQ8kbylVVuU4BMhFSk=.da2732be-0964-4c50-abc5-af902764bcf7@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  More shutdown streamlining

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/15793afa..7b86aac4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=15-16

  Stats: 68 lines in 1 file changed: 21 ins; 24 del; 23 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

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

From iklam at openjdk.org  Mon Nov  4 23:57:48 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 4 Nov 2024 23:57:48 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v8]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  @DanHeidinga comment -- exit VM when runtimeSetup() fails

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/935dcc68..c46ae0b9

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

  Stats: 34 lines in 5 files changed: 20 ins; 9 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

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

From iklam at openjdk.org  Mon Nov  4 23:57:48 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Mon, 4 Nov 2024 23:57:48 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v6]
In-Reply-To: <w_FH1vXE90vHr6fftcrH0StwbxMGWWyffYwro_Qe-Yo=.5f4e2de8-7e4f-4471-a9c4-d033dd0139ad@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <Wa16sMIw3k7Ad2Fxj3OYhaxYzHsA0nZCYuRkmiUmSbg=.b2d64b08-8edb-47f4-9ab7-6e332950536c@github.com>
 <qM3nz9qI10MFZ14TlthOJERSf2LhhYCcIz5LpZvB8P8=.ad19e9dc-369b-40f9-b425-b682ec0202c6@github.com>
 <8IyBT_SVLgsOjXogoorL6m3SmYK8OVzJDpRv-MH4MaA=.7f7f50c3-db38-4418-9381-9f915bb07470@github.com>
 <w_FH1vXE90vHr6fftcrH0StwbxMGWWyffYwro_Qe-Yo=.5f4e2de8-7e4f-4471-a9c4-d033dd0139ad@github.com>
Message-ID: <nUe-RmT5VV3RY9U31jDtzKegeWaFhY8roJ_D2bE3VEg=.1415c83f-5876-498e-a879-72a0ae960cca@github.com>

On Mon, 4 Nov 2024 14:21:09 GMT, Dan Heidinga <heidinga at openjdk.org> wrote:

>> I think this is already done:
>> 
>> `runtimeSetup()` is called inside `InstanceKlass::call_class_initializer()`. When that returns, we will proceed to `InstanceKlass::set_initialization_state_and_notify()` which will perform the memory fencing. 
>> 
>> https://github.com/iklam/jdk/blob/6eebd18fc2820ffb179d431f179fc6af6d1be247/src/hotspot/share/oops/instanceKlass.cpp#L1276-L1300
>
> I think you're right about the memory fencing being covered there but reading that code shows another potential issue - what if the `runtimeSetup()` call throws an exception?
> 
> If I read `InstanceKlass::call_class_initializer()` correctly, an exception from `runtimeSetup()` will lead to marking the class as failing initialization (`initialization_error`) which will be an unexpected outcome as there may be instances of the class in the AOTCache that aren't produced by paths through the `<clinit>` method.
> 
> Classes are able to create an instance in `<clinit>` and escape it to other code and then fail initialization.  The instances are left in an odd state where after the `<clinit>` the instance methods can be called but static fields and static methods can't be accessed.
> 
> `runtimeSetup()` expands on this corner case which I think is OK for current "crawl" stage of our "crawl-walk-run" approach as its analogous to the existing `<clinit>` behaviour.  It may need refining in the future to abort the VM or do something else (?) in the case of failed `runtimeSetup` calls

Thanks for catching this. I added code to exit the JVM when `runtimeSetup()` fails.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1828549749

From fyang at openjdk.org  Tue Nov  5 00:20:53 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 5 Nov 2024 00:20:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>
Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com>

On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>
> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 

> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

I agree with @pchilano in that we are fine with these places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437

From vlivanov at openjdk.org  Tue Nov  5 00:23:34 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 5 Nov 2024 00:23:34 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v8]
In-Reply-To: <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
Message-ID: <ElrA4frQ4YdtXcbkdkkOadEZMEuQz-GuLit9tqFc7vM=.7416712c-e42f-4fc5-90d8-9e6fe3667b8e@github.com>

On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @DanHeidinga comment -- exit VM when runtimeSetup() fails

Looks good.

Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my eye. I find the former spelling more descriptive. Any particular reason to use "aot" unless all lowercase spelling is preferred in some particular context?

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

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2414396530

From fyang at openjdk.org  Tue Nov  5 00:26:54 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 5 Nov 2024 00:26:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com>
Message-ID: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.d62c81bf-a40b-4f06-ae3b-0b8114a92728@github.com>

On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.
>
>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
> 
> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
> 
>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
> 
> I agree with @pchilano in that we are fine with these places.

> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395

From swen at openjdk.org  Tue Nov  5 00:31:32 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 5 Nov 2024 00:31:32 GMT
Subject: Integrated: 8343500: Optimize ArrayClassDescImpl computeDescriptor
In-Reply-To: <17-2o2dXFqtL40ZGfMB0byqtSWJ6YWYPCW6gf3TvR60=.90d252e2-ad7d-411c-ad4b-4ea14021da93@github.com>
References: <17-2o2dXFqtL40ZGfMB0byqtSWJ6YWYPCW6gf3TvR60=.90d252e2-ad7d-411c-ad4b-4ea14021da93@github.com>
Message-ID: <3loojI1fUShVmU7tDW7TalQUVcl_q5_u-BlZah6hwv0=.a6e96531-6870-4e67-8e0f-79526a7f5d1c@github.com>

On Sat, 2 Nov 2024 22:50:29 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> A small improvement to ArrayClassDescImpl#computeDescriptor that avoids intermediate object allocation in the common rank 1 scenario.

This pull request has now been integrated.

Changeset: 67907d5e
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/67907d5e8985ee47ddadb51dae1220404a18dd47
Stats:     5 lines in 1 file changed: 0 ins; 4 del; 1 mod

8343500: Optimize ArrayClassDescImpl computeDescriptor

Reviewed-by: liach

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

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

From cushon at openjdk.org  Tue Nov  5 01:05:31 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 5 Nov 2024 01:05:31 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
 <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>
Message-ID: <tu2S8UiFlVsX6tbU8cbrY-v98l9yJa_7Urp9A4cn0WE=.92d3c239-00e3-4dde-9849-347783ee5239@github.com>

On Mon, 21 Oct 2024 17:56:23 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Migrate another use of sun.misc.Unsafewq
>
> lgtm

@vicente-romero-oracle could you please take another look?

I was preparing to integrate this, and the latest merge includes one new benchmark that requires another update: https://github.com/openjdk/jdk/pull/19397/commits/a56bc3a5d461f2f27ee77e169d7bc6b9e80247cb

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

PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2456009483

From iklam at openjdk.org  Tue Nov  5 01:13:39 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Tue, 5 Nov 2024 01:13:39 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v8]
In-Reply-To: <ElrA4frQ4YdtXcbkdkkOadEZMEuQz-GuLit9tqFc7vM=.7416712c-e42f-4fc5-90d8-9e6fe3667b8e@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
 <ElrA4frQ4YdtXcbkdkkOadEZMEuQz-GuLit9tqFc7vM=.7416712c-e42f-4fc5-90d8-9e6fe3667b8e@github.com>
Message-ID: <uJ8sP7dcSh5vkCh1naSFQgB9bY_cBLY7aqign9YyhAQ=.7e7725d1-ec2c-4dc0-aa31-e9388888dae8@github.com>

On Tue, 5 Nov 2024 00:20:56 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Looks good.
> 
> Stylistic comment: while browsing the code a mix of "AOT" & "aot" caught my eye. I find the former spelling more descriptive. Any particular reason to use "aot" unless all lowercase spelling is preferred in some particular context?

I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention.

In logging, I've been using "aot" as logging seems to favor lowercase.

In comments, I've been using a mix of AOT-xxx and aot-xxx, for no particular reason :-(

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

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2456016366

From pkoppula at openjdk.org  Tue Nov  5 01:36:31 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Tue, 5 Nov 2024 01:36:31 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v7]
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <Z7moJMD1fwTAyI4R3jC5piISn1h_Zni89bxc2ikiGKI=.443dd178-dbd2-423a-bf69-8693b2d8b7bc@github.com>

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/57e5936c..b6aa84f0

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

  Stats: 25 lines in 3 files changed: 2 ins; 10 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/20414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20414/head:pull/20414

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

From pchilanomate at openjdk.org  Tue Nov  5 01:40:15 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:40:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:

 - Add oopDesc::has_klass_gap() check
 - Rename waitTimeout/set_waitTimeout accessors
 - Revert suggestion to ThawBase::new_stack_frame
 - Improve JFR pinned reason in event
 - Use freeze_result consistently

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/11396312..79189f9b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=28-29

  Stats: 439 lines in 21 files changed: 123 ins; 261 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From pchilanomate at openjdk.org  Tue Nov  5 01:43:57 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:43:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v9]
In-Reply-To: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.d62c81bf-a40b-4f06-ae3b-0b8114a92728@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <2HnGc3Do9UW-D2HG9lJXL6_V5XRX56-21c78trR7uaI=.7b59a42e-5001-40f5-ae32-d4d70d23b021@github.com>
 <44I6OK-F7ynO-BUaNKKVdPhi2Ti5jbhCZD1Q2aL2QJM=.8ebc4c64-93e1-4a95-83d9-c43b16e84364@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.91acb434-1e19-40cf-b67a-fd2669b2e42c@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.83f5e1a8-3f56-4138-896c-9d3995344264@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.454d46c6-9b82-4d78-8e59-ad1bcfe741d2@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.afebcd78-dc2c-4265-a9ef-e46873850cfe@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0ad6b253-7ab4-4f0c-891a-4a87e902fc59@github.com>
 <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.d62c81bf-a40b-4f06-ae3b-0b8114a92728@github.com>
Message-ID: <B6yKYX170EzYJUUBWPDAOJmNDGNVRsSXi4OBHWmh4TU=.59f8b023-22b5-4e44-9a49-55c733a3d50a@github.com>

On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
>> 
>> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
>> 
>>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
>> 
>> I agree with @pchilano in that we are fine with these places.
>
>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
> 
> Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499

From pchilanomate at openjdk.org  Tue Nov  5 01:43:58 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:43:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v28]
In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <KGi60RBbL4qJ1PepmgyVdF4gSB9MgwNbbivNv_iaZpU=.cfb90678-ec08-4b5e-bd55-31695eae594b@github.com>
 <uye8ABnuuA0grmtS650RC8ogs4VIkHR2twx-Y1pLeeg=.df0ef53f-d838-41d2-a151-8340c47443c1@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.2ca0fc7a-49b5-47eb-8cc2-56757cafb96e@github.com>
Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.9026ecf7-915c-4366-afff-30ec82ec6f98@github.com>

On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2107:
>> 
>>> 2105: 
>>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>>> 2107:   return vthread->long_field(_timeout_offset);
>> 
>> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??
>
> It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

Renamed accessors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772

From pchilanomate at openjdk.org  Tue Nov  5 01:43:59 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:43:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v16]
In-Reply-To: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.074f9493-482c-4fdb-81d8-d148d25b5c61@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <7NPCzsJLb7Xvk6m91ty092ahF2z_Pl2TibOWAAC3cSo=.9c017e0d-4468-45fb-8d63-feba00b31d48@github.com>
 <wwMKbSzwXA9xeUcULD9VWqq1I20h-IkkJ7-F-3Vr3gI=.ab2ef554-1b4f-4471-8347-7dd2b3f96ed2@github.com>
 <vhW5wcmZhStH378raoko_9Lu4YVFB0XpAmRozbr6_dg=.bbb35e4f-ae5e-44ac-8ce2-0c4726005287@github.com>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.3cbbc4cf-65b3-49bd-8481-ae69c8ba6fe5@github.com>
 <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.074f9493-482c-4fdb-81d8-d148d25b5c61@github.com>
Message-ID: <FJEpZFaGxULmsFhOGyiaLRoIWxL2o9bKBNbo4LWqlrs=.a80e1774-7171-49cb-94fa-650aca3a0c8f@github.com>

On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore.
>
> This code in `StackChunkAllocator::initialize` mimics the clearing code in:
> 
> void MemAllocator::mem_clear(HeapWord* mem) const {
>   assert(mem != nullptr, "cannot initialize null object");
>   const size_t hs = oopDesc::header_size();
>   assert(_word_size >= hs, "unexpected object size");
>   oopDesc::set_klass_gap(mem, 0);
>   Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
> }
> 
> 
> but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:
> 
>   if (oopDesc::has_klass_gap()) {
>     oopDesc::set_klass_gap(mem, 0);
>   }
> 
> 
> So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

Thanks for confirming. I added the check here which I think should cover any merge order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946

From pchilanomate at openjdk.org  Tue Nov  5 01:50:58 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 01:50:58 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <cLURgV2XqvNyCRXLrQ_a95SF5r2JnNvxwl-53HMuvQs=.97fd4ddb-2706-49cb-a3c7-8b73b6ea0307@github.com>

On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

I brought some JFR changes from the loop repo that improve the reported reason when pinning.
@mgronlun @egahlin Could any of you review these JFR changes? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504

From syan at openjdk.org  Tue Nov  5 01:51:37 2024
From: syan at openjdk.org (SendaoYan)
Date: Tue, 5 Nov 2024 01:51:37 GMT
Subject: RFR: 8343490: Update copyright year for JDK-8341692
Message-ID: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com>

Hi all,
The copyright year of some files which has been changed by  [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk.

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

Commit messages:
 - delete tail whitespace of test/hotspot/jtreg/serviceability/dcmd/gc/HeapDumpCompressedTest.java
 - 8343490: Update copyright year for JDK-8341692

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

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

From weijun at openjdk.org  Tue Nov  5 02:56:34 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Tue, 5 Nov 2024 02:56:34 GMT
Subject: Integrated: 8343549: SeededSecureRandomTest needn't be in a package
In-Reply-To: <p-XvBPOkbxJ8BhZvjMGtX29wGcwB7ws1THcgxxiJPqM=.60f7d3a5-84c2-4770-b4cf-4773b5c52469@github.com>
References: <p-XvBPOkbxJ8BhZvjMGtX29wGcwB7ws1THcgxxiJPqM=.60f7d3a5-84c2-4770-b4cf-4773b5c52469@github.com>
Message-ID: <R55ROzXqfJhlzFPouiLLXeq9XfcSa2er3Pg5gnTpgyM=.04964e0c-d95c-40f2-9625-96e033260791@github.com>

On Mon, 4 Nov 2024 16:09:33 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> The test was mistakenly put in a package as the library class it's testing. This is unnecessary since there is no internal field/method it needs access to.

This pull request has now been integrated.

Changeset: cd91a445
Author:    Weijun Wang <weijun at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cd91a44500e83f84e8e9ecc2760552dd18860842
Stats:     4 lines in 1 file changed: 1 ins; 2 del; 1 mod

8343549: SeededSecureRandomTest needn't be in a package

Reviewed-by: mullan

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

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

From tprinzing at openjdk.org  Tue Nov  5 03:24:51 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 5 Nov 2024 03:24:51 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v2]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <hKkxjQV5Zvtk-PxlM0S29AfljzrB-QFwz6YklaEfOu8=.9d24be84-b4a4-4190-8551-3aaa7349678a@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  Added support for connection failure and non-blocking connections.
  
  If an exception is thrown while attempting a connection, the message
  from the exception is stored in the event.  The start time of the
  initial connect call is stored and used when a finishConnect call is
  successful or an exception is thrown.

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/05227c9d..7113bd75

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

  Stats: 91 lines in 4 files changed: 44 ins; 14 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From amitkumar at openjdk.org  Tue Nov  5 04:15:54 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Tue, 5 Nov 2024 04:15:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <jj6iCskb42eGr6L5b_roCs03SXecaECIHTT5TRMmOHg=.2e640db9-2c3e-49b5-84a2-50edf7daf20e@github.com>

On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

Hi @pchilano, 

I see couple of failures on s390x, can you apply this patch: 


diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
index f342240f3ca..d28b4579824 100644
--- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
@@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1
 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp1;
@@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
   // If csg succeeds then CR=EQ, otherwise, register zero is filled
   // with the current owner.
   z_lghi(zero, 0);
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
 
   // Store a non-null value into the box.
   z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box);
@@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 
   BLOCK_COMMENT("fast_path_recursive_lock {");
   // Check if we are already the owner (recursive lock)
-  z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above
+  z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above
   z_brne(done); // not a recursive lock
 
   // Current thread already owns the lock. Just increment recursion count.
@@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp2;
@@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg
   // Handle existing monitor.
   bind(object_has_monitor);
 
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
   z_brne(done);
 
   BLOCK_COMMENT("fast_path_recursive_unlock {");
@@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t
 }
 
 void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) {
-  assert_different_registers(obj, box, tmp1, tmp2);
+  assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch);
 
   // Handle inflated monitor.
   NearLabel inflated;
@@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe
     // If csg succeeds then CR=EQ, otherwise, register zero is filled
     // with the current owner.
     z_lghi(zero, 0);
-    z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-    z_csg(zero, Z_R1_scratch, owner_address);
+    z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+    z_csg(zero, Z_R0_scratch, owner_address);
     z_bre(monitor_locked);
 
     // Check if recursive.
-    z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction
+    z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction
     z_brne(slow_path);
 
     // Recursive


CC: @RealLucy

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800

From pkoppula at openjdk.org  Tue Nov  5 04:54:15 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Tue, 5 Nov 2024 04:54:15 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v8]
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <L7QijvJtbvI3qA8rJaOofhot54j6K6EQCodT_CeEuWE=.b090e4eb-a3be-45c7-9eb7-4caf14a1b49d@github.com>

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  Removed unnecessary code

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/b6aa84f0..24c3f476

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

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

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

From fyang at openjdk.org  Tue Nov  5 06:35:52 2024
From: fyang at openjdk.org (Fei Yang)
Date: Tue, 5 Nov 2024 06:35:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@github.com>
Message-ID: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.271195a1-d071-49b4-971f-e31186c1ec50@github.com>

On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Here's my suggested C2 change:
>> 
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
>> @@ -3692,14 +3692,13 @@ encode %{
>>        __ post_call_nop();
>>      } else {
>>        Label retaddr;
>> +      // Make the anchor frame walkable
>>        __ adr(rscratch2, retaddr);
>> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>>        __ lea(rscratch1, RuntimeAddress(entry));
>> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
>> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>>        __ blr(rscratch1);
>>        __ bind(retaddr);
>>        __ post_call_nop();
>> -      __ add(sp, sp, 2 * wordSize);
>>      }
>>      if (Compile::current()->max_vector_size() > 0) {
>>        __ reinitialize_ptrue();
>
> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
> @RealFYang I made the equivalent change for riscv, could you verify it's okay?

@pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
`hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.

BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
Do you mind adding following small addon change to fix it? Thanks.

diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
index 84a292242c3..ac28f4b3514 100644
--- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
+++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
@@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
   if (LockingMode != LM_LEGACY) {
     // Check preemption for Object.wait()
     Label not_preempted;
-    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ beqz(t0, not_preempted);
+    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
+    __ beqz(t1, not_preempted);
     __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ jr(t0);
+    __ jr(t1);
     __ bind(native_return);
     __ restore_after_resume(true /* is_native */);
     // reload result_handler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495

From egahlin at openjdk.org  Tue Nov  5 08:02:54 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Tue, 5 Nov 2024 08:02:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>

On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

src/hotspot/share/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:

https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html

(Note: The fact that the event is now written in the JVM doesn't determine the category.)

src/hotspot/share/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

The label should be "Blocking Operation" with a capital "O".

Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025

From alanb at openjdk.org  Tue Nov  5 08:22:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 08:22:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
Message-ID: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.7707b1d4-a54f-40e3-902e-685f214a4c01@github.com>

On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> src/hotspot/share/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
> 
> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
> 
> (Note: The fact that the event is now written in the JVM doesn't determine the category.)

Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value that was in the `@Catalog` wasn't carried over.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229

From pminborg at openjdk.org  Tue Nov  5 08:41:34 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 08:41:34 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <u7vuKgUD2K5j2_aMP7r4q6zR7cUWqJNhnCCUE-qwEBY=.6e5b7e0d-7f61-4528-bca8-33c27b976e43@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
 <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
 <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>
 <lAEOqppEUsn93yvkT-tyz1ECFU09KbQqmZXwdmbORfA=.34b48ecd-d51d-4bed-b5b5-3c915749152a@github.com>
 <qvFBWdanR_WQuUgcbv0k__lfCUprg5bzSGqth5zBP88=.3d47769b-c25b-4814-af92-4c1c793d581c@github.com>
 <XB8L2-EcMcGxNmh2djEvPyCRf71xRJGo83vUMRA_oPA=.d3c6d0d4-bf24-4531-b681-719384298787@github.com>
 <u7vuKgUD2K5j2_aMP7r4q6zR7cUWqJNhnCCUE-qwEBY=.6e5b7e0d-7f61-4528-bca8-33c27b976e43@github.com>
Message-ID: <Ul9AT7YJE6uaGx9OyNsU7fyXno0Buk5PcImMW9Slb4Y=.7c0d4c56-f53f-466b-afa3-434513d9e920@github.com>

On Mon, 4 Nov 2024 21:57:39 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Doesn't using `setOpaque` mean that another thread may see the update to `state` before the update to `acquireCount`? i.e. the scope of a memory segment may appear closed, but the segment would still be passable to a downcall?
>
> `acquireCount` is?always?accessed using?`volatile`?semantics by?`SharedSession`.

The close operation is not performance-critical so I think using volatile semantics here would have little or no negative performance impact. From a maintenance and readability point of view (in my subjective opinion) volatile is easier to understand.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1828941391

From fabian at buildbuddy.io  Tue Nov  5 08:52:11 2024
From: fabian at buildbuddy.io (Fabian Meumertzheim)
Date: Tue, 5 Nov 2024 09:52:11 +0100
Subject: Allowing apps to force sun.jnu.encoding = "UTF-8" on Windows
In-Reply-To: <d24fd299-3af2-4b5d-aa59-61be6294bcf2@oracle.com>
References: <mailman.17375.1730309194.124.core-libs-dev@openjdk.org>
 <CAHY-eHva4JsvMfh18PxLp6jA9G254dB4a2EDT5xFr44s6rZHng@mail.gmail.com>
 <440fa736-4282-40ca-a084-aba1e14ab574@oracle.com>
 <CAHY-eHv2H3SeT_UCUVj=z6=RJsnF17FLgYEmu1ZhPvvC-_ETBw@mail.gmail.com>
 <d24fd299-3af2-4b5d-aa59-61be6294bcf2@oracle.com>
Message-ID: <CAHY-eHu9UDN5mJufVf1FySGgc-W=g8MhBoYcuMB4iOr8HRhCAg@mail.gmail.com>

On Mon, Nov 4, 2024 at 8:46?PM Naoto Sato <naoto.sato at oracle.com> wrote:
> I am afraid that the risk that would be involved in configuring
> sun.jnu.encoding exceeds the benefit it would bring, as the encoding is
> so baked in the basis of the Windows Java runtime. Since Microsoft
> itself now recommends users choose UTF-8 as the ANSI code page (over
> changing apps to use -W APIs)[1], I think we would want to wait for that
> glorious day.
>
> Naoto
>
> [1]
> https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page#-a-vs--w-apis

My understanding of that page is that Microsoft recommends
*application developers* to choose UTF-8 as the code page for their
apps by adding a directive to their app manifest. While this works
well for native applications, it doesn't directly apply to Java
applications as the manifest is that of the java.exe launcher binary,
which is necessarily static (and currently doesn't set the
`activeCodePage` directive).

We could choose to rely on users switching to the UTF-8 codepage
system-wide. This is possible as of the 1809 build of Windows 10, but
is not the default, still marked as Beta in the latest version,
requires admin privileges to enable, and can break other applications,
even of other users. This may become the default some day, but it's
unclear whether this will happen in the foreseeable future, especially
since there is a backwards compatible alternative for native
applications.

I understand that incrementally refactoring the Windows Java runtime
until its encoding becomes configurable is too risky. Taking that into
account, what do you think of offering an additional entrypoint for
the Java launcher on Windows, say java-utf8.exe, that is identical to
java.exe except that it specifies
`<activeCodePage>UTF-8</activeCodePage>` in its app manifest? This
would give users the desired opt-in behavior with no changes to the
actual implementation of the Java runtime. (In fact, in my concrete
use case, we are relying on this as a workaround by patching the
manifest in java.exe with a tool [1].)

Fabian

[1] https://github.com/bazelbuild/bazel/pull/24172/files#diff-a0c93cc3220759276f3c447b2fd213159d66612d2eb3b19173df20129625dd6a

From duke at openjdk.org  Tue Nov  5 09:52:30 2024
From: duke at openjdk.org (vulinh64)
Date: Tue, 5 Nov 2024 09:52:30 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v3]
In-Reply-To: <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
Message-ID: <TENfziWlBy_10TuYwbsZnB8t0ukvO9afP7hYGefVn6g=.032e07ff-ec74-42f5-9249-500d34c573d9@github.com>

On Tue, 29 Oct 2024 08:13:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR is simply adding parameter-less `java.io.IO.{println(),readln()}`, with the (hopefully) obvious semantics, plus the corresponding wiring to make those work. This may become part of JEP 495:
>> https://openjdk.org/jeps/495
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test for Console.readln/readLine, ensuring the proper methods are called.

My question (please don't bash me, I am new): Any chance we can set the encoding of console? I tested on Java 23 and the encoding is `windows-1252` so it will not display unicode characters correctly.

![image](https://github.com/user-attachments/assets/cd4cb1a7-8dec-4bb7-ae76-121f3a9369b0)

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

PR Comment: https://git.openjdk.org/jdk/pull/21693#issuecomment-2456709109

From jlahoda at openjdk.org  Tue Nov  5 11:24:29 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 5 Nov 2024 11:24:29 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v3]
In-Reply-To: <TENfziWlBy_10TuYwbsZnB8t0ukvO9afP7hYGefVn6g=.032e07ff-ec74-42f5-9249-500d34c573d9@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
 <TENfziWlBy_10TuYwbsZnB8t0ukvO9afP7hYGefVn6g=.032e07ff-ec74-42f5-9249-500d34c573d9@github.com>
Message-ID: <LiTAbYtJFss17_WBgUfpKC4vn0o3SR6xQO2y11XMGp8=.09906daf-5f67-450d-8cb2-db9c4779ab7a@github.com>

On Tue, 5 Nov 2024 09:48:29 GMT, vulinh64 <duke at openjdk.org> wrote:

> My question (please don't bash me, I am new): Any chance we can set the encoding of console? I tested on Java 23 (Windows) and the encoding is `windows-1252` so it will not display unicode characters correctly.

I believe that after https://github.com/openjdk/jdk/pull/21569, the `Console` encoding used by the JDK can be overwritten with `stdout.encoding`.

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

PR Comment: https://git.openjdk.org/jdk/pull/21693#issuecomment-2456910087

From sspitsyn at openjdk.org  Tue Nov  5 11:38:53 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Tue, 5 Nov 2024 11:38:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>

On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

src/hotspot/share/runtime/objectMonitor.cpp line 1643:

> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);

We post a JVMTI `MonitorWaited` event here for a virtual thread.
A couple of questions on this:
- Q1: Is this posted after the `VirtualThreadMount` extension event posted?
         Unfortunately, it is not easy to make this conclusion.
- Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
          Does it post the `MonitorWaited` event for this virtual thread as well?
          If not, then it is not clear how posting for virtual thread is avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889

From mcimadamore at openjdk.org  Tue Nov  5 12:01:29 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Nov 2024 12:01:29 GMT
Subject: RFR: 8343071: Broken anchors to restricted method page and some
 redundant ids
In-Reply-To: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
References: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
Message-ID: <9qjuiPbFAB7rl_sx_ZPeqpEcJWKThveCrePlfv_2t88=.5a5b56a0-fe9d-436a-aeae-b0c70706a491@github.com>

On Fri, 1 Nov 2024 17:19:00 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this patch that brings the last changes to fix broken anchors in the source code.
> 
> The links updated in this patch can be grouped into 3 sections, they were minor so I grouped them into one PR.
> 
> 1- Move some references from the old `foreign/package-summary.html#restricted` to the new `Restricted Methods` page, these were broken after https://github.com/openjdk/jdk/commit/f4dccfd4cf354f360b823c8cce15bb54ef90e9ca
> 
> 2- Remove a redundant `<a>` tag in `Class.java`, the id not needed as we already created an index.
> 
> 3- Fix some broken anchors in `StructuredTaskScope.java`, the text will be updated in a JEP but we can fix the current text now. 
> 
> Thanks!

Changes in FFM look good

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

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21839#pullrequestreview-2415423043

From liangchenblue at gmail.com  Tue Nov  5 12:15:45 2024
From: liangchenblue at gmail.com (Chen Liang)
Date: Tue, 5 Nov 2024 06:15:45 -0600
Subject: Request for Comments: Adding bulk-read method
 "CharSequence.getChars(int
 srcBegin, int srcEnd, char[] dst, int dstBegin)"
In-Reply-To: <000001db284c$56fd0690$04f713b0$@eu>
References: <000001db2704$04318bf0$0c94a3d0$@eu>
 <000001db284c$56fd0690$04f713b0$@eu>
Message-ID: <CABe8uE1CWCaS5U=+J+x+OATX57CPws2_QHBCa1YSQ3ypMGz=aQ@mail.gmail.com>

Thanks Markus, let's continue the API discussion here.

I indeed believe that allowing to batch-copy to an array is a good idea.
The JDK CharSequence can provide a safe "ranged copy from source into
destination" functionality.  However, users must be aware that there may be
malicious CharSequence implementations that may retain references to the
passed array; users must copy the resulting array again if they store it.

This particular fact is fine for Reader.of, since arbitrary readers should
never be trusted.  However, I think this might affect many other usages of
getChars if users pass in a trusted char array into such a method.

-Chen

On Sun, Oct 27, 2024 at 3:44?AM Markus Karg <markus at headcrashing.eu> wrote:

> >Hi Markus,
>
> >Should we drop the srcBigin/srcEnd parameters, as they can be replaced by
> a subSequence(srcBegin, srcEnd) call?
>
> Chen, I do understand your idea and while originally I had the same in
> mind (it really *is* appealing!), I came up with a draft using the
> *original* String.getChars() signature instead, due to the following
> drawbacks:
>
>    - There might exist (possibly lotsof) CharSequence.getChars(int, int,
>    char[], int) implementations already, as this problem (and the idea
>    how to solve it) is anything but new. At least such implementations are
>    String, StringBuilder and StringBuffer. If we come up with a different
>    signature, then *none* of these already existing performance boosters
>    will get used by Reader.of(CharSequence) automatically - at least
>    until they come up with alias methods. Effectively this leads to (possibly
>    lots) of alias methods. At least it leads to alias methods in String,
>    StringBuilder, StringBuffer and CharBuffer. In contrast, when keeping
>    the signature copied from String.getChars, chances are good that
>    (possibly lots of) implementations will *instantly* be supported by
>    Reader.of(CharSequence) without alias methods. At least, String,
>    StringBuilder and StringBuffer will be.
>    - Since decades people are now very used to StringBuilder.getChars(int,
>    int, char[], int), so (possibly a lot of) people might simply *expect*
>    us to come up with that lengthy signature. These people might be rather
>    confused (if not to say frustrated) when we now force them to write an
>    intermediate subSequence(int, int) for something that was "such
>    simple" before.
>    - Custom implementations of CharSequence.subSequence could come up
>    with the (performance-wise "bad") idea of creating *copies* instead of
>    views. At least it seems like AbstractStringBuilder is doing that, so
>    chances are "good" that custom libs will do that, too. For example, because
>    they need it for safety. Or possibly, because they have a technical reason
>    that *enforces* a copy. That would (possibly massively, depending on
>    the actual class) spoil the idea of performance-boosting this RFC is all
>    about.
>
> -Markus
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241105/68154259/attachment-0001.htm>

From liach at openjdk.org  Tue Nov  5 12:18:37 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Nov 2024 12:18:37 GMT
Subject: Integrated: 8343547: Restore accidentally removed annotations in
 LambdaForm from ClassFile API port
In-Reply-To: <yGA_kbsDxQNHJUnQq25kakeJyeEX89GIIJ6cFcYJ4fo=.fcb5b60b-8bf4-4468-b5d6-3050ddba972a@github.com>
References: <yGA_kbsDxQNHJUnQq25kakeJyeEX89GIIJ6cFcYJ4fo=.fcb5b60b-8bf4-4468-b5d6-3050ddba972a@github.com>
Message-ID: <aebxcpq76OH3x810irLuihkSohePtADdv_049u9Yq-E=.287ae878-9f0d-4ebf-be5c-0771b957fd09@github.com>

On Mon, 4 Nov 2024 15:47:46 GMT, Chen Liang <liach at openjdk.org> wrote:

> These two annotations are found to be lost during the ClassFile API port of LambdaForm generation.  I seem not able to reproduce the master issue in a current build but could reproduce before when the change is first made.  Anyways this restoration is always a right thing, better commit it and further investigate.
> 
> Old Stable on BMH impl class static species field: https://github.com/openjdk/jdk/pull/17108/files#diff-3d6c6bed9cbcb47fe292bdb0c795ab77e56783fdbb144decc6f00857b020c092L612-L615
> 
> Incorrect way to add InjectedProfile annotation: https://github.com/openjdk/jdk/pull/17108/files#diff-3b05b61400e7766115409b3f508d839fb51e450423822252ab2e18543427c764R618

This pull request has now been integrated.

Changeset: 16feeb7a
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/16feeb7a8e9a02fec4846179fcfbdc3a71b07fe5
Stats:     19 lines in 2 files changed: 16 ins; 0 del; 3 mod

8343547: Restore accidentally removed annotations in LambdaForm from ClassFile API port

Reviewed-by: asotona

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

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

From alanb at openjdk.org  Tue Nov  5 12:28:04 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 12:28:04 GMT
Subject: RFR: 8342380: Implement JEP draft: Warn about use of Memory-Access
 Methods in `sun.misc.Unsafe`
Message-ID: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>

Change default value of the command line option --sun-misc-unsafe-memory-access from "allow" to "warn".

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

Commit messages:
 - Update test
 - Merge branch 'master' into JDK-8342380
 - Update usage/man page
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/21762/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21762&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342380
  Stats: 29 lines in 4 files changed: 10 ins; 5 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21762/head:pull/21762

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

From pminborg at openjdk.org  Tue Nov  5 13:33:07 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 13:33:07 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v9]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <FrCPgWAjnqV5W9LKqn5bkd-woY0TPTBr5XU6OSKdK_s=.fe7b3043-07ab-4475-b721-0e08276487a3@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with seven additional commits since the last revision:

 - Update test/jdk/java/foreign/TestLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/Linker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/java/lang/foreign/Linker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/0f4e93ff..e81b34f1

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

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

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

From epeter at openjdk.org  Tue Nov  5 13:41:51 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 5 Nov 2024 13:41:51 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
Message-ID: <S6z0rCk1836kiV4ECjB5vsUJxWmSZrZ-g703V_4oj6A=.41421d10-eb39-4c54-a68a-c3adf9da185c@github.com>

On Fri, 18 Oct 2024 21:56:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - fix build error
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - revert test
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/918f9b3e...457735c9

FYI https://github.com/openjdk/jdk/pull/19970 is now integrated - thanks for the patience :)

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

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2457208051

From asemenyuk at openjdk.org  Tue Nov  5 13:45:35 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Nov 2024 13:45:35 GMT
Subject: Integrated: 8343314: Move common properties from jpackage jtreg test
 declarations to TEST.properties file
In-Reply-To: <WlR1qz4C6miTVQz6LotCiEy0oqinc4LxBRbr5wigc0M=.c9a5d80c-3e50-4df8-91fc-06085dbe8d90@github.com>
References: <WlR1qz4C6miTVQz6LotCiEy0oqinc4LxBRbr5wigc0M=.c9a5d80c-3e50-4df8-91fc-06085dbe8d90@github.com>
Message-ID: <sc0CjsGe9BHc2Bz1HvDzQ2ZghRkrLYcSACmqY4TBwgs=.0067ed64-2b40-46a1-9cc5-e5af417f9f35@github.com>

On Wed, 30 Oct 2024 19:07:54 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Clean up of jpackage jtreg test declarations:
>  - remove "<span>@</span>modules java.base/jdk.internal.util";
>  - remove `--add-opens` from <span>@</span>run;
>  - replace "<span>@</span>library ../../../../helpers" and "<span>@</span>library ../helpers" with "<span>@</span>library /test/jdk/tools/jpackage/helpers";
>  - remove <span>@</span>library referring to unused libraries;
>  - remove duplicated <span>@</span>build;
>  - add `modules=jdk.jpackage/jdk.jpackage.internal:+open java.base/jdk.internal.util` to jpackage's `TEST.properties` file.
> 
> Most changes were automated with ad-hoc scripts.

This pull request has now been integrated.

Changeset: c33a8f52
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c33a8f52b613e5eff02f572eda876cbbfc7c22cf
Stats:     297 lines in 87 files changed: 4 ins; 122 del; 171 mod

8343314: Move common properties from jpackage jtreg test declarations to TEST.properties file

Reviewed-by: almatvee

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

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

From pminborg at openjdk.org  Tue Nov  5 13:51:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 13:51:13 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v10]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <f1jb6WM9zR3vagx2vYnkD5NBHCpsF0AmY1PYFEGyblE=.fda79479-0c7b-4761-aba4-2ff9184bd8e2@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Add checks of exception messages

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/e81b34f1..3f537602

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

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

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

From qamai at openjdk.org  Tue Nov  5 14:07:12 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Nov 2024 14:07:12 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
Message-ID: <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>

> Hi,
> 
> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
> 
> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
> 
> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
> 
>     Benchmark                      Mode  Cnt  Score   Error  Units
>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
> 
> For reference this is the results without this patch:
> 
>     Benchmark                      Mode  Cnt  Score   Error  Units
>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
> 
> Please kindly review, thanks very much.

Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:

 - copyright year
 - address reviews

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21810/files
  - new: https://git.openjdk.org/jdk/pull/21810/files/29047718..ab8aecc1

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

  Stats: 81 lines in 4 files changed: 70 ins; 6 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21810.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21810/head:pull/21810

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

From qamai at openjdk.org  Tue Nov  5 14:07:12 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Nov 2024 14:07:12 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
Message-ID: <Rf_cOt826wUfLN2CUNbIl6BfP_Nc2UFUwqF4hCJ-Lu0=.7b7bfd27-f7c4-4fa9-a190-fb21ffc50d58@github.com>

On Fri, 1 Nov 2024 02:44:15 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   wait for the close operation to complete on acquire failures

@JornVernee Thanks for your reviews, I have addressed them in the last commit.

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

PR Comment: https://git.openjdk.org/jdk/pull/21810#issuecomment-2457262533

From qamai at openjdk.org  Tue Nov  5 14:07:12 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Nov 2024 14:07:12 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v4]
In-Reply-To: <XB8L2-EcMcGxNmh2djEvPyCRf71xRJGo83vUMRA_oPA=.d3c6d0d4-bf24-4531-b681-719384298787@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <AmTWtETdhrDe40C3cvOlagtr3md0DGGeUz1SkhFxEyo=.d8f240f9-eea6-4a8f-958b-0c2c73ea68c0@github.com>
 <OE7AbOPhWZFwEn9_5D09afsq-_dsuL1djSdHSQ8OTAE=.085d23e9-d2da-4e7f-8a36-e92c47406e60@github.com>
 <Mg1g0PjMHuvVMhSOv6SmJHcfjRluQMn7Wqxocf-2rN8=.4e5da988-8cf4-490c-a512-6c67842546a0@github.com>
 <JEFmyjfRI4ZiTQx5J87_rdp9oRazMzLfPWSlBu6_HmY=.66a245a1-eb85-44f0-b4c5-dec34d70d53e@github.com>
 <lAEOqppEUsn93yvkT-tyz1ECFU09KbQqmZXwdmbORfA=.34b48ecd-d51d-4bed-b5b5-3c915749152a@github.com>
 <qvFBWdanR_WQuUgcbv0k__lfCUprg5bzSGqth5zBP88=.3d47769b-c25b-4814-af92-4c1c793d581c@github.com>
 <XB8L2-EcMcGxNmh2djEvPyCRf71xRJGo83vUMRA_oPA=.d3c6d0d4-bf24-4531-b681-719384298787@github.com>
Message-ID: <5HDmOWdMt9DKa4x3oiOJfqQxCrK9EorL83V4iBuP8e0=.7446bb53-7491-4b39-a5d4-9b77377a6fca@github.com>

On Mon, 4 Nov 2024 19:08:49 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> `checkValidStateRaw` synchronizes with `justClose` using handshakes so an opaque or higher load is only needed in `sharedSessionAlreadyClosed`. A `getOpaque` would probably be adequate. But I believe there is no formal restriction preventing the load from being hoisted out of the loop, so I decided to go for the strongest ordering in this exception-throwing case.
>
> Doesn't using `setOpaque` mean that another thread may see the update to `state` before the update to `acquireCount`? i.e. the scope of a memory segment may appear closed, but the segment would still be passable to a downcall?

@JornVernee The acquire property of the `acquireCount` compare exchange prevents the `state` store from floating above it. But following @minborg suggestion I changed it to a volatile store.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1829408406

From pminborg at openjdk.org  Tue Nov  5 14:20:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 14:20:47 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v11]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <gkdN2oq3f_KPTItKYCF_ajywbVinkf4CZfDS-p6S7CQ=.76acf421-65f6-4823-aacb-021e1734af68@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with two additional commits since the last revision:

 - Rephrase doc
 - Improve language

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/3f537602..b92ff23e

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

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

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

From pminborg at openjdk.org  Tue Nov  5 14:20:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 14:20:48 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v8]
In-Reply-To: <iacWt-7SfGTZ5hBQN0Y7WTm9P2yHEXZYr_nVn_6EAHQ=.13a1962f-e3e5-4fe6-b764-a787199d900f@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>
 <g9Uv9uy2Rxwk-ThqQhJbqMKYfgRCuJsPBmfLUSrkONQ=.a21519c6-7733-444a-b29d-b8935f2a90d0@github.com>
 <iacWt-7SfGTZ5hBQN0Y7WTm9P2yHEXZYr_nVn_6EAHQ=.13a1962f-e3e5-4fe6-b764-a787199d900f@github.com>
Message-ID: <XkOgYL4Ik6D3nIj_3Kr_IR1aPULPyQSTG4yi7ce5hdE=.598cf7be-f000-437b-87e3-5d0575d51929@github.com>

On Mon, 4 Nov 2024 12:15:53 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Also, don't we already check the alignment before when calling `checkMemberOffset`? Why is it checked again here?

Good catch.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1829425363

From jvernee at openjdk.org  Tue Nov  5 14:20:48 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Nov 2024 14:20:48 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v10]
In-Reply-To: <f1jb6WM9zR3vagx2vYnkD5NBHCpsF0AmY1PYFEGyblE=.fda79479-0c7b-4761-aba4-2ff9184bd8e2@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <f1jb6WM9zR3vagx2vYnkD5NBHCpsF0AmY1PYFEGyblE=.fda79479-0c7b-4761-aba4-2ff9184bd8e2@github.com>
Message-ID: <igpFdB3yc7EhtpSi8DT0OkGFJPp4YcGmzF_ilu2yPPo=.f7430dbc-5554-41ad-bca5-41e3fd6178ec@github.com>

On Tue, 5 Nov 2024 13:51:13 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add checks of exception messages

test/jdk/java/foreign/TestLinker.java line 188:

> 186:             assertEquals(e.getMessage(),
> 187:                     "The padding layout x2 was preceded by another padding layout x1 in [b1x1x2i4]");
> 188:         }

Doesn't `assertThrows` return the exception instance? (which could be used to check the message as well).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1829429545

From pminborg at openjdk.org  Tue Nov  5 14:23:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 14:23:30 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v8]
In-Reply-To: <XkOgYL4Ik6D3nIj_3Kr_IR1aPULPyQSTG4yi7ce5hdE=.598cf7be-f000-437b-87e3-5d0575d51929@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>
 <g9Uv9uy2Rxwk-ThqQhJbqMKYfgRCuJsPBmfLUSrkONQ=.a21519c6-7733-444a-b29d-b8935f2a90d0@github.com>
 <iacWt-7SfGTZ5hBQN0Y7WTm9P2yHEXZYr_nVn_6EAHQ=.13a1962f-e3e5-4fe6-b764-a787199d900f@github.com>
 <XkOgYL4Ik6D3nIj_3Kr_IR1aPULPyQSTG4yi7ce5hdE=.598cf7be-f000-437b-87e3-5d0575d51929@github.com>
Message-ID: <B6j7BemE--zLEo8kIwU2CroO6yQn7qNzHhaBJv4qdQU=.6c3d61e5-8be8-42bf-9d5a-d32958031d3c@github.com>

On Tue, 5 Nov 2024 14:12:42 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Also, don't we already check the alignment before when calling `checkMemberOffset`? Why is it checked again here?
>
>> Also, don't we already check the alignment before when calling `checkMemberOffset`? Why is it checked again here?
> 
> Good catch.

> What happens here if an element is already aligned, and `padding.byteSize() == element.byteAlignment()`? e.g. `MemoryLayout.structLayout(MemoryLayout.paddingLayout(4), ValueLayout.JAVA_INT)`?

This is an error that existed before this PR. On the main branch:


    @Test
    public void alignedByInitialPadding() {
        Linker linker = Linker.nativeLinker();
        var struct = MemoryLayout.structLayout(
                MemoryLayout.paddingLayout(Integer.BYTES),
                JAVA_INT);
        var fd = FunctionDescriptor.of(struct, struct, struct);
        linker.downcallHandle(fd);
    }


would produce:


test TestLinker.alignedByInitialPadding(): failure
java.lang.IllegalArgumentException: Member layout 'i4', of '[x4i4]' found at unexpected offset: 4 != 0
	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkMemberOffset(AbstractLinker.java:235)
	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayoutRecursive(AbstractLinker.java:195)
	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayout(AbstractLinker.java:176)
	at java.base/java.util.Optional.ifPresent(Optional.java:178)
	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayouts(AbstractLinker.java:167)
	at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle0(AbstractLinker.java:98)
	at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle(AbstractLinker.java:92)
	at TestLinker.alignedByInitialPadding(TestLinker.java:160)
	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1829438324

From pminborg at openjdk.org  Tue Nov  5 14:27:32 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 14:27:32 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v8]
In-Reply-To: <B6j7BemE--zLEo8kIwU2CroO6yQn7qNzHhaBJv4qdQU=.6c3d61e5-8be8-42bf-9d5a-d32958031d3c@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>
 <g9Uv9uy2Rxwk-ThqQhJbqMKYfgRCuJsPBmfLUSrkONQ=.a21519c6-7733-444a-b29d-b8935f2a90d0@github.com>
 <iacWt-7SfGTZ5hBQN0Y7WTm9P2yHEXZYr_nVn_6EAHQ=.13a1962f-e3e5-4fe6-b764-a787199d900f@github.com>
 <XkOgYL4Ik6D3nIj_3Kr_IR1aPULPyQSTG4yi7ce5hdE=.598cf7be-f000-437b-87e3-5d0575d51929@github.com>
 <B6j7BemE--zLEo8kIwU2CroO6yQn7qNzHhaBJv4qdQU=.6c3d61e5-8be8-42bf-9d5a-d32958031d3c@github.com>
Message-ID: <z1CrgGzUdZXru1v4inp_q7f5oYyfhki4VETB-HvJFQ4=.a226ed47-025e-4eda-8c1b-40d1195fdcff@github.com>

On Tue, 5 Nov 2024 14:20:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> Also, don't we already check the alignment before when calling `checkMemberOffset`? Why is it checked again here?
>> 
>> Good catch.
>
>> What happens here if an element is already aligned, and `padding.byteSize() == element.byteAlignment()`? e.g. `MemoryLayout.structLayout(MemoryLayout.paddingLayout(4), ValueLayout.JAVA_INT)`?
> 
> This is an error that existed before this PR. On the main branch:
> 
> 
>     @Test
>     public void alignedByInitialPadding() {
>         Linker linker = Linker.nativeLinker();
>         var struct = MemoryLayout.structLayout(
>                 MemoryLayout.paddingLayout(Integer.BYTES),
>                 JAVA_INT);
>         var fd = FunctionDescriptor.of(struct, struct, struct);
>         linker.downcallHandle(fd);
>     }
> 
> 
> would produce:
> 
> 
> test TestLinker.alignedByInitialPadding(): failure
> java.lang.IllegalArgumentException: Member layout 'i4', of '[x4i4]' found at unexpected offset: 4 != 0
> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkMemberOffset(AbstractLinker.java:235)
> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayoutRecursive(AbstractLinker.java:195)
> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayout(AbstractLinker.java:176)
> 	at java.base/java.util.Optional.ifPresent(Optional.java:178)
> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayouts(AbstractLinker.java:167)
> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle0(AbstractLinker.java:98)
> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle(AbstractLinker.java:92)
> 	at TestLinker.alignedByInitialPadding(TestLinker.java:160)
> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)

I've raised a separate issue for this: https://bugs.openjdk.org/browse/JDK-8343620

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1829445374

From pminborg at openjdk.org  Tue Nov  5 14:27:34 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 14:27:34 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v10]
In-Reply-To: <igpFdB3yc7EhtpSi8DT0OkGFJPp4YcGmzF_ilu2yPPo=.f7430dbc-5554-41ad-bca5-41e3fd6178ec@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <f1jb6WM9zR3vagx2vYnkD5NBHCpsF0AmY1PYFEGyblE=.fda79479-0c7b-4761-aba4-2ff9184bd8e2@github.com>
 <igpFdB3yc7EhtpSi8DT0OkGFJPp4YcGmzF_ilu2yPPo=.f7430dbc-5554-41ad-bca5-41e3fd6178ec@github.com>
Message-ID: <9zewqMdAQJ6VUhqAeHRK8Sx6gpUIB78Cb92XIEkw-38=.58bf7f56-0aac-488e-a2a4-81f1f89a93f7@github.com>

On Tue, 5 Nov 2024 14:15:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Add checks of exception messages
>
> test/jdk/java/foreign/TestLinker.java line 188:
> 
>> 186:             assertEquals(e.getMessage(),
>> 187:                     "The padding layout x2 was preceded by another padding layout x1 in [b1x1x2i4]");
>> 188:         }
> 
> Doesn't `assertThrows` return the exception instance? (which could be used to check the message as well).

Unfortunately not in testng. In JUnit 5 it does.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1829447400

From pchilanomate at openjdk.org  Tue Nov  5 14:34:21 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:34:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v31]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <jjaAbty4zUUXNkpiQA69cO_Lqw5sPLTvlGJVrmSgsjQ=.3c196de8-1e8e-4914-983b-02e428449d3c@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:

 - Fixes to JFR metadata.xml
 - Fix return miss prediction in generate_native_entry for riscv
 - Fix s390x failures

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/79189f9b..124efa0a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=29-30

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

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

From pchilanomate at openjdk.org  Tue Nov  5 14:34:22 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:34:22 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v12]
In-Reply-To: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.271195a1-d071-49b4-971f-e31186c1ec50@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <5Jizat_qEASY4lR57VpdmTCwqWd9p01idKiv5_z1hTs=.e63147e4-753b-4fef-94a8-3c93bf9c1d8a@github.com>
 <ZXDoPp-VIU-Rdh8TeOrZWhwbiLDEZB4HyK4WpDB6T9k=.53bf7d9a-5ec0-4e1c-9b3f-10b56664c7f7@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.03695c47-8f5a-4649-82b4-8cdf14a821ab@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.841fc155-1881-449a-ace8-7c2cf069150b@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.0d087962-e0f5-4dd0-a311-a22ea3832986@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.7b95bed2-c9c3-4555-9409-7c8f9e201f2e@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.c7150103-76e8-4c6f-8fa2-5a80f83c6cc4@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.33c64b19-e51f-4330-9701-2e3b6ff3cbb3@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.a247bac3-395e-45f3-acb4-c4070629cb81@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrty
 SG-ah6IA=.199756d3-287f-427e-8514-62a62d7eb749@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.b27c936d-22f5-479e-bb59-b0d142fd7b3b@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.55d1a37c-c2eb-419f-a1c0-5039abce48fc@github.com>
 <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.271195a1-d071-49b4-971f-e31186c1ec50@github.com>
Message-ID: <Z0J2vBm4Z7jT_aibhLEjVlN3tMtVt4kPuxrXg28hRmY=.0550810f-3fc6-4221-8da6-128a84012f5f@github.com>

On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
>> @RealFYang I made the equivalent change for riscv, could you verify it's okay?
>
> @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
> `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.
> 
> BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
> Do you mind adding following small addon change to fix it? Thanks.
> 
> diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> index 84a292242c3..ac28f4b3514 100644
> --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
>    if (LockingMode != LM_LEGACY) {
>      // Check preemption for Object.wait()
>      Label not_preempted;
> -    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ beqz(t0, not_preempted);
> +    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> +    __ beqz(t1, not_preempted);
>      __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ jr(t0);
> +    __ jr(t1);
>      __ bind(native_return);
>      __ restore_after_resume(true /* is_native */);
>      // reload result_handler

Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335

From pchilanomate at openjdk.org  Tue Nov  5 14:37:56 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:37:56 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
Message-ID: <O8JULSt20GzECs148szBdunnT7m3Gq1N3MraPGVogm4=.2639d95d-b377-42c9-a914-deb892072207@github.com>

On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> src/hotspot/share/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> The label should be "Blocking Operation" with a capital "O".
> 
> Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128

From pchilanomate at openjdk.org  Tue Nov  5 14:37:54 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:37:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <cLURgV2XqvNyCRXLrQ_a95SF5r2JnNvxwl-53HMuvQs=.97fd4ddb-2706-49cb-a3c7-8b73b6ea0307@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <cLURgV2XqvNyCRXLrQ_a95SF5r2JnNvxwl-53HMuvQs=.97fd4ddb-2706-49cb-a3c7-8b73b6ea0307@github.com>
Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.b9ae55cd-0172-40f4-bb51-cb72eadac61d@github.com>

On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> I brought some JFR changes from the loom repo that improve the reported reason when pinning.
> @mgronlun @egahlin Could any of you review these JFR changes? Thanks.

> Hi @pchilano,
> 
> I see couple of failures on s390x, can you apply this patch:
> 
Thanks @offamitkumar. Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726

From aboldtch at openjdk.org  Tue Nov  5 14:37:57 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 5 Nov 2024 14:37:57 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
Message-ID: <tEsdXiiwSouYPshYr9vLW4gSORoKYUCnaH2_vB-eSEg=.e0576133-5fc4-4a6a-bd37-932a20d8124b@github.com>

On Tue, 5 Nov 2024 01:40:15 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
> 
>  - Add oopDesc::has_klass_gap() check
>  - Rename waitTimeout/set_waitTimeout accessors
>  - Revert suggestion to ThawBase::new_stack_frame
>  - Improve JFR pinned reason in event
>  - Use freeze_result consistently

src/hotspot/share/runtime/objectMonitor.inline.hpp line 50:

> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");

Suggestion:

  assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829464866

From jvernee at openjdk.org  Tue Nov  5 14:46:35 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Nov 2024 14:46:35 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
Message-ID: <fLrCs7GTb11_7KyPfbfwh5gMv6tgEa_jZ0OJ0EiztoA=.2bc18d6c-c68d-4fcd-b48a-b08f6573a57e@github.com>

On Tue, 5 Nov 2024 14:07:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year
>  - address reviews

test/jdk/java/foreign/TestMemorySession.java line 374:

> 372:                     Thread.onSpinWait();
> 373:                     k = lock.get();
> 374:                 }

I think the right primitive here is a `CyclicBarrier` with 2 parties. Each thread will then wait for the other before continuing to the next iteration.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1829480458

From pchilanomate at openjdk.org  Tue Nov  5 14:37:55 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 14:37:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.7707b1d4-a54f-40e3-902e-685f214a4c01@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.18897a54-c7ef-4907-8a77-32254be0c90f@github.com>
 <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.7707b1d4-a54f-40e3-902e-685f214a4c01@github.com>
Message-ID: <FST2J8IQ3-HRqwpZqe44YLVavuGNcakXyrIKmnieBU4=.ea5fd5c7-1b2f-4265-9ff6-9165a4327d93@github.com>

On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 160:
>> 
>>> 158: 
>>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
>> 
>> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
>> 
>> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
>> 
>> (Note: The fact that the event is now written in the JVM doesn't determine the category.)
>
> Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765

From qamai at openjdk.org  Tue Nov  5 14:51:34 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Nov 2024 14:51:34 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <fLrCs7GTb11_7KyPfbfwh5gMv6tgEa_jZ0OJ0EiztoA=.2bc18d6c-c68d-4fcd-b48a-b08f6573a57e@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
 <fLrCs7GTb11_7KyPfbfwh5gMv6tgEa_jZ0OJ0EiztoA=.2bc18d6c-c68d-4fcd-b48a-b08f6573a57e@github.com>
Message-ID: <l2ekEr2hNdOsYZUzPggrN4iu-cnJVaav43fM2SGt514=.16e28b49-5edd-415d-9b70-b5bbf002bd67@github.com>

On Tue, 5 Nov 2024 14:43:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyright year
>>  - address reviews
>
> test/jdk/java/foreign/TestMemorySession.java line 374:
> 
>> 372:                     Thread.onSpinWait();
>> 373:                     k = lock.get();
>> 374:                 }
> 
> I think the right primitive here is a `CyclicBarrier` with 2 parties. Each thread will then wait for the other before continuing to the next iteration.

I'm afraid that it would be too expensive compared to a spinlock, and the scheduler might not wake up the threads soon enough to make a meaningful race, greatly reducing the effectiveness of the test.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1829490880

From ihse at openjdk.org  Tue Nov  5 14:51:47 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 5 Nov 2024 14:51:47 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
Message-ID: <ZJZkX6Asec26xKuYhDfNk2SYI9h_BivdZmiqOMMpzi4=.4abcb053-fc1c-4c01-aeb0-870c093a9d7c@github.com>

On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: jvm_md.h was included, but not jvm.h...

This has now passed internal CI testing tier1-5 (except for one test that also fails in mainline).

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2457376495

From pminborg at openjdk.org  Tue Nov  5 14:56:46 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 14:56:46 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v12]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <F9ecmfM0HwkJniiQJv8gjH6_m2vZCLFcx_kQtA7PIQo=.03368236-8f42-4d5a-9436-d021ecf30926@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant check

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/b92ff23e..0c134821

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=10-11

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

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

From jvernee at openjdk.org  Tue Nov  5 15:05:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Nov 2024 15:05:32 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v10]
In-Reply-To: <9zewqMdAQJ6VUhqAeHRK8Sx6gpUIB78Cb92XIEkw-38=.58bf7f56-0aac-488e-a2a4-81f1f89a93f7@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <f1jb6WM9zR3vagx2vYnkD5NBHCpsF0AmY1PYFEGyblE=.fda79479-0c7b-4761-aba4-2ff9184bd8e2@github.com>
 <igpFdB3yc7EhtpSi8DT0OkGFJPp4YcGmzF_ilu2yPPo=.f7430dbc-5554-41ad-bca5-41e3fd6178ec@github.com>
 <9zewqMdAQJ6VUhqAeHRK8Sx6gpUIB78Cb92XIEkw-38=.58bf7f56-0aac-488e-a2a4-81f1f89a93f7@github.com>
Message-ID: <--0YONTvxYAS3TS0iJAbNZAfLWh1NerqGnZVdbu2ESA=.71db8e43-5425-4c73-b181-87810708ccb3@github.com>

On Tue, 5 Nov 2024 14:25:21 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> test/jdk/java/foreign/TestLinker.java line 188:
>> 
>>> 186:             assertEquals(e.getMessage(),
>>> 187:                     "The padding layout x2 was preceded by another padding layout x1 in [b1x1x2i4]");
>>> 188:         }
>> 
>> Doesn't `assertThrows` return the exception instance? (which could be used to check the message as well).
>
> Unfortunately not in testng. In JUnit 5 it does.

Testng should have this as well, since 6.9.5: https://www.javadoc.io/doc/org.testng/testng/latest/org/testng/Assert.html#expectThrows(java.lang.Class,org.testng.Assert.ThrowingRunnable) jtreg current bundles testng 7.3.0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1829514720

From swen at openjdk.org  Tue Nov  5 15:08:45 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 5 Nov 2024 15:08:45 GMT
Subject: RFR: 8333893: Optimization for StringBuilder append boolean & null
 [v20]
In-Reply-To: <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
 <v9I99BFnyIcHMujqyqh_RZ9QzWKo3dJny3THTGZGG4g=.163a3876-89e7-46a6-86ad-6fa0e6b3dfca@github.com>
Message-ID: <Mn8QU9bXy2kTik2ahflS-wCkjunEYim5UJYqOC8iGgc=.daffe29e-1664-4627-9390-ae2cbae2056d@github.com>

On Fri, 18 Oct 2024 21:56:53 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
>> 
>> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 26 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - fix build error
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'origin/optim_str_builder_append_202406' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - revert test
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - Merge remote-tracking branch 'upstream/master' into optim_str_builder_append_202406
>  - ... and 16 more: https://git.openjdk.org/jdk/compare/88a99fce...457735c9

It has been tested that mergeStore can work after the master branch is merged

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

PR Comment: https://git.openjdk.org/jdk/pull/19626#issuecomment-2457414686

From swen at openjdk.org  Tue Nov  5 15:08:45 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 5 Nov 2024 15:08:45 GMT
Subject: Integrated: 8333893: Optimization for StringBuilder append boolean &
 null
In-Reply-To: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
References: <fgizzENcfGu73DOoZluVhh8BvpVucy_BJphgFI6DwSA=.6771ec64-35e8-4865-9dc9-641520607ffc@github.com>
Message-ID: <hXDZiDjY04Dx6NcEx-EjVyqQEckpkl2ZOFwMhGG7KoY=.2ce81938-d1ed-48f8-9af5-302f8079b527@github.com>

On Mon, 10 Jun 2024 12:12:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> After PR https://github.com/openjdk/jdk/pull/16245, C2 optimizes stores into primitive arrays by combining values ??into larger stores.
> 
> This PR rewrites the code of appendNull and append(boolean) methods so that these two methods can be optimized by C2.

This pull request has now been integrated.

Changeset: 5890d943
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5890d9438bbde88b89070052926a2eafe13d7b42
Stats:     133 lines in 5 files changed: 79 ins; 18 del; 36 mod

8333893: Optimization for StringBuilder append boolean & null

Reviewed-by: liach

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

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

From vromero at openjdk.org  Tue Nov  5 15:14:34 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Nov 2024 15:14:34 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v4]
In-Reply-To: <qM415oS2t5vN-3HIkzHd_sQBzqPdDUL3SLeUcOYkzYg=.970db2cc-ce93-4dba-ab32-9ed77b818d6a@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <qM415oS2t5vN-3HIkzHd_sQBzqPdDUL3SLeUcOYkzYg=.970db2cc-ce93-4dba-ab32-9ed77b818d6a@github.com>
Message-ID: <aAtkQqPQIlBWL8UpKK7fVCR9vrjd1B5b7puY6u1L8mU=.0246a81e-9a18-41e1-80be-95f6ad925147@github.com>

On Mon, 4 Nov 2024 22:23:50 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
>> 
>> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.
>
> Liam Miller-Cushon has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:
> 
>  - Update another reference to sun.misc.Unsafe
>  - Merge remote-tracking branch 'origin/master' into JDK-8332744
>  - Migrate another use of sun.misc.Unsafewq
>  - Merge remote-tracking branch 'origin/master' into JDK-8332744
>  - Merge remote-tracking branch 'origin/master' into JDK-8332744
>  - Use jdk.internal.misc.Unsafe instead of sun.misc.Unsafe in microbenchmarks to avoid a sunapi warning
>  - [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version

looks good

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

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19397#pullrequestreview-2415924757

From vromero at openjdk.org  Tue Nov  5 15:14:35 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Nov 2024 15:14:35 GMT
Subject: RFR: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version [v3]
In-Reply-To: <tu2S8UiFlVsX6tbU8cbrY-v98l9yJa_7Urp9A4cn0WE=.92d3c239-00e3-4dde-9849-347783ee5239@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
 <VmfcEUxtRp799UOO_tzqXRPJI7pieCFsuZnKz2efoMc=.810434ec-e34c-46fa-b4c9-f7aca329b622@github.com>
 <NJ1kA2s5gYMRDafFlhNCi2zBhn5tRoguIvpEDkGlhxQ=.b5f223ca-78a1-47e6-be66-702989164680@github.com>
 <tu2S8UiFlVsX6tbU8cbrY-v98l9yJa_7Urp9A4cn0WE=.92d3c239-00e3-4dde-9849-347783ee5239@github.com>
Message-ID: <98ego0ITZcPdFJrPOtSXGeRVdYSheBuMre9SiCYRFpg=.784d6375-752b-4c35-b17f-f41daa365a09@github.com>

On Tue, 5 Nov 2024 01:03:14 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> lgtm
>
> @vicente-romero-oracle could you please take another look?
> 
> I was preparing to integrate this, and the latest merge includes one new benchmark that requires another update: https://github.com/openjdk/jdk/pull/19397/commits/a56bc3a5d461f2f27ee77e169d7bc6b9e80247cb

@cushon done, thanks

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

PR Comment: https://git.openjdk.org/jdk/pull/19397#issuecomment-2457434466

From jvernee at openjdk.org  Tue Nov  5 15:16:33 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Nov 2024 15:16:33 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
Message-ID: <kmCv1PKT_ez-ovGhDVUeeQQkeH4tMj9PpQ9ttFfcGas=.9087563e-e28b-4684-8541-59822970efa3@github.com>

On Tue, 5 Nov 2024 14:07:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year
>  - address reviews

Marked as reviewed by jvernee (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21810#pullrequestreview-2415931242

From jvernee at openjdk.org  Tue Nov  5 15:16:34 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Nov 2024 15:16:34 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <l2ekEr2hNdOsYZUzPggrN4iu-cnJVaav43fM2SGt514=.16e28b49-5edd-415d-9b70-b5bbf002bd67@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
 <fLrCs7GTb11_7KyPfbfwh5gMv6tgEa_jZ0OJ0EiztoA=.2bc18d6c-c68d-4fcd-b48a-b08f6573a57e@github.com>
 <l2ekEr2hNdOsYZUzPggrN4iu-cnJVaav43fM2SGt514=.16e28b49-5edd-415d-9b70-b5bbf002bd67@github.com>
Message-ID: <VpFTPfBvbefPBY31iZ3-XGpPUVgcF_GSpZUvumvbkaI=.4f661ae4-3ce8-4e02-aef5-5116080c35d2@github.com>

On Tue, 5 Nov 2024 14:49:09 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> test/jdk/java/foreign/TestMemorySession.java line 374:
>> 
>>> 372:                     Thread.onSpinWait();
>>> 373:                     k = lock.get();
>>> 374:                 }
>> 
>> I think the right primitive here is a `CyclicBarrier` with 2 parties. Each thread will then wait for the other before continuing to the next iteration.
>
> I'm afraid that it would be too expensive compared to a spinlock, and the scheduler might not wake up the threads soon enough to make a meaningful race, greatly reducing the effectiveness of the test.

Okay, fair enough.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1829533706

From pminborg at openjdk.org  Tue Nov  5 15:33:29 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 5 Nov 2024 15:33:29 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
Message-ID: <Umv8EUsRk_LswQHC0lQjer0VI0Ye0_kgaYzBD-qm9aI=.67f83133-8701-441b-b2b0-1bfe6c6362d7@github.com>

On Tue, 5 Nov 2024 14:07:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year
>  - address reviews

In `SharedSession`, would it not be necessary to override `isClosable()` so it would be using `volatile` semantics to read the `state` field rather than relying on plain reads?

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

PR Comment: https://git.openjdk.org/jdk/pull/21810#issuecomment-2457478675

From mcimadamore at openjdk.org  Tue Nov  5 15:33:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Tue, 5 Nov 2024 15:33:30 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <VpFTPfBvbefPBY31iZ3-XGpPUVgcF_GSpZUvumvbkaI=.4f661ae4-3ce8-4e02-aef5-5116080c35d2@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
 <fLrCs7GTb11_7KyPfbfwh5gMv6tgEa_jZ0OJ0EiztoA=.2bc18d6c-c68d-4fcd-b48a-b08f6573a57e@github.com>
 <l2ekEr2hNdOsYZUzPggrN4iu-cnJVaav43fM2SGt514=.16e28b49-5edd-415d-9b70-b5bbf002bd67@github.com>
 <VpFTPfBvbefPBY31iZ3-XGpPUVgcF_GSpZUvumvbkaI=.4f661ae4-3ce8-4e02-aef5-5116080c35d2@github.com>
Message-ID: <19bAQX1sW4B7UE9oRTKKYvOuWki94CaIua-xArd73f8=.e6ba39df-72d3-4527-96ce-417c0fb11da8@github.com>

On Tue, 5 Nov 2024 15:13:29 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> I'm afraid that it would be too expensive compared to a spinlock, and the scheduler might not wake up the threads soon enough to make a meaningful race, greatly reducing the effectiveness of the test.
>
> Okay, fair enough.

Using two blocking queues might also be possible:
* at the start of each iteration a thread does a `get` on its own queue
* at the end of each iteration, a thread does a put on the other thread's queue
* we call put on the first thread's queue, to get things moving

This should create the desired "ping-pong" effect.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1829563292

From qamai at openjdk.org  Tue Nov  5 15:36:33 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Nov 2024 15:36:33 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <Umv8EUsRk_LswQHC0lQjer0VI0Ye0_kgaYzBD-qm9aI=.67f83133-8701-441b-b2b0-1bfe6c6362d7@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
 <Umv8EUsRk_LswQHC0lQjer0VI0Ye0_kgaYzBD-qm9aI=.67f83133-8701-441b-b2b0-1bfe6c6362d7@github.com>
Message-ID: <B136ZwjEO3M7jgPyfNPn9vkJ5E7uHRPp8FOWatb7OgY=.405fd015-184a-44c6-8e17-10e12b12a0e4@github.com>

On Tue, 5 Nov 2024 15:29:22 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyright year
>>  - address reviews
>
> In `SharedSession`, would it not be necessary to override `isClosable()` so it would be using `volatile` semantics to read the `state` field rather than relying on plain reads?

@minborg No because a `SharedSession` can only transit from `OPEN` to `CLOSED`, both states will return `true` on `isCloseable()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/21810#issuecomment-2457491919

From swen at openjdk.org  Tue Nov  5 15:47:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 5 Nov 2024 15:47:00 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v2]
In-Reply-To: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
Message-ID: <DPd3cEy9NeRFgO3diWAiIWU6GQV7tMrGElJjwVsA8jI=.2fc1e645-c6ee-4199-8ed7-6f44a063990b@github.com>

> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
> 
> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
> 3. Eliminate duplicate code in BigDecimal

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

 - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410
 - fix Helper
 - fix Helper
 - fix Helper
 - unsafe putByte
 - remove digitPair
 - fix import
 - remove JLA
 - remove unused code
 - add comments
 - ... and 1 more: https://git.openjdk.org/jdk/compare/b209cf90...73b32004

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21593/files
  - new: https://git.openjdk.org/jdk/pull/21593/files/65dbe676..73b32004

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

  Stats: 215050 lines in 1978 files changed: 123180 ins; 69459 del; 22411 mod
  Patch: https://git.openjdk.org/jdk/pull/21593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21593/head:pull/21593

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

From qamai at openjdk.org  Tue Nov  5 15:54:33 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Nov 2024 15:54:33 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <19bAQX1sW4B7UE9oRTKKYvOuWki94CaIua-xArd73f8=.e6ba39df-72d3-4527-96ce-417c0fb11da8@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
 <fLrCs7GTb11_7KyPfbfwh5gMv6tgEa_jZ0OJ0EiztoA=.2bc18d6c-c68d-4fcd-b48a-b08f6573a57e@github.com>
 <l2ekEr2hNdOsYZUzPggrN4iu-cnJVaav43fM2SGt514=.16e28b49-5edd-415d-9b70-b5bbf002bd67@github.com>
 <VpFTPfBvbefPBY31iZ3-XGpPUVgcF_GSpZUvumvbkaI=.4f661ae4-3ce8-4e02-aef5-5116080c35d2@github.com>
 <19bAQX1sW4B7UE9oRTKKYvOuWki94CaIua-xArd73f8=.e6ba39df-72d3-4527-96ce-417c0fb11da8@github.com>
Message-ID: <R4xF1v_FBcBGIesRuThq9i20rb48z5e2jDnaoT4IgT0=.6c99615c-d898-4b0f-8bc1-5b49b6abb4dc@github.com>

On Tue, 5 Nov 2024 15:31:11 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Okay, fair enough.
>
> Using two blocking queues might also be possible:
> * at the start of each iteration a thread does a `get` on its own queue
> * at the end of each iteration, a thread does a put on the other thread's queue
> * we call put on the first thread's queue, to get things moving
> 
> This should create the desired "ping-pong" effect.

There are many ways to achieve this lock-step behaviour. In this case, the operation is extremely fast and there are only 2 threads waiting for each other so I believe a spinlock is the most appropriate. The major benefit of spinning is that we can be more confident that the threads will start each step at the approximately same time, increasing the chance to have a meaningful race.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21810#discussion_r1829600074

From coffeys at openjdk.org  Tue Nov  5 16:11:36 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 5 Nov 2024 16:11:36 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v8]
In-Reply-To: <L7QijvJtbvI3qA8rJaOofhot54j6K6EQCodT_CeEuWE=.b090e4eb-a3be-45c7-9eb7-4caf14a1b49d@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <L7QijvJtbvI3qA8rJaOofhot54j6K6EQCodT_CeEuWE=.b090e4eb-a3be-45c7-9eb7-4caf14a1b49d@github.com>
Message-ID: <21kjfLqGd2d6rMrsjpJaDUxq1BwcerfgU30NjQDlS6s=.137f5c54-324f-4730-9484-781f91114202@github.com>

On Tue, 5 Nov 2024 04:54:15 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed unnecessary code

src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java line 700:

> 698:             byte[] encoded = null;
> 699:             int trustedKeyCount = 0, privateKeyCount = 0, secretKeyCount = 0;
> 700:             String storeName = null;

let's initialize this to an empty string ("") -- otherwise you run the risk of printing "null" in the debug output later.

src/java.base/share/classes/com/sun/crypto/provider/JceKeyStore.java line 709:

> 707:                                 .getPath(stream);
> 708:                 if (keystorePath != null) {
> 709:                     storeName = Paths.get(keystorePath).getFileName()

`Path.of ` might be better

src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 286:

> 284:                     .getPath(ks);
> 285:             if (keystorePath != null) {
> 286:                 SSLLogger.fine(provider.getName() + ": using \"" + Paths.get(

`Path.of ` might be better

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1962:

> 1960:         macAlgorithm = null;
> 1961:         macIterationCount = -1;
> 1962:         String storeName = null;

same here - you'll need to use "" to avoid printing null for non-FIS based keystores

src/java.base/share/classes/sun/security/provider/JavaKeyStore.java line 663:

> 661:             byte[] encoded;
> 662:             int trustedKeyCount = 0, privateKeyCount = 0;
> 663:             String storeName = null;

here also

src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java line 293:

> 291:                         .getPath(stream);
> 292:                 String storeName = (keystorePath != null)
> 293:                         ? Paths.get(keystorePath).getFileName().toString()

suggestion `Path.of`

src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java line 294:

> 292:                 String storeName = (keystorePath != null)
> 293:                         ? Paths.get(keystorePath).getFileName().toString()
> 294:                         : null;

avoid use of null

test/jdk/java/security/KeyStore/LogKeyStorePathVerifier.java line 67:

> 65:              BufferedInputStream bis = new BufferedInputStream(
> 66:              new FileInputStream(bisKeyStoreName));
> 67:              BufferedInputStream bbis = new BufferedInputStream(bis)) {

you should create bbis from a unique file name - otherwise, you've no way of distinguishing the output in the OutputAnalyzer tests later.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829577618
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829584187
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829584597
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829612196
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829612937
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829616007
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829618551
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1829625052

From jvernee at openjdk.org  Tue Nov  5 16:45:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 5 Nov 2024 16:45:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v8]
In-Reply-To: <z1CrgGzUdZXru1v4inp_q7f5oYyfhki4VETB-HvJFQ4=.a226ed47-025e-4eda-8c1b-40d1195fdcff@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <G_VbryqZjOYQvBT8ucmfGqE7Bn_74Ei_zdo8xZQJXRQ=.728b5538-e547-41ae-a180-726e082acccc@github.com>
 <g9Uv9uy2Rxwk-ThqQhJbqMKYfgRCuJsPBmfLUSrkONQ=.a21519c6-7733-444a-b29d-b8935f2a90d0@github.com>
 <iacWt-7SfGTZ5hBQN0Y7WTm9P2yHEXZYr_nVn_6EAHQ=.13a1962f-e3e5-4fe6-b764-a787199d900f@github.com>
 <XkOgYL4Ik6D3nIj_3Kr_IR1aPULPyQSTG4yi7ce5hdE=.598cf7be-f000-437b-87e3-5d0575d51929@github.com>
 <B6j7BemE--zLEo8kIwU2CroO6yQn7qNzHhaBJv4qdQU=.6c3d61e5-8be8-42bf-9d5a-d32958031d3c@github.com>
 <z1CrgGzUdZXru1v4inp_q7f5oYyfhki4VETB-HvJFQ4=.a226ed47-025e-4eda-8c1b-40d1195fdcff@github.com>
Message-ID: <L2fz9JRWezBFlbT0TnuV9oiCeMG9sCGjeKksvDBynbo=.b0cffd6f-3410-421e-84ac-3a340ca5a4c1@github.com>

On Tue, 5 Nov 2024 14:24:20 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>>> What happens here if an element is already aligned, and `padding.byteSize() == element.byteAlignment()`? e.g. `MemoryLayout.structLayout(MemoryLayout.paddingLayout(4), ValueLayout.JAVA_INT)`?
>> 
>> This is an error that existed before this PR. On the main branch:
>> 
>> 
>>     @Test
>>     public void alignedByInitialPadding() {
>>         Linker linker = Linker.nativeLinker();
>>         var struct = MemoryLayout.structLayout(
>>                 MemoryLayout.paddingLayout(Integer.BYTES),
>>                 JAVA_INT);
>>         var fd = FunctionDescriptor.of(struct, struct, struct);
>>         linker.downcallHandle(fd);
>>     }
>> 
>> 
>> would produce:
>> 
>> 
>> test TestLinker.alignedByInitialPadding(): failure
>> java.lang.IllegalArgumentException: Member layout 'i4', of '[x4i4]' found at unexpected offset: 4 != 0
>> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkMemberOffset(AbstractLinker.java:235)
>> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayoutRecursive(AbstractLinker.java:195)
>> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayout(AbstractLinker.java:176)
>> 	at java.base/java.util.Optional.ifPresent(Optional.java:178)
>> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.checkLayouts(AbstractLinker.java:167)
>> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle0(AbstractLinker.java:98)
>> 	at java.base/jdk.internal.foreign.abi.AbstractLinker.downcallHandle(AbstractLinker.java:92)
>> 	at TestLinker.alignedByInitialPadding(TestLinker.java:160)
>> 	at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
>
> I've raised a separate issue for this: https://bugs.openjdk.org/browse/JDK-8343620

Looks like you removed the check here: https://github.com/openjdk/jdk/pull/21041/commits/0c134821d6ad7d3c7668d9cc88f7d329b5648827

I think that is good. We already check whether struct fields are aligned when creating a struct layout.

The existing `checkMemberOffset` does the right thing for this case. If tries to manually compute the expected offset of the field (using minimal amount of padding), and then checks if the field actually appears at that offset.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1829682340

From tprinzing at openjdk.org  Tue Nov  5 16:48:14 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Tue, 5 Nov 2024 16:48:14 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v3]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <BSESGYup48gBo9rJSfcozFYgqcHnfXYpfhmDSAggNwM=.f71ff4ee-e19c-4a74-a5cf-717638f13d48@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  improved exception names and handling

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/7113bd75..a8898ffc

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

  Stats: 33 lines in 3 files changed: 9 ins; 8 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From sgehwolf at openjdk.org  Tue Nov  5 17:05:49 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Nov 2024 17:05:49 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <GeX-p8oPeUPnmtFX5WQh9IW_ZLcf86EgOjYgBkGSWyA=.50a46579-ba96-4a18-a168-e00ebd9190a1@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <GeX-p8oPeUPnmtFX5WQh9IW_ZLcf86EgOjYgBkGSWyA=.50a46579-ba96-4a18-a168-e00ebd9190a1@github.com>
Message-ID: <7zzFJwLb-7avQbBufmGg0PvYEPHc-ySXmcbg7sn6Xq8=.af0737b3-fac2-48dd-82fd-25d3dcb93e1d@github.com>

On Thu, 31 Oct 2024 23:20:30 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> `test/jdk/tools/jlink/JmodLess` can be renamed to `linkableRuntimeImage` or a name consistent with the JEP.

Renamed to `runtimeImage`. As it's in the `jlink` folder already it's implied that it's the link from run-time image then.

> test/jtreg-ext/requires/VMProps.java line 743:
> 
>> 741:         // jdk.jlink module has the following resource indicating a runtime-linkable
>> 742:         // image. It's the diff file for runtime linking of the java.base module.
>> 743:         String linkableRuntimeResource = "jdk/tools/jlink/internal/runtimelink/diff_java.base";
> 
> Can this access `LinkableRuntimeImage::DIFF_PATTERN` via qualified exports?

I don't see how, but I may be missing something. `VMProps` isn't in any named module is it? Is it worth sprinkling `jdk.jlink`'s `module-info.java` classes with those exports for test-only purposes, though? Is there precedent that I can look at?

It appears this hard-coded resource seems the lesser of the two evils to me. Thoughts?

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2457721189
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1829713235

From cushon at openjdk.org  Tue Nov  5 17:08:43 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 5 Nov 2024 17:08:43 GMT
Subject: Integrated: 8332744: [REDO] 'internal proprietary API' diagnostics if
 --system is configured to an earlier JDK version
In-Reply-To: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
References: <gUPYrwlffiMAdBJVzY89RUU1RZwkE6w2mO-YaM0B5Nw=.457b29c1-8ae2-40f7-9f6f-73b555dab5f5@github.com>
Message-ID: <zmHdknVXpTiOKGhcEmDmbGNwePKbRt6labO2YqjDvNE=.31016eec-86c9-4615-9510-a71638175754@github.com>

On Fri, 24 May 2024 15:32:09 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

> This change fixes a bug preventing javac from emitting 'compiler.warn.sun.proprietary' diagnostics if `--system` is set to a non-default value. The diagnostics are currently emitted for values of `--release`, and for the default value of `--system`.
> 
> The is a redo of [JDK-8331081](https://bugs.openjdk.org/browse/JDK-8331081), which was backed out in [JDK-8332740](https://bugs.openjdk.org/browse/JDK-8332740) due to a build failure in the microbenchmarks.

This pull request has now been integrated.

Changeset: 839de82c
Author:    Liam Miller-Cushon <cushon at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/839de82c314697d7461b77caa9d85407e3578de3
Stats:     161 lines in 22 files changed: 132 ins; 0 del; 29 mod

8332744: [REDO] 'internal proprietary API' diagnostics if --system is configured to an earlier JDK version

Reviewed-by: vromero

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

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

From kbarrett at openjdk.org  Tue Nov  5 17:11:53 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Tue, 5 Nov 2024 17:11:53 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
Message-ID: <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>

On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: jvm_md.h was included, but not jvm.h...

I kind of wish the __cdecl / __stdcall changes had been done separately.  Oh well.

src/hotspot/os/windows/os_windows.cpp line 5820:

> 5818: }
> 5819: 
> 5820: // FIXME

???

src/hotspot/os/windows/os_windows.cpp line 5863:

> 5861:     return nullptr;
> 5862:   }
> 5863: 

[pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.]
The calculation of `len` is wasting a byte when `lib_name` is null.  The `+2` accounts for the
terminating `NUL` and the underscore separator between the sym_name part and the lib_name
part.  That underscore isn't added when there isn't a lib_name part.  I think the simplest fix would
be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation.  And add some
commentary.

This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment
padding, and it slightly further complicates the calculation.  But additional commentary would still
be desirable, to guide the next careful reader.  In which case it might be simpler to describe the
fixed version.

Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup
change.

src/hotspot/share/include/jvm.h line 1165:

> 1163: #define AGENT_ONLOAD_SYMBOLS    {"Agent_OnLoad"}
> 1164: #define AGENT_ONUNLOAD_SYMBOLS  {"Agent_OnUnload"}
> 1165: #define AGENT_ONATTACH_SYMBOLS  {"Agent_OnAttach"}

There is more cleanup that can be done here.  These definitions are used as
array initializers (hence the surrounding curly braces).  They are now always
singleton, rather than sometimes having 2 elements.  The uses iterate over the
now always singleton arrays.  Those iterations are no longer needed and could
be eliminated.  And these macros could be eliminated, using the corresponding
string directly in each use.  This can all be done as a followup change.

src/java.base/share/native/libjava/NativeLibraries.c line 67:

> 65:         strcat(jniEntryName, "_");
> 66:         strcat(jniEntryName, cname);
> 67:     }

I would prefer this be directly inlined at the sole call (in findJniFunction),
to make it easier to verify there aren't any buffer overrun problems. (I don't
think there are, but looking at this in isolation triggered warnings in my
head.)

Also, it looks like all callers of findJniFunction ensure the cname argument
is non-null. So there should be no need to handle the null case in
findJniFunction (other than perhaps an assert or something). That could be
addressed in a followup. (I've already implicitly suggested elsewhere in this
PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS
thing.)

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

Changes requested by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2415002837
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829659373
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1828969105
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829478432
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1829684759

From aph at openjdk.org  Tue Nov  5 17:15:35 2024
From: aph at openjdk.org (Andrew Haley)
Date: Tue, 5 Nov 2024 17:15:35 GMT
Subject: Integrated: 8341903: Implementation of Scoped Values (Fourth Preview)
In-Reply-To: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
References: <PeLZjsjS3q4vFQu34hRvII89MavzxLYNphWoJ1dD0-Y=.6f464364-0872-4c06-8bd3-4229e404a6d9@github.com>
Message-ID: <uy9o7_0hhd0kldoMEDzz0Ddq3O_5QvYmUF0mwUhgxDs=.4e6d38c4-3e98-4898-aec6-0a4bf71e2e72@github.com>

On Thu, 10 Oct 2024 16:16:51 GMT, Andrew Haley <aph at openjdk.org> wrote:

> The fourth preview of scoped values.

This pull request has now been integrated.

Changeset: 3fab8e37
Author:    Andrew Haley <aph at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3fab8e37bbebbb3930108b2015efe488b1fa1e97
Stats:     161 lines in 7 files changed: 4 ins; 73 del; 84 mod

8341903: Implementation of Scoped Values (Fourth Preview)

Reviewed-by: alanb

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

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

From sgehwolf at openjdk.org  Tue Nov  5 17:19:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Nov 2024 17:19:15 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v43]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <sQhBBQRl3j7U4XYkemoauZ46k8PBXTuZD91inE0V03o=.1bf331fd-8e3a-4d8f-ba62-bb8f7a6843f2@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with four additional commits since the last revision:

 - Rename PackagedModulesVsJmodLessTest => PackagedModulesVsRuntimeImageLinkTest
 - Rename JmodLess => runtimeImage
 - Refactor tests so that they run for default build
   
   When a default JDK build is being produced, the tests create a run-time
   image capable JDK as an interim step before everything else is being
   verified.
   
   For a build that has the run-time image link capability already turned
   on, this extra step is being omitted.
 - Mandy's feedback

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/b702ba8c..40a3f7e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=42
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=41-42

  Stats: 4421 lines in 44 files changed: 2376 ins; 1983 del; 62 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

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

From sgehwolf at openjdk.org  Tue Nov  5 17:19:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Nov 2024 17:19:15 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <hAQ0t6h7-4RW0a43Jsn0o9AwJzFoDoOKsXm7OhlmcLY=.f5980637-2622-4d0c-8481-cdbc4ef46572@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <n2hkylB3HsgWYwZ37GvdJe2SAEX-c9geJJtSN_8NiYY=.20707bda-2fd7-4e09-b42d-319407f40ac6@github.com>
 <hAQ0t6h7-4RW0a43Jsn0o9AwJzFoDoOKsXm7OhlmcLY=.f5980637-2622-4d0c-8481-cdbc4ef46572@github.com>
Message-ID: <IjuacJAM28wKrLXV3SMWNMqbb5fVjUYs24FaMOWPX5I=.4a0821ec-5787-4dd0-b11d-9c8a77c8f4a5@github.com>

On Fri, 1 Nov 2024 18:03:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> I expect that the jmodless tests will first build an image (say `image1`) using jlink `--generate-linkable-runtime` option and then verify `image1/bin/jlink` that links from the run-time image. I don't see `--generate-linkable-runtime` option is used from jmodless tests. I looked at `AbstractLinkableRuntimeTest` which provides the support to create linkable runtime image but not obvious to me. Can you describe the idea of this test framework?

This has gone through a couple of iterations. The idea once was, as you describe now, to create a run-time image link capable JDK on the fly for testing. Then, once the build flag got introduced it changed to it assuming a run-time image link capable JDK (and only removed `jmods` if present - to provoke run-time image based linking) and tests would only activate on such builds.

> OK. I see this now (`@requires jlink.runtime.linkable` in all jmodless tests). I.e. No test for the default JDK build.

Correct. Though, I've been testing builds using `--enable-linkable-runtime` in GHA here for example (Linked in the description of the PR): https://github.com/jerboaa/jdk/actions/runs/11612287720
 
> I think this feature needs test verification even for the default JDK build. One way to do that is to build a test image (say `base-image`) using jlink `--generate-linkable-runtime` option and then verify `base-image/bin/jlink` instead of the JDK.

That makes sense. The framework mostly supported this use-case anyway so I've now extended it to run those tests also on the default build (`jlink` with `-run-time-image` capability). Those now do perform an extra step to create a JDK with the capability first. If the JDK build has the capability already turned on, this step is omitted.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2457744203

From alanb at openjdk.org  Tue Nov  5 17:23:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 17:23:30 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v3]
In-Reply-To: <BSESGYup48gBo9rJSfcozFYgqcHnfXYpfhmDSAggNwM=.f71ff4ee-e19c-4a74-a5cf-717638f13d48@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <BSESGYup48gBo9rJSfcozFYgqcHnfXYpfhmDSAggNwM=.f71ff4ee-e19c-4a74-a5cf-717638f13d48@github.com>
Message-ID: <cVRdc_386fJlJrDNCHuNE87a2c9NzTer3_mSuYByNOg=.a75b5f70-a534-4f9a-a700-5582d69e1569@github.com>

On Tue, 5 Nov 2024 16:48:14 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   improved exception names and handling

Discussed with Tim as there are a number of issues that will need attention. A SocketConnectEvent should only be "offered" for connect events, not cases such as "already connected" or "socket closed". For SocketChannel there is also a socket adaptor (blockingConnect method) that will need to be updated. The non-blocking connect/finishConnect is complicated and there are several issues there. Finally, remoteAddress requires stateLock.

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2457759513

From iris at openjdk.org  Tue Nov  5 17:36:32 2024
From: iris at openjdk.org (Iris Clark)
Date: Tue, 5 Nov 2024 17:36:32 GMT
Subject: RFR: 8343071: Broken anchors to restricted method page and some
 redundant ids
In-Reply-To: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
References: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
Message-ID: <_jJWKczMY5HOzk7ApY43SWLDTGxQupjCTFeNltj18vA=.65f27b3a-d404-4dcf-9b35-cc89b56d83c8@github.com>

On Fri, 1 Nov 2024 17:19:00 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this patch that brings the last changes to fix broken anchors in the source code.
> 
> The links updated in this patch can be grouped into 3 sections, they were minor so I grouped them into one PR.
> 
> 1- Move some references from the old `foreign/package-summary.html#restricted` to the new `Restricted Methods` page, these were broken after https://github.com/openjdk/jdk/commit/f4dccfd4cf354f360b823c8cce15bb54ef90e9ca
> 
> 2- Remove a redundant `<a>` tag in `Class.java`, the id not needed as we already created an index.
> 
> 3- Fix some broken anchors in `StructuredTaskScope.java`, the text will be updated in a JEP but we can fix the current text now. 
> 
> Thanks!

Marked as reviewed by iris (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21839#pullrequestreview-2416297480

From naoto.sato at oracle.com  Tue Nov  5 17:48:54 2024
From: naoto.sato at oracle.com (Naoto Sato)
Date: Tue, 5 Nov 2024 09:48:54 -0800
Subject: Allowing apps to force sun.jnu.encoding = "UTF-8" on Windows
In-Reply-To: <CAHY-eHu9UDN5mJufVf1FySGgc-W=g8MhBoYcuMB4iOr8HRhCAg@mail.gmail.com>
References: <mailman.17375.1730309194.124.core-libs-dev@openjdk.org>
 <CAHY-eHva4JsvMfh18PxLp6jA9G254dB4a2EDT5xFr44s6rZHng@mail.gmail.com>
 <440fa736-4282-40ca-a084-aba1e14ab574@oracle.com>
 <CAHY-eHv2H3SeT_UCUVj=z6=RJsnF17FLgYEmu1ZhPvvC-_ETBw@mail.gmail.com>
 <d24fd299-3af2-4b5d-aa59-61be6294bcf2@oracle.com>
 <CAHY-eHu9UDN5mJufVf1FySGgc-W=g8MhBoYcuMB4iOr8HRhCAg@mail.gmail.com>
Message-ID: <7ad3fd45-d05c-4b6d-a6b9-092aa8d8d308@oracle.com>

Hi Fabian,

On 11/5/24 12:52 AM, Fabian Meumertzheim wrote:
> On Mon, Nov 4, 2024 at 8:46?PM Naoto Sato <naoto.sato at oracle.com> wrote:
>> I am afraid that the risk that would be involved in configuring
>> sun.jnu.encoding exceeds the benefit it would bring, as the encoding is
>> so baked in the basis of the Windows Java runtime. Since Microsoft
>> itself now recommends users choose UTF-8 as the ANSI code page (over
>> changing apps to use -W APIs)[1], I think we would want to wait for that
>> glorious day.
>>
>> Naoto
>>
>> [1]
>> https://urldefense.com/v3/__https://learn.microsoft.com/en-us/windows/apps/design/globalizing/use-utf8-code-page*-a-vs--w-apis__;Iw!!ACWV5N9M2RV99hQ!JcTCVhRAZCQZaQWCt8WQJ8oN31jpETS4danV6j-3PXtKlK9ffLVuPY0G-XEooSus0sCFYoCNx-dJNyyNSmdRzg$
> 
> My understanding of that page is that Microsoft recommends
> *application developers* to choose UTF-8 as the code page for their
> apps by adding a directive to their app manifest. While this works
> well for native applications, it doesn't directly apply to Java
> applications as the manifest is that of the java.exe launcher binary,
> which is necessarily static (and currently doesn't set the
> `activeCodePage` directive).

Yes, the article is for app developers, but my intention quoting that 
specific paragraph (-A vs -W) was to point out Microsoft's directional 
change:

```
Until recently, Windows has emphasized "Unicode" -W variants over -A 
APIs. However, recent releases have used the ANSI code page and -A APIs 
as a means to introduce UTF-8 support to apps. If the ANSI code page is 
configured for UTF-8, then -A APIs typically operate in UTF-8. This 
model has the benefit of supporting existing code built with -A APIs 
without any code changes.
```

This was a 180 degree direction change, which lets ANSI based apps 
(including Java launcher) work without any changes in apps side.

> 
> We could choose to rely on users switching to the UTF-8 codepage
> system-wide. This is possible as of the 1809 build of Windows 10, but
> is not the default, still marked as Beta in the latest version,
> requires admin privileges to enable, and can break other applications,
> even of other users. This may become the default some day, but it's
> unclear whether this will happen in the foreseeable future, especially
> since there is a backwards compatible alternative for native
> applications.

I cannot speak for MS, but I read the article as the day will still 
come, when UTF-8 becomes the default on Windows.

> 
> I understand that incrementally refactoring the Windows Java runtime
> until its encoding becomes configurable is too risky. Taking that into
> account, what do you think of offering an additional entrypoint for
> the Java launcher on Windows, say java-utf8.exe, that is identical to
> java.exe except that it specifies
> `<activeCodePage>UTF-8</activeCodePage>` in its app manifest? This
> would give users the desired opt-in behavior with no changes to the
> actual implementation of the Java runtime. (In fact, in my concrete
> use case, we are relying on this as a workaround by patching the
> manifest in java.exe with a tool [1].)

Yes, it would be possible if two launchers were provided. However, 
please note that it would also require the maintenance cost doubled. 
Some JDK distributors may be interested, but I am not sure it would be 
implemented in the OpenJDK Windows reference implementation.

Naoto

From bpb at openjdk.org  Tue Nov  5 17:58:35 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 5 Nov 2024 17:58:35 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
Message-ID: <a7tVih_-xTKHa7_mXMsoMWddPThkDXgTZR0vn7bOC04=.d07f1cb4-eed0-404b-9015-18e8cc86b80e@github.com>

On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Minor makefile tweak

continue;

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

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2457827897

From naoto at openjdk.org  Tue Nov  5 18:14:29 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 5 Nov 2024 18:14:29 GMT
Subject: RFR: 8342936: Enhance java.io.IO with parameter-less println() and
 readln() [v3]
In-Reply-To: <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
 <GIU_Xlc5Yj__L93sxQnPyri420Zyhh3m4GEFrOJz7xE=.bf03cd11-9d67-49be-b122-2c213b2ef45e@github.com>
Message-ID: <oiwrvkaNtK6NaRNEF8ichKEGA7tI-m5qN0OeTPsD42M=.aedcc497-685c-4e3a-ac84-4da3e45892cd@github.com>

On Tue, 29 Oct 2024 08:13:22 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This PR is simply adding parameter-less `java.io.IO.{println(),readln()}`, with the (hopefully) obvious semantics, plus the corresponding wiring to make those work. This may become part of JEP 495:
>> https://openjdk.org/jeps/495
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixing test for Console.readln/readLine, ensuring the proper methods are called.

> > My question (please don't bash me, I am new): Any chance we can set the encoding of console? I tested on Java 23 (Windows) and the encoding is `windows-1252` so it will not display unicode characters correctly.
> 
> I believe that after #21569, the `Console` encoding used by the JDK can be overwritten with `stdout.encoding`.

Yes, that is in place. Will be available in JDK24: https://bugs.openjdk.org/browse/JDK-8342208

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

PR Comment: https://git.openjdk.org/jdk/pull/21693#issuecomment-2457858145

From mullan at openjdk.org  Tue Nov  5 18:30:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 18:30:37 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v7]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <djVIdf6f-DCXWXIZXcS0tr5pnTYNYUi_qzbrtKGbUB0=.ce9aafa1-bf99-4f36-a520-a4b6ff670686@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 213 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove "access" and "policy" options from debug help.
 - Merge branch 'master' into jep486
 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
 - remove MainClassCantBeLoadedTest from problemlisting
 - remove LauncherErrors test from problemlisting
 - Merge branch 'master' into jep486
 - Remove left-over paragraph about SM use from LoggerFinder
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 203 more: https://git.openjdk.org/jdk/compare/f69b6016...51d2a2a3

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=06
  Stats: 68938 lines in 1889 files changed: 2490 ins; 62600 del; 3848 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From liach at openjdk.org  Tue Nov  5 18:37:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Nov 2024 18:37:43 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory
Message-ID: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>

After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.

This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.

The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

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

Commit messages:
 - Specify consequence
 - 8343064: ClassFormatError: Illegal class name from InnerClassLambdaMetafactory

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

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

From duke at openjdk.org  Tue Nov  5 18:37:43 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Tue, 5 Nov 2024 18:37:43 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <p_jkNelulSPiaKDUjsdXC64dqnjtSwqs_C9aa6OuJU8=.44ab5241-e049-4057-a9ca-4b339c3f71fb@github.com>

On Tue, 5 Nov 2024 18:29:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

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

PR Review: https://git.openjdk.org/jdk/pull/21912#pullrequestreview-2416413346

From alanb at openjdk.org  Tue Nov  5 18:43:35 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 5 Nov 2024 18:43:35 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <dwyezuDOlJvWb-rxo4x2E43660EDbUOL-WonXgeW67o=.06ebe2b1-c910-444d-91cf-b92e723f12c0@github.com>

On Tue, 5 Nov 2024 18:29:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

Is it possible to add a test for this?

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

PR Comment: https://git.openjdk.org/jdk/pull/21912#issuecomment-2457907971

From qamai at openjdk.org  Tue Nov  5 18:50:33 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Tue, 5 Nov 2024 18:50:33 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
Message-ID: <CsLdH47WoNKervXaAPvv7_MU_wZF3ytTbKRI8Ng9liQ=.e21a403a-e875-4d25-ae16-ef2a8b07de0f@github.com>

On Tue, 5 Nov 2024 14:07:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year
>  - address reviews

Thanks a lot for your reviews and suggestions, I will merge this patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21810#issuecomment-2457920466

From mullan at openjdk.org  Tue Nov  5 18:58:22 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 18:58:22 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v8]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 217 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Remove "access" and "policy" options from debug help.
 - Merge branch 'master' into jep486
 - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
 - remove MainClassCantBeLoadedTest from problemlisting
 - remove LauncherErrors test from problemlisting
 - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9

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

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=07
  Stats: 68934 lines in 1889 files changed: 2490 ins; 62600 del; 3844 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

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

From liach at openjdk.org  Tue Nov  5 19:21:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Nov 2024 19:21:58 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v2]
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <t_kN9keWunZ0GSPIayskKgmZXIKh5mVFX2BglAv6wkI=.ab9752b3-0c00-4ed6-b31a-e6bf430adf3b@github.com>

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Add a test to ensure serializable lambda creation and basic execution in hidden classes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21912/files
  - new: https://git.openjdk.org/jdk/pull/21912/files/08086c42..4e3790a9

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

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

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

From liach at openjdk.org  Tue Nov  5 19:21:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 5 Nov 2024 19:21:59 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <knUygDwwKMeBj_n3E4W_E2QRbw0BSMSSJh8mCAmBs-Q=.9b5e0964-9a0f-4090-a2d8-ef9a0fb42179@github.com>

On Tue, 5 Nov 2024 18:29:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

Test added to ensure that serializable lambdas can be created and its SAM can be called when the caller is a hidden class.  Note that we do not guarantee anything about the serialization functionality itself.  We can add serialization support for hidden classes in the future, but I doubt we do as it is niche and requires larger implementation changes.

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

PR Comment: https://git.openjdk.org/jdk/pull/21912#issuecomment-2457973143

From mullan at openjdk.org  Tue Nov  5 19:24:12 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 19:24:12 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <xRVrQFl6ZVB6qRtcmHuhoKR_Mce8hOgkrNpDl-KBCUE=.3c80cc67-9f11-4955-a56e-100740a61061@github.com>
 <0j1uUkVMlrLOxFPmXYzvHcDe9I3a34Fbfjh4hBK2BL0=.13667c44-1516-4784-823e-7216e886512c@github.com>
 <kmiW_HVglMJ8QaDWdo-YZVZbfZGBrSoWiZgs44OzQ_I=.37e4e07a-e18c-4007-b4ec-b69ac7e96cfd@github.com>
Message-ID: <oObdOTPzC4tiiWiwoqy9kJo6t60O7P7kqlnArXu9wbc=.925ca6c4-fa1d-4433-bff2-70b3e66bbce8@github.com>

On Sun, 3 Nov 2024 12:33:05 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Right - this paragraph - lines 1620-1625 (old file) / 1362-1367 (new file) is no longer relevant and should be removed too. Thanks for spotting that.
>
> Removed in jep486 branch in sandbox so will get picked up when PR is refreshed.

Fixed in https://github.com/openjdk/jdk/pull/21498/commits/ab586f6619ca5f7e213876219abf61a36155735c

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1829886748

From vaivanov at openjdk.org  Tue Nov  5 19:26:29 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 5 Nov 2024 19:26:29 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers
In-Reply-To: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
Message-ID: <65x40rhtmRWGXTj4HnTruu-RUm_TYfOr3V-AmKrQtG4=.6f970809-b54e-49c9-89ec-c04f30aa91af@github.com>

On Thu, 31 Oct 2024 21:33:11 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
> Unit tests was not affected:
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp                                     516   516     0     0
>    jtreg:test/jdk/javax/xml                             70    70     0     0
> ==============================
> TEST SUCCESS
> 
> The tier1 is OK too.

specjvm2008::xml.validation scores
Original build: 1 vCPU: 415.6; 16vCPU: 5755.27; 32 vCPU: 10467.91; 112vCPU: 17524.4
Patched build: 1vCPU: 415.65; 16vCPU: 5832.28; 32vCPU: 10622.34; 112vCPU: 21773.84
The run-to-run variation for this workload ~5%. So, for the low vCPU numbers no differences with/without patch.

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

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2457981375

From swen at openjdk.org  Tue Nov  5 19:37:53 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 5 Nov 2024 19:37:53 GMT
Subject: RFR: 8337279: Optimize format instant [v10]
In-Reply-To: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
References: <17bf2n2yLh8dwpk9nsTF9G9UKHYWLDXDh0kie-9YrcA=.f19351bb-d47f-4ded-8a63-07914de70b4f@github.com>
Message-ID: <f8RcBY64AD_DC3vjsFGqGeET-tvBIx3Gc4XhTlX0DWs=.ce6ba313-0c33-4c45-864c-699cefa869c4@github.com>

> By removing the redundant code logic in DateTimeFormatterBuilder$InstantPrinterParser#formatTo, the codeSize can be reduced and the performance can be improved.

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

 - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
 - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
 - suggestion from @jensli
 - Speed up Instant.toString using JavaTimeAccess
 - add JavaTimeAccess SharedSecrets
 - Merge remote-tracking branch 'upstream/master' into optim_instant_fmt_202407
 - breaking out the printNano methods
 - copyright
 - Update src/java.base/share/classes/java/time/format/DateTimeFormatterBuilder.java
   
   Co-authored-by: Stephen Colebourne <scolebourne at joda.org>
 - 1. fix handle fraction == -1
   2. Split two methods to make codeSize less than 325
 - ... and 2 more: https://git.openjdk.org/jdk/compare/8c44b116...a9c5a36e

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20353/files
  - new: https://git.openjdk.org/jdk/pull/20353/files/1c2482e7..a9c5a36e

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

  Stats: 183697 lines in 2937 files changed: 99517 ins; 70736 del; 13444 mod
  Patch: https://git.openjdk.org/jdk/pull/20353.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20353/head:pull/20353

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

From sgehwolf at openjdk.org  Tue Nov  5 19:39:08 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Nov 2024 19:39:08 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v44]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <pddnNqxl-WC5MdCv6HNZkCqxGgJ6xfegmNy8LTor7AI=.af74ec9a-a8a5-416b-b1d1-0228fd6f7761@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Fix SystemModulesTest2 when linkable runtime but no packaged modules

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/40a3f7e2..96443bef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=43
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=42-43

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

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

From sgehwolf at openjdk.org  Tue Nov  5 19:50:56 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 5 Nov 2024 19:50:56 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v44]
In-Reply-To: <pddnNqxl-WC5MdCv6HNZkCqxGgJ6xfegmNy8LTor7AI=.af74ec9a-a8a5-416b-b1d1-0228fd6f7761@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <pddnNqxl-WC5MdCv6HNZkCqxGgJ6xfegmNy8LTor7AI=.af74ec9a-a8a5-416b-b1d1-0228fd6f7761@github.com>
Message-ID: <ecHgQTa5u_HnD1Up3_D6OYlH5HAPPjUwyx5ycySbZI4=.3fd6fc14-50c8-42db-9eba-87c4182ba577@github.com>

On Tue, 5 Nov 2024 19:39:08 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix SystemModulesTest2 when linkable runtime but no packaged modules

New tests now also run for a default JDK build (which doesn't enable the run-time image capability in `jlink`):


$ ./build/linux-x86_64-server-release/images/jdk/bin/jlink --help | tail -n1
Capabilities: -run-time-image
$ make  LOG=info  test TEST="jtreg:test/jdk/tools/jlink/runtimeImage"
[...]
Running test 'jtreg:test/jdk/tools/jlink/runtimeImage'
Passed: tools/jlink/runtimeImage/BasicJlinkTest.java#default_build
Passed: tools/jlink/runtimeImage/GenerateJLIClassesTest.java#default_build
Passed: tools/jlink/runtimeImage/AddOptionsTest.java#default_build
Passed: tools/jlink/runtimeImage/CustomModuleJlinkTest.java#default_build
Passed: tools/jlink/runtimeImage/BasicJlinkMissingJavaBase.java#default_build
Passed: tools/jlink/runtimeImage/KeepPackagedModulesFailTest.java#default_build
Passed: tools/jlink/runtimeImage/ModifiedFilesExitTest.java#default_build
Passed: tools/jlink/runtimeImage/MultiHopTest.java#default_build
Passed: tools/jlink/runtimeImage/ModifiedFilesWarningTest.java#default_build
Passed: tools/jlink/runtimeImage/PatchedJDKModuleJlinkTest.java#default_build
Passed: tools/jlink/runtimeImage/JavaSEReproducibleTest.java#default_build
Passed: tools/jlink/runtimeImage/SystemModulesTest.java#default_build
Passed: tools/jlink/runtimeImage/SystemModulesTest2.java#default_build
Passed: tools/jlink/runtimeImage/PackagedModulesVsRuntimeImageLinkTest.java#default_build
Test results: passed: 14
[...]

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2458026613

From vromero at openjdk.org  Tue Nov  5 19:55:58 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 5 Nov 2024 19:55:58 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call
Message-ID: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>

Javac is not issuing a mandated unchecked cast warning for code like:


import java.lang.invoke.VarHandle;

class VarHandleCast<V> {
     VarHandle vh;
     V method(Object obj) {
         return (V)vh.getAndSet(this, obj);
     }
}


according to the spec the return type inferred for this method polymorphic method should be Object see:

-  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
...
    ? The compile-time result is determined as follows:
        Otherwise, if the method invocation expression is the operand of a cast
    expression (?15.16), the compile-time result is the erasure of the type of the
    cast expression (?4.6).

javac is not doing the type erasure mandated by the spec which is what this PR is fixing

TIA

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

Commit messages:
 - 8343286: Redundant cast in polymorphic method call

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

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

From mullan at openjdk.org  Tue Nov  5 20:10:20 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 5 Nov 2024 20:10:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v8]
In-Reply-To: <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <6Ys0lsn0cw84Hsu-SaEsMIeno_mE2fwcB-Er45r3S2Y=.9d2da633-3647-4539-93ef-d5c1d186e804@github.com>
Message-ID: <nKDNw4mah9BaszGzCs83ttYt9TzQdfhGCiO_8quB0vQ=.4234a809-ebc3-4aa5-8265-08f8cebb1bf5@github.com>

On Tue, 5 Nov 2024 18:58:22 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 217 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Remove "access" and "policy" options from debug help.
>  - Merge branch 'master' into jep486
>  - Merge branch 'jep486' of https://github.com/openjdk/jdk-sandbox into jep486
>  - remove MainClassCantBeLoadedTest from problemlisting
>  - remove LauncherErrors test from problemlisting
>  - ... and 207 more: https://git.openjdk.org/jdk/compare/3fab8e37...e9e7f0c9

The latest update includes:
- merging with the mainline sources
- a couple of test removals from the ProblemList for tests that no longer apply
- removal of the "policy" and "access" options from the `-Djava.security.debug` help option.
- a small update to remove some SM specific text from the `System.LoggerFinder` class description.
- copyright header updates for several tests that were previously modified
- addition of a few client manual tests to the ProblemList that have dependencies on the Security Manager and will be resolved later

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

PR Comment: https://git.openjdk.org/jdk/pull/21498#issuecomment-2458058335

From nbenalla at openjdk.org  Tue Nov  5 21:45:38 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 5 Nov 2024 21:45:38 GMT
Subject: RFR: 8343071: Broken anchors to restricted method page and some
 redundant ids
In-Reply-To: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
References: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
Message-ID: <lornhzLUlazzEMwS3VX9YyoYs2ssRK5q4PZpRVwqB8Q=.743d7c34-47ba-46f5-aa47-52a0acb79447@github.com>

On Fri, 1 Nov 2024 17:19:00 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this patch that brings the last changes to fix broken anchors in the source code.
> 
> The links updated in this patch can be grouped into 3 sections, they were minor so I grouped them into one PR.
> 
> 1- Move some references from the old `foreign/package-summary.html#restricted` to the new `Restricted Methods` page, these were broken after https://github.com/openjdk/jdk/commit/f4dccfd4cf354f360b823c8cce15bb54ef90e9ca
> 
> 2- Remove a redundant `<a>` tag in `Class.java`, the id not needed as we already created an index.
> 
> 3- Fix some broken anchors in `StructuredTaskScope.java`, the text will be updated in a JEP but we can fix the current text now. 
> 
> Thanks!

Thanks Maurizio, Iris for the reviews

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

PR Comment: https://git.openjdk.org/jdk/pull/21839#issuecomment-2458205549

From nbenalla at openjdk.org  Tue Nov  5 21:45:39 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Tue, 5 Nov 2024 21:45:39 GMT
Subject: Integrated: 8343071: Broken anchors to restricted method page and some
 redundant ids
In-Reply-To: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
References: <gAXRgIqqr_HcRt1Xkk6NZ-xvWmsy_2dGef3eJKGNTQA=.00d919dd-cff8-4b3d-b77e-fc61ed64c852@github.com>
Message-ID: <P93HFFoli4IhLsgCW_Sqcc2Ftkyoe_KzStitut1qrZM=.30515f1d-fb71-46e5-a951-1a59a050c3f9@github.com>

On Fri, 1 Nov 2024 17:19:00 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this patch that brings the last changes to fix broken anchors in the source code.
> 
> The links updated in this patch can be grouped into 3 sections, they were minor so I grouped them into one PR.
> 
> 1- Move some references from the old `foreign/package-summary.html#restricted` to the new `Restricted Methods` page, these were broken after https://github.com/openjdk/jdk/commit/f4dccfd4cf354f360b823c8cce15bb54ef90e9ca
> 
> 2- Remove a redundant `<a>` tag in `Class.java`, the id not needed as we already created an index.
> 
> 3- Fix some broken anchors in `StructuredTaskScope.java`, the text will be updated in a JEP but we can fix the current text now. 
> 
> Thanks!

This pull request has now been integrated.

Changeset: 69bc0887
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/69bc0887741a7dd7eda234f5b3252c3c5e46d87e
Stats:     7 lines in 4 files changed: 0 ins; 0 del; 7 mod

8343071: Broken anchors to restricted method page and some redundant ids
8332747: Broken links in StructuredTaskScope

Reviewed-by: mcimadamore, iris

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

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

From asemenyuk at openjdk.org  Tue Nov  5 22:39:57 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Nov 2024 22:39:57 GMT
Subject: RFR: 8343610: InOutPathTest jpackage test produces invalid app image
 on macOS
Message-ID: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>

- fix `JPackageCommand.excludeAppLayoutAsserts()`;
- fix `InOutPath` test case that will make jpackage produce an invalid app image on macOS.

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

Commit messages:
 - Better wording of the comment
 - One more try to make it work on OSX
 - Bugfix for the case when `--app-content` is set to `--temp`
 - Bugfix and additional verification of input added
 - Merge branch 'master' into JDK-8343610
 - 8343610: InOutPathTest jpackage test produces invalid app image on macOS

Changes: https://git.openjdk.org/jdk/pull/21909/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21909&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343610
  Stats: 59 lines in 4 files changed: 46 ins; 0 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/21909.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21909/head:pull/21909

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

From asemenyuk at openjdk.org  Tue Nov  5 22:39:57 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Nov 2024 22:39:57 GMT
Subject: RFR: 8343610: InOutPathTest jpackage test produces invalid app
 image on macOS
In-Reply-To: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
References: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
Message-ID: <BeuCZDHHxu-NmI5FXH8YVNkzHeANzBVdgoG-PzpCtl0=.475041f6-29e2-4924-b835-91f645965fe1@github.com>

On Tue, 5 Nov 2024 16:08:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - fix `JPackageCommand.excludeAppLayoutAsserts()`;
> - fix `InOutPath` test case that will make jpackage produce an invalid app image on macOS.

@sashamatveev ptal

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

PR Comment: https://git.openjdk.org/jdk/pull/21909#issuecomment-2458277793

From asemenyuk at openjdk.org  Tue Nov  5 22:44:28 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 5 Nov 2024 22:44:28 GMT
Subject: RFR: 8343610: InOutPathTest jpackage test produces invalid app
 image on macOS
In-Reply-To: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
References: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
Message-ID: <cQ50VjDjK-9ch-aPo0iQ_ddbqhg0xYxNDtC39fmgCrM=.d5d92d22-a32e-4f01-9436-59c76ca6ba30@github.com>

On Tue, 5 Nov 2024 16:08:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - fix `JPackageCommand.excludeAppLayoutAsserts()`;
> - fix `InOutPath` test case that will make jpackage produce an invalid app image on macOS.

@MBaesken can you try this fix in your environment?

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

PR Comment: https://git.openjdk.org/jdk/pull/21909#issuecomment-2458284327

From almatvee at openjdk.org  Tue Nov  5 23:05:28 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 5 Nov 2024 23:05:28 GMT
Subject: RFR: 8343610: InOutPathTest jpackage test produces invalid app
 image on macOS
In-Reply-To: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
References: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
Message-ID: <ndgOYiXCkysd5jVamyesZGZXZIGTTb_5PP6ebuM-7mg=.89aad14a-8b07-494a-b19a-fd5db39b6e24@github.com>

On Tue, 5 Nov 2024 16:08:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - fix `JPackageCommand.excludeAppLayoutAsserts()`;
> - fix `InOutPath` test case that will make jpackage produce an invalid app image on macOS.

Looks good.

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

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21909#pullrequestreview-2416933477

From cushon at openjdk.org  Tue Nov  5 23:44:30 2024
From: cushon at openjdk.org (Liam Miller-Cushon)
Date: Tue, 5 Nov 2024 23:44:30 GMT
Subject: RFR: 8328821: Map.of() derived view collection mutators should
 throw UnsupportedOperationException [v7]
In-Reply-To: <If4E-nt-VM_sg_7yTZnKfPD1wiKZaeVxYeONnR1AzPk=.34a8be90-522a-4d70-bbf1-44295e247a0d@github.com>
References: <np86XgOjE1gYESY--2_OXTPIvO1mvmJbD3UH-lIn9TY=.c4a288f1-0469-4cc6-a076-58bab04d24ad@github.com>
 <If4E-nt-VM_sg_7yTZnKfPD1wiKZaeVxYeONnR1AzPk=.34a8be90-522a-4d70-bbf1-44295e247a0d@github.com>
Message-ID: <tyzSbsuybS1bpZFh4OO-VtmD2DLK0rpR1ga4fwCRmUI=.9ccbbac9-84f8-44f6-8238-cbb8eba9f66e@github.com>

On Tue, 9 Jul 2024 23:17:47 GMT, Liam Miller-Cushon <cushon at openjdk.org> wrote:

>> This change overrides mutator methods in the implementation returned by `Map.of().entrySet()` to throw `UnsupportedOperationException`.
>
> Liam Miller-Cushon has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update test/jdk/java/util/Collection/MOAT.java
>   
>   Co-authored-by: Chen Liang <liach at openjdk.org>

Let's keep this open for now

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

PR Comment: https://git.openjdk.org/jdk/pull/18522#issuecomment-2458418514

From pchilanomate at openjdk.org  Tue Nov  5 23:55:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 23:55:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
 <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
Message-ID: <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>

On Mon, 4 Nov 2024 20:55:07 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Update comment block in objectMonitor.cpp
>>  - Fix issue with unmounted virtual thread when dumping heap
>>  - Remove ThawBase::possibly_adjust_frame()
>
> src/hotspot/share/runtime/continuation.cpp line 134:
> 
>> 132:   return true;
>> 133: }
>> 134: #endif // INCLUDE_JVMTI
> 
> Could you, please, consider the simplification below?
> 
> 
> #if INCLUDE_JVMTI
> // return true if started vthread unmount
> bool jvmti_unmount_begin(JavaThread* target) {
>   assert(!target->is_in_any_VTMS_transition(), "must be");
> 
>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>   // be installed in start_VTMS_transition() so we need to check it here.
>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>     JvmtiThreadState* state = target->jvmti_thread_state();
>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>       return false;
>     }
>   }
>   // Don't preempt in case there is an async exception installed since
>   // we would incorrectly throw it during the unmount logic in the carrier.
>   if (target->has_async_exception_condition()) {
>     return false;
>   }
>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>   } else {
>     target->set_is_in_VTMS_transition(true);
>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>   }
>   return false;
> }
> 
> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>   if (target->is_in_VTMS_transition()) {
>     // We caught target at the end of a mount transition.
>     return false;
>   }
>   return true;
> }
> #endif // INCLUDE_JVMTI
> ...
> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>     return false;
>   }
>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
> }
> ...
> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>   verify_preempt_preconditions(target, continuation);
> 
>   if (LockingMode == LM_LEGACY) {
>     return freeze_unsupported;
>   }
>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>     return freeze_pinned_native;
>   }
>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>   log_trace(continuations, preempt)("try_preempt: %d", res);
>   return res;
> }
> 
> 
> The following won't be needed:
> 
> target->set_pending_jvmti_unmou...

Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838

From pchilanomate at openjdk.org  Tue Nov  5 23:55:53 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 5 Nov 2024 23:55:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
 <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
 <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>
Message-ID: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.14e90620-411b-41db-8455-14ffa4697f71@github.com>

On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 134:
>> 
>>> 132:   return true;
>>> 133: }
>>> 134: #endif // INCLUDE_JVMTI
>> 
>> Could you, please, consider the simplification below?
>> 
>> 
>> #if INCLUDE_JVMTI
>> // return true if started vthread unmount
>> bool jvmti_unmount_begin(JavaThread* target) {
>>   assert(!target->is_in_any_VTMS_transition(), "must be");
>> 
>>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>>   // be installed in start_VTMS_transition() so we need to check it here.
>>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>>     JvmtiThreadState* state = target->jvmti_thread_state();
>>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>>       return false;
>>     }
>>   }
>>   // Don't preempt in case there is an async exception installed since
>>   // we would incorrectly throw it during the unmount logic in the carrier.
>>   if (target->has_async_exception_condition()) {
>>     return false;
>>   }
>>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>>   } else {
>>     target->set_is_in_VTMS_transition(true);
>>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>>   }
>>   return false;
>> }
>> 
>> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>>   if (target->is_in_VTMS_transition()) {
>>     // We caught target at the end of a mount transition.
>>     return false;
>>   }
>>   return true;
>> }
>> #endif // INCLUDE_JVMTI
>> ...
>> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>>     return false;
>>   }
>>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
>> }
>> ...
>> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>>   verify_preempt_preconditions(target, continuation);
>> 
>>   if (LockingMode == LM_LEGACY) {
>>     return freeze_unsupported;
>>   }
>>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>>     return freeze_pinned_native;
>>   }
>>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>>   log_trace(con...
>
> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.

[1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411

From pchilanomate at openjdk.org  Wed Nov  6 00:08:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v32]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
Message-ID: <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/124efa0a..c0c7e6cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=31
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=30-31

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

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

From pchilanomate at openjdk.org  Wed Nov  6 00:08:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
Message-ID: <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>

On Tue, 5 Nov 2024 11:35:29 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>  Is this posted after the VirtualThreadMount extension event posted?
>
It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909

From pchilanomate at openjdk.org  Wed Nov  6 00:08:16 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:16 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
 <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
Message-ID: <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>

On Tue, 5 Nov 2024 23:58:39 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 1643:
>> 
>>> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
>>> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
>>> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);
>> 
>> We post a JVMTI `MonitorWaited` event here for a virtual thread.
>> A couple of questions on this:
>> - Q1: Is this posted after the `VirtualThreadMount` extension event posted?
>>          Unfortunately, it is not easy to make this conclusion.
>> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
>>           Does it post the `MonitorWaited` event for this virtual thread as well?
>>           If not, then it is not clear how posting for virtual thread is avoided.
>
>>  Is this posted after the VirtualThreadMount extension event posted?
>>
> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

> The JvmtiExport::post_monitor_waited() is called at the line 1801.
> Does it post the MonitorWaited event for this virtual thread as well?
>
That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475

From pchilanomate at openjdk.org  Wed Nov  6 00:08:17 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 00:08:17 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <tEsdXiiwSouYPshYr9vLW4gSORoKYUCnaH2_vB-eSEg=.e0576133-5fc4-4a6a-bd37-932a20d8124b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <tEsdXiiwSouYPshYr9vLW4gSORoKYUCnaH2_vB-eSEg=.e0576133-5fc4-4a6a-bd37-932a20d8124b@github.com>
Message-ID: <mRFEu40W_IpSm-Pd85OFh6qH5T2M2GJyr3EoB72MZRQ=.d60717b6-4096-4e7a-adea-af19a1c18241@github.com>

On Tue, 5 Nov 2024 14:35:11 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with five additional commits since the last revision:
>> 
>>  - Add oopDesc::has_klass_gap() check
>>  - Rename waitTimeout/set_waitTimeout accessors
>>  - Revert suggestion to ThawBase::new_stack_frame
>>  - Improve JFR pinned reason in event
>>  - Use freeze_result consistently
>
> src/hotspot/share/runtime/objectMonitor.inline.hpp line 50:
> 
>> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
>> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
>> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");
> 
> Suggestion:
> 
>   assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830229529

From tprinzing at openjdk.org  Wed Nov  6 00:15:44 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 6 Nov 2024 00:15:44 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
Message-ID: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>

> Adds a JFR event for socket connect operations.
> 
> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.

Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:

  suggested changes

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21528/files
  - new: https://git.openjdk.org/jdk/pull/21528/files/a8898ffc..ce9d39e2

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

  Stats: 76 lines in 2 files changed: 49 ins; 15 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21528.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21528/head:pull/21528

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

From swen at openjdk.org  Wed Nov  6 00:34:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Nov 2024 00:34:44 GMT
Subject: RFR: 8343650: Reuse StringLatin1::putCharsAt and
 StringUTF16::putCharsAt
Message-ID: <z6Fuk2vuX3I9lkrBuiou_DW41ZDF6YN_puY97ZggS6I=.f281484c-083f-46d7-9a21-583931341156@github.com>

Reuse the optimized putCharsAt method of StringLatin1 and StringUTF16 in PR #19626 to simplify the code, eliminate boundary checks, and improve performance

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

Commit messages:
 - use StringLatin1::putCharsAt and StringUTF16::putCharsAt

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

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

From dholmes at openjdk.org  Wed Nov  6 01:00:45 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 01:00:45 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
Message-ID: <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>

On Mon, 4 Nov 2024 20:42:59 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix: jvm_md.h was included, but not jvm.h...

I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

src/hotspot/os/windows/os_windows.cpp line 510:

> 508: // Thread start routine for all newly created threads.
> 509: // Called with the associated Thread* as the argument.
> 510: static unsigned thread_native_entry(void* t) {

Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`.
https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2417056020
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1830259353

From amenkov at openjdk.org  Wed Nov  6 01:47:45 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Wed, 6 Nov 2024 01:47:45 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
Message-ID: <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>

On Wed, 6 Nov 2024 00:58:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170
`On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.`

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458534929

From liach at openjdk.org  Wed Nov  6 03:16:39 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 6 Nov 2024 03:16:39 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v2]
In-Reply-To: <DPd3cEy9NeRFgO3diWAiIWU6GQV7tMrGElJjwVsA8jI=.2fc1e645-c6ee-4199-8ed7-6f44a063990b@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <DPd3cEy9NeRFgO3diWAiIWU6GQV7tMrGElJjwVsA8jI=.2fc1e645-c6ee-4199-8ed7-6f44a063990b@github.com>
Message-ID: <cXBGAQwawEKZc_Hjn5L5qXz7I0lH3BorjLVqqrEQtLo=.d66ff05f-ac30-4408-8a48-851a644ecd83@github.com>

On Tue, 5 Nov 2024 15:47:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
>> 
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
>> 3. Eliminate duplicate code in BigDecimal
>
> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410
>  - fix Helper
>  - fix Helper
>  - fix Helper
>  - unsafe putByte
>  - remove digitPair
>  - fix import
>  - remove JLA
>  - remove unused code
>  - add comments
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/303de364...73b32004

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 136:

> 134: 
> 135:     // Used by trusted callers.  Assumes all necessary bounds checks have
> 136:     // been done by the caller.

We have comment in the method already, don't need this one

src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 415:

> 413:         int packed = DIGITS[v];
> 414:         putCharLatin1(buf, charPos, packed & 0xFF);
> 415:         putCharLatin1(buf, charPos + 1, packed >> 8);

Does merge store work here?  Original code in StringLatin1 uses direct array writes, not sure about this version.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21593#discussion_r1830284792
PR Review Comment: https://git.openjdk.org/jdk/pull/21593#discussion_r1830286715

From jwaters at openjdk.org  Wed Nov  6 04:43:42 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Wed, 6 Nov 2024 04:43:42 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
Message-ID: <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>

On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458712195

From dholmes at openjdk.org  Wed Nov  6 04:55:34 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 04:55:34 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v8]
In-Reply-To: <uJ8sP7dcSh5vkCh1naSFQgB9bY_cBLY7aqign9YyhAQ=.7e7725d1-ec2c-4dc0-aa31-e9388888dae8@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
 <ElrA4frQ4YdtXcbkdkkOadEZMEuQz-GuLit9tqFc7vM=.7416712c-e42f-4fc5-90d8-9e6fe3667b8e@github.com>
 <uJ8sP7dcSh5vkCh1naSFQgB9bY_cBLY7aqign9YyhAQ=.7e7725d1-ec2c-4dc0-aa31-e9388888dae8@github.com>
Message-ID: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com>

On Tue, 5 Nov 2024 01:10:37 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention.

As an acronym I think AOT in capitals should be preferred even in function/variable names. 

> In logging, I've been using "aot" as logging seems to favor lowercase.

Yes log tags seem to be always lower-case, by convention.

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

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2458722622

From swen at openjdk.org  Wed Nov  6 05:16:50 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Nov 2024 05:16:50 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v3]
In-Reply-To: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
Message-ID: <YcglLhlvLNbwCsWPbM0p-0ClhI_9tyMn-HPPROWkMzM=.691bd1bd-575f-44bf-9290-36da56701818@github.com>

> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
> 
> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
> 3. Eliminate duplicate code in BigDecimal

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  remove comments, from @liach

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21593/files
  - new: https://git.openjdk.org/jdk/pull/21593/files/73b32004..e97138db

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

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

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

From swen at openjdk.org  Wed Nov  6 05:16:56 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 6 Nov 2024 05:16:56 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v2]
In-Reply-To: <cXBGAQwawEKZc_Hjn5L5qXz7I0lH3BorjLVqqrEQtLo=.d66ff05f-ac30-4408-8a48-851a644ecd83@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <DPd3cEy9NeRFgO3diWAiIWU6GQV7tMrGElJjwVsA8jI=.2fc1e645-c6ee-4199-8ed7-6f44a063990b@github.com>
 <cXBGAQwawEKZc_Hjn5L5qXz7I0lH3BorjLVqqrEQtLo=.d66ff05f-ac30-4408-8a48-851a644ecd83@github.com>
Message-ID: <hcWC0tdqaCPfB8Bf1VqZc5F0SdBjhZtr78c4_Mln8ao=.27802ad4-c85f-4484-9493-2a12c55eb963@github.com>

On Wed, 6 Nov 2024 01:44:38 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410
>>  - fix Helper
>>  - fix Helper
>>  - fix Helper
>>  - unsafe putByte
>>  - remove digitPair
>>  - fix import
>>  - remove JLA
>>  - remove unused code
>>  - add comments
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/1355efc1...73b32004
>
> src/java.base/share/classes/jdk/internal/util/DecimalDigits.java line 415:
> 
>> 413:         int packed = DIGITS[v];
>> 414:         putCharLatin1(buf, charPos, packed & 0xFF);
>> 415:         putCharLatin1(buf, charPos + 1, packed >> 8);
> 
> Does merge store work here?  Original code in StringLatin1 uses direct array writes, not sure about this version.

Tests show that the current version of MergeStore also works


[TraceMergeStores] found:
    0-->  114  StoreB  === 80 91 113 95  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: DecimalDigits::putCharLatin1 @ bci:12 (line 430) DecimalDigits::putPairLatin1 @ bci:24 (line 413)
    1-->   91  StoreB  === 80 7 90 51  [[ 114 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: DecimalDigits::putCharLatin1 @ bci:12 (line 430) DecimalDigits::putPairLatin1 @ bci:13 (line 412)
[TraceMergeStores] truncated:
    0-->  114  StoreB  === 80 91 113 95  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: DecimalDigits::putCharLatin1 @ bci:12 (line 430) DecimalDigits::putPairLatin1 @ bci:24 (line 413)
    1-->   91  StoreB  === 80 7 90 51  [[ 114 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: DecimalDigits::putCharLatin1 @ bci:12 (line 430) DecimalDigits::putPairLatin1 @ bci:13 (line 412)
[TraceMergeStores]: Replace
  91  StoreB  === 80 7 90 51  [[ 114 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: DecimalDigits::putCharLatin1 @ bci:12 (line 430) DecimalDigits::putPairLatin1 @ bci:13 (line 412)
 114  StoreB  === 80 91 113 95  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=5; unsafe  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !jvms: DecimalDigits::putCharLatin1 @ bci:12 (line 430) DecimalDigits::putPairLatin1 @ bci:24 (line 413)
[TraceMergeStores]: with
  51  LoadS  === 33 7 49  [[ 91 85 95 70 118 ]]  @short[int:>=0] (java/lang/Cloneable,java/io/Serializable):exact+any *, idx=4; #short !jvms: DecimalDigits::putPairLatin1 @ bci:4 (line 411)
 118  StoreC  === 80 7 90 51  [[ ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5;
[TraceMergeStores] MergePrimitiveStores::run:  118  StoreC  === 80 7 90 51  [[ 18 ]]  @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; mismatched  Memory: @byte[int:>=0] (java/lang/Cloneable,java/io/Serializable):NotNull:exact+any *, idx=5; !orig=[114] !jvms: DecimalDigits::putCharLatin1 @ bci:12 (line 430) DecimalDigits::putPairLatin1 @ bci:24 (line 413)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21593#discussion_r1830398810

From dholmes at openjdk.org  Wed Nov  6 05:32:53 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 05:32:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v32]
In-Reply-To: <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
Message-ID: <FQ_XTZ1NAU6pE5K9IzwtAJ2irQjr-Tu46z6xt-POjQk=.41c27641-2a45-4915-ac36-519a3abc3243@github.com>

On Wed, 6 Nov 2024 00:08:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()

Marked as reviewed by dholmes (Reviewer).

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456

From dholmes at openjdk.org  Wed Nov  6 05:55:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 05:55:47 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
Message-ID: <91oCFKrjKmyjkaT3dBRRcpao4NNde2DXg39vjvBn7Wk=.893ab420-92f3-4bda-8744-4a801a07f95c@github.com>

On Wed, 6 Nov 2024 01:44:48 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> On ARM and x64 processors, __stdcall is accepted and ignored by the compiler;

@alexmenkov and @TheShermanTanker , I stand corrected and my apologies to @magicus .

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2458778303

From aboldtch at openjdk.org  Wed Nov  6 06:39:55 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 06:39:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v32]
In-Reply-To: <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <OtROYGY1pi3wwxedxOBKpZTizCn-ioDNmiO86bQNRz0=.906a52ac-1602-4b2f-b89a-461318c7d7b9@github.com>
Message-ID: <k2pGIDqjtzechkzb2pm4a71NnFPihIonlD7mh5ySWIs=.53c0b7fb-da75-4bdd-a875-4abccc3e1992@github.com>

On Wed, 6 Nov 2024 00:08:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()

Good work! I'll approve the GC related changes.

There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.

Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.

A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.

// the sp of the oldest known interpreted/call_stub frame inside the
// continuation that we know about

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

Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171

From iklam at openjdk.org  Wed Nov  6 06:48:33 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 6 Nov 2024 06:48:33 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v8]
In-Reply-To: <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
 <ElrA4frQ4YdtXcbkdkkOadEZMEuQz-GuLit9tqFc7vM=.7416712c-e42f-4fc5-90d8-9e6fe3667b8e@github.com>
 <uJ8sP7dcSh5vkCh1naSFQgB9bY_cBLY7aqign9YyhAQ=.7e7725d1-ec2c-4dc0-aa31-e9388888dae8@github.com>
 <1KCOK7hSTz6122-AErD-x4tjyCx7xvdymzVHlLOpO-4=.8e39cde5-969d-4ee0-9af0-262c1844a1e9@github.com>
Message-ID: <Tr0uv81ZdCvyP3v8t7xtY1WE2oc9vbhWBA9Xzb5jFAw=.eb43e03c-3a3d-4f49-b757-0f11a13bee76@github.com>

On Wed, 6 Nov 2024 04:52:56 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > I've been using AOT in class names and aot in function/variable names. I think that's consistent with HotSpot convention.
> 
> As an acronym I think AOT in capitals should be preferred even in function/variable names.

I searched for "GC" vs "gc" and "JVMTI" vs "jvmti" in function names. Almost all of them are in lower cases.

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

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2458836253

From mbaesken at openjdk.org  Wed Nov  6 07:54:28 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Nov 2024 07:54:28 GMT
Subject: RFR: 8343610: InOutPathTest jpackage test produces invalid app
 image on macOS
In-Reply-To: <cQ50VjDjK-9ch-aPo0iQ_ddbqhg0xYxNDtC39fmgCrM=.d5d92d22-a32e-4f01-9436-59c76ca6ba30@github.com>
References: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
 <cQ50VjDjK-9ch-aPo0iQ_ddbqhg0xYxNDtC39fmgCrM=.d5d92d22-a32e-4f01-9436-59c76ca6ba30@github.com>
Message-ID: <BEHr8yv3ziw97zj4n97Fl0zKAQVPqne9QixA9KXDZ-A=.bb319752-1014-4d47-8b72-721ab5aa6973@github.com>

On Tue, 5 Nov 2024 22:42:13 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> can you try this fix in your environment?

Sure, I added the patch to our build/test queue .

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

PR Comment: https://git.openjdk.org/jdk/pull/21909#issuecomment-2458923465

From alanb at openjdk.org  Wed Nov  6 08:05:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 08:05:36 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <ZFOO5n1jTQ28-cpz5qoTZOEnnXjKM9otE4KMeiX2S50=.9bd63cf6-5ff0-487f-94b9-19e5f782428f@github.com>

On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 2:

> 1: /*
> 2:  * Copyright (c) 2016, 2023, Oracle and/or its affiliates. All rights reserved.

I assume you didn't mean to change that.

src/jdk.jfr/share/conf/jfr/profile.jfc line 741:

> 739:       <setting name="stackTrace">true</setting>
> 740:       <setting name="threshold" control="socket-threshold">10 ms</setting>
> 741:     </event>

In default.jfr the threshold for the socket events is 20ms, but 10ms in profile.jfc. Is that intentional?

test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 106:

> 104: 
> 105:                 try (SocketChannel sc = SocketChannel.open(ssc.getLocalAddress())) {
> 106:                     addExpectedEvent(IOEvent.createSocketConnectEvent(sc.socket()));

This is SocketChannel in blocking mode where the connect succeeds. There is also the non-blocking and where connect fails. In addition the connection can established with the socket adaptor. So 6 possible cases for SocketChannel if the test is expanded.

test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 108:

> 106:                 try (Socket s = new Socket()) {
> 107:                     s.connect(ss.getLocalSocketAddress());
> 108:                     addExpectedEvent(IOEvent.createSocketConnectEvent(s));

This is Socket.connect success case, I assume we'll need a test for fail case too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830512546
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830516492
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830545551
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1830537634

From pminborg at openjdk.org  Wed Nov  6 08:07:33 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Nov 2024 08:07:33 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <CsLdH47WoNKervXaAPvv7_MU_wZF3ytTbKRI8Ng9liQ=.e21a403a-e875-4d25-ae16-ef2a8b07de0f@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
 <CsLdH47WoNKervXaAPvv7_MU_wZF3ytTbKRI8Ng9liQ=.e21a403a-e875-4d25-ae16-ef2a8b07de0f@github.com>
Message-ID: <XMdcK40OIOYC3cZaUkAJtII9iITqMZAnPar-gltOgdg=.70116aa9-6bc1-469f-89a5-691bd0c29907@github.com>

On Tue, 5 Nov 2024 18:48:07 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - copyright year
>>  - address reviews
>
> Thanks a lot for your reviews and suggestions, I will merge this patch.

Thanks for your contribution @merykitty ! I am already curious if you can find additional improvements!

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

PR Comment: https://git.openjdk.org/jdk/pull/21810#issuecomment-2458945551

From alanb at openjdk.org  Wed Nov  6 08:10:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 08:10:31 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <xqNMNjbZtes0NQ0qvL2GBBwQhPb0MX_ePQkLwltaEsw=.a6945963-6b0f-431a-ad5b-33dcc51265eb@github.com>

On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

The update in ce9d39e2 has the changes that I discussed with Tim yesterday. Specifically, it fixes several issues with the non-blocking case, only records an event if the connect method actually attempts to establish a connection, and fixes the socket adaptor. So I think this to NioSocketImpl and SocketChannelImpl are good now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2458949631

From duke at openjdk.org  Wed Nov  6 08:11:33 2024
From: duke at openjdk.org (mjschwaiger)
Date: Wed, 6 Nov 2024 08:11:33 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <o2yX16JXsezlSbrp3cYK-8Rs7zAe5zWUex8oviqlB0s=.19169a03-2814-4ff3-b5aa-615d00646e13@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
 <o2yX16JXsezlSbrp3cYK-8Rs7zAe5zWUex8oviqlB0s=.19169a03-2814-4ff3-b5aa-615d00646e13@github.com>
Message-ID: <yWaVX_sQ8KzeFan8q1c6r41UBGZl3HVEhK5sqJlcTWw=.166984a0-3f50-4a43-8ffb-2ad477f3f73d@github.com>

On Mon, 23 Sep 2024 06:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Windows Server 2025 will be releases in a few months.
>> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
>> (currently Windows server 2022 is printed , that is wrong)
>> 
>> The build numbers of some recent previews documented here
>> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
>> are 26080 and 26085 (final release version will most likely be a bit higher).
>
> Thanks for the reviews !

@MBaesken Is this issue going to be backported to jdk17 (and jdk8) as well?

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

PR Comment: https://git.openjdk.org/jdk/pull/21082#issuecomment-2458952099

From mbaesken at openjdk.org  Wed Nov  6 08:35:33 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Nov 2024 08:35:33 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <o2yX16JXsezlSbrp3cYK-8Rs7zAe5zWUex8oviqlB0s=.19169a03-2814-4ff3-b5aa-615d00646e13@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
 <o2yX16JXsezlSbrp3cYK-8Rs7zAe5zWUex8oviqlB0s=.19169a03-2814-4ff3-b5aa-615d00646e13@github.com>
Message-ID: <aYwA_V-yobnfuJ4iJvam51RWj4mgQmgdRXzqDOwXCQM=.f7ac288f-22aa-4ad0-badd-6e8135faaac0@github.com>

On Mon, 23 Sep 2024 06:38:45 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> Windows Server 2025 will be releases in a few months.
>> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
>> (currently Windows server 2022 is printed , that is wrong)
>> 
>> The build numbers of some recent previews documented here
>> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
>> are 26080 and 26085 (final release version will most likely be a bit higher).
>
> Thanks for the reviews !

> @MBaesken Is this issue going to be backported to jdk17 (and jdk8) as well?

Thanks for the reminder, I just started a backport to jdk17u-dev. Regarding jdk8 I don't know, no backport from me but maybe some jdk8 maintainers will do it.

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

PR Comment: https://git.openjdk.org/jdk/pull/21082#issuecomment-2458997046

From stuefe at openjdk.org  Wed Nov  6 09:15:11 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Nov 2024 09:15:11 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
 <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>
Message-ID: <pK8vKaEeCpoHunxUWPmsGsyZ2BRlPMuQfHvq0lswsWM=.bf4f7bb0-0e98-42b9-b446-4b9d5d84bede@github.com>

On Wed, 6 Nov 2024 04:40:24 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!

stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention.

I am sure __stdcall is ignored by the compiler on x64 or arm64.

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459078526

From stuefe at openjdk.org  Wed Nov  6 09:15:12 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Wed, 6 Nov 2024 09:15:12 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <pK8vKaEeCpoHunxUWPmsGsyZ2BRlPMuQfHvq0lswsWM=.bf4f7bb0-0e98-42b9-b446-4b9d5d84bede@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <nBU9ue3qDRZRxScmNmnifaru36PZ-STSJwHocUO_KNk=.07dda1ed-384b-496a-b94b-6ce7c0a02f8a@github.com>
 <iKe3YslSTrnOODL9j5aOr9BS7pj57VjRswtuOIUnbqs=.24500a46-d92b-4c15-aac6-8ffd978d0614@github.com>
 <pK8vKaEeCpoHunxUWPmsGsyZ2BRlPMuQfHvq0lswsWM=.bf4f7bb0-0e98-42b9-b446-4b9d5d84bede@github.com>
Message-ID: <wRLgGr7tu6TxChDieo2Mc6HWK51JC-Hjr6eBYCUPqAU=.7d627968-161a-4ce8-98be-8dc2a329868d@github.com>

On Wed, 6 Nov 2024 09:12:02 GMT, Thomas Stuefe <stuefe at openjdk.org> wrote:

> > I think you may be throwing the baby out with the bath water when it comes to `__stdcall`. It may be that 32-bit requires `__stdcall` but I don't see anything that states `__stdcall` is ONLY for 32-bit!
> 
> stdcall and cdecl are 32-bit Windows calling conventions. On x64 and arm64, as on all other platforms we support, there is just one calling convention. See https://en.wikipedia.org/wiki/X86_calling_conventions#Microsoft_x64_calling_convention.
> 
> I am sure __stdcall is ignored by the compiler on x64 or arm64.

Never mind my noise, other people did already answer this :-)

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

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2459080708

From daniel.peintner at gmail.com  Wed Nov  6 09:19:42 2024
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Wed, 6 Nov 2024 10:19:42 +0100
Subject: [jpackage] Changes to icon handling between Java 17 and Java 21 on
 Windows
Message-ID: <CAAoP7T6SPwhxKUxsFG91Of5hWdBugTw9uJzev1DoM-s1MbKSRA@mail.gmail.com>

Hello,

I am not sure if this is the right place to ask, but I hope so.
If not please let me know where I can report this kind of problem.

Recently we changed from JDK 17 to JDK 21 and something seems to have
changed when running jpackage with --icon option.

Produced structure on Windows for

# Java 17
/app
/runtime
foo.exe
foo.ico

while for

# Java 21 (v 21.0.5)
/app
/runtime
foo.exe

As you can see the foo.ico is missing.
Note: the foo.exe still shows the right icon when looking at it in
FileExplorer.

Anyhow, on some devices the missing ico file is causing issues.
There is no icon on the program list nor in the taskbar (see attached
images).

Note: On some windows installations it works without issues.

Is this a known problem? I tried to browse through https://bugs.openjdk.org
without finding such a bug report.

Thanks for any input/advice.

-- Daniel
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241106/d00f37cd/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: program-list.png
Type: image/png
Size: 18415 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241106/d00f37cd/program-list-0001.png>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: taskbar.png
Type: image/png
Size: 23450 bytes
Desc: not available
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241106/d00f37cd/taskbar-0001.png>

From alanb at openjdk.org  Wed Nov  6 09:26:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 09:26:55 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
 <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
 <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>
Message-ID: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1789ddda-b40d-4427-a0c1-8161504c0768@github.com>

On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>>  Is this posted after the VirtualThreadMount extension event posted?
>>>
>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620
>
>> The JvmtiExport::post_monitor_waited() is called at the line 1801.
>> Does it post the MonitorWaited event for this virtual thread as well?
>>
> That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

Just to add that the 2 extension events (VirtualThreadMount and  VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204

From sgehwolf at openjdk.org  Wed Nov  6 11:24:23 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 6 Nov 2024 11:24:23 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v45]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits:

 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Make capability in --help human readable
 - Fix comment
 - Fix SystemModulesTest2 when linkable runtime but no packaged modules
 - Rename PackagedModulesVsJmodLessTest => PackagedModulesVsRuntimeImageLinkTest
 - Rename JmodLess => runtimeImage
 - Refactor tests so that they run for default build
   
   When a default JDK build is being produced, the tests create a run-time
   image capable JDK as an interim step before everything else is being
   verified.
   
   For a build that has the run-time image link capability already turned
   on, this extra step is being omitted.
 - Mandy's feedback
 - Merge branch 'master' into jdk-8311302-jmodless-link
 - Some test fixes
 - ... and 170 more: https://git.openjdk.org/jdk/compare/83f3d42d...e83b9584

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

Changes: https://git.openjdk.org/jdk/pull/14787/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=44
  Stats: 4648 lines in 47 files changed: 4410 ins; 134 del; 104 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

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

From sgehwolf at openjdk.org  Wed Nov  6 11:24:24 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 6 Nov 2024 11:24:24 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v40]
In-Reply-To: <mJTtR5XCSDsnEJ6nwpWQSSzJc6OV9C7XsqRDjq6R2sM=.d95f5a7d-96e2-488b-8784-297b1a7e93b5@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <dzvJywrIZpOXOPMf8qqB4yBEdjZCQrVMStCpvvY7d3A=.94956783-7874-4dfd-a449-c6d379620af2@github.com>
 <KZP1m6p2Y3tAiSbpXcK-TRO7fL9Oegq2pg6WMoNAUxk=.70dcbe9f-1682-4f67-8f7c-4bc79d8158b8@github.com>
 <Q1KN8YsZRb1YlcnYfRetYBoutIHAqSD4fGg1wFZpyEU=.a7be37d6-3589-4657-9c27-1ba8284192de@github.com>
 <nLafZx6UtWkuVSf3CNi_vi0AWRpGsy4LLqS8fwpJt4E=.3d64536a-8d44-4074-8577-fb527888c9f1@github.com>
 <mJTtR5XCSDsnEJ6nwpWQSSzJc6OV9C7XsqRDjq6R2sM=.d95f5a7d-96e2-488b-8784-297b1a7e93b5@github.com>
Message-ID: <OYnjhX0id-zjpLAWH8p_4z8XJhSwaL5KiJculcpHg3E=.a5d2981c-42d9-4e46-b6bc-e795832a010c@github.com>

On Mon, 4 Nov 2024 10:35:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> OK. I would prefer:
> 
> ```
> Capabilities:
>     Linking from run-time image enabled
> ```
> 
> ... as it would be more in-line with other wording of the feature.

I've implemented this now and will update the JEP and the JSR accordingly.

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2459482416

From dl at openjdk.org  Wed Nov  6 11:47:55 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 6 Nov 2024 11:47:55 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v18]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <73KmIzD1nMZe8F-HvWjaKdzGD6BE2J-0vjSky7Ij77w=.287c77a9-c663-42d1-8d26-38a8a78f7ed7@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

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

 - Merge branch 'openjdk:master' into JDK-8336707
 - More shutdown streamlining
 - Don't report termination while cancellations in progress
 - Reduce read contention
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reduce shutdown overhead and contention
 - dropWaiters now back to releaseAll
 - Merge branch 'openjdk:master' into JDK-8336707
 - reduce shutdown overhead
 - For starvation check #7
 - ... and 26 more: https://git.openjdk.org/jdk/compare/340f0ba8...f657543b

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/7b86aac4..f657543b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=16-17

  Stats: 128924 lines in 665 files changed: 102232 ins; 9181 del; 17511 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

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

From duke at openjdk.org  Wed Nov  6 11:48:36 2024
From: duke at openjdk.org (mjschwaiger)
Date: Wed, 6 Nov 2024 11:48:36 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
Message-ID: <RB2kgd9nf5ftPE24jbK2LKYsjpK7MM8VFuthiniri5Y=.8112b06e-b9e6-4953-abd8-00ae70ca8642@github.com>

On Thu, 19 Sep 2024 07:40:43 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Windows Server 2025 will be releases in a few months.
> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
> (currently Windows server 2022 is printed , that is wrong)
> 
> The build numbers of some recent previews documented here
> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
> are 26080 and 26085 (final release version will most likely be a bit higher).

src/hotspot/os/windows/os_windows.cpp line 1950:

> 1948:       // - 2019 GA 11/2018 build: 17763
> 1949:       // - 2022 GA 08/2021 build: 20348
> 1950:       // - 2025 Preview build   : 26040

Just for the record, Microsoft released Windows Server 2025 on Nov 1st, 2025 and the official build number is 26100.

// - 2025 GA 11/2024 build: 26100
if (build_number > 26099) {
  st->print("Server 2025");

Reference: https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21082#discussion_r1830880925

From duke at openjdk.org  Wed Nov  6 11:54:31 2024
From: duke at openjdk.org (mjschwaiger)
Date: Wed, 6 Nov 2024 11:54:31 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <aYwA_V-yobnfuJ4iJvam51RWj4mgQmgdRXzqDOwXCQM=.f7ac288f-22aa-4ad0-badd-6e8135faaac0@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
 <o2yX16JXsezlSbrp3cYK-8Rs7zAe5zWUex8oviqlB0s=.19169a03-2814-4ff3-b5aa-615d00646e13@github.com>
 <aYwA_V-yobnfuJ4iJvam51RWj4mgQmgdRXzqDOwXCQM=.f7ac288f-22aa-4ad0-badd-6e8135faaac0@github.com>
Message-ID: <wwA1yMY8_yVYqhKDzxR31eEgVXQNts9edV91th-9d3w=.33878f51-0a7d-47a6-b975-a77033c9c411@github.com>

On Wed, 6 Nov 2024 08:33:12 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> > @MBaesken Is this issue going to be backported to jdk17 (and jdk8) as well?
> 
> Thanks for the reminder, I just started a backport to jdk17u-dev. Regarding jdk8 I don't know, no backport from me but maybe some jdk8 maintainers will do it.

Thank you for responding and resolving this quickly.

And as noted above, Windows Server 2025 (build 26100) was released last week.

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

PR Comment: https://git.openjdk.org/jdk/pull/21082#issuecomment-2459545003

From mbaesken at openjdk.org  Wed Nov  6 11:54:32 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Wed, 6 Nov 2024 11:54:32 GMT
Subject: RFR: 8340387: Update OS detection code to recognize Windows Server
 2025
In-Reply-To: <RB2kgd9nf5ftPE24jbK2LKYsjpK7MM8VFuthiniri5Y=.8112b06e-b9e6-4953-abd8-00ae70ca8642@github.com>
References: <qmaJRl86w1eASe0eyCSTlYFS0a04B0VGs-Aqu00Wpqw=.3a6cff58-087f-4557-9dfd-90faeffe7de1@github.com>
 <RB2kgd9nf5ftPE24jbK2LKYsjpK7MM8VFuthiniri5Y=.8112b06e-b9e6-4953-abd8-00ae70ca8642@github.com>
Message-ID: <S0h3CS6wRBdPEFlMZoQSrt4iTJNwj49CML46d8Ss6dA=.1583c77f-488a-4604-b6f9-5db05958bf88@github.com>

On Wed, 6 Nov 2024 11:45:23 GMT, mjschwaiger <duke at openjdk.org> wrote:

>> Windows Server 2025 will be releases in a few months.
>> The OS detection code of the JVM/JDK should recognize the new Windows server 2025 version.
>> (currently Windows server 2022 is printed , that is wrong)
>> 
>> The build numbers of some recent previews documented here
>> https://learn.microsoft.com/en-us/windows-server/get-started/whats-new-windows-server-2025
>> are 26080 and 26085 (final release version will most likely be a bit higher).
>
> src/hotspot/os/windows/os_windows.cpp line 1950:
> 
>> 1948:       // - 2019 GA 11/2018 build: 17763
>> 1949:       // - 2022 GA 08/2021 build: 20348
>> 1950:       // - 2025 Preview build   : 26040
> 
> Just for the record, Microsoft released Windows Server 2025 on Nov 1st, 2025 and the official build number is 26100.
> 
> // - 2025 GA 11/2024 build: 26100
> if (build_number > 26099) {
>   st->print("Server 2025");
> 
> Reference: https://learn.microsoft.com/en-us/windows-server/get-started/windows-server-release-info

Thanks this is what I got this week too from our Microsoft experts.
I added the info to this JBS bug 8340387.
With the the check present, we detect also some previews which is not bad imho.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21082#discussion_r1830888321

From pkoppula at openjdk.org  Wed Nov  6 12:03:56 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 6 Nov 2024 12:03:56 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v9]
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <Oyz2VnEyiPMEx8inZTUalDGMIXn9PHN7KP_lB6FXa1s=.e058d113-f858-44ae-b04c-2d2516578de3@github.com>

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  Replaced Paths.get with Path.of

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/24c3f476..8648125b

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

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

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

From pminborg at openjdk.org  Wed Nov  6 14:18:50 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Nov 2024 14:18:50 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v13]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <e5AoQnwnl2vLztV4xKNjhSxusEDjOk7cCb_4RwVdVk4=.003bb6ac-f1eb-40ed-a25c-dae005cbc727@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

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

 - Simplify exception testing
 - Merge branch 'master' into linker-padding-layout-only
 - Remove redundant check
 - Rephrase doc
 - Improve language
 - Add checks of exception messages
 - Update test/jdk/java/foreign/TestLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - ... and 20 more: https://git.openjdk.org/jdk/compare/7728503f...6a97fe5d

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/0c134821..6a97fe5d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=11-12

  Stats: 126278 lines in 574 files changed: 100610 ins; 8624 del; 17044 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

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

From coffeys at openjdk.org  Wed Nov  6 14:29:31 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Wed, 6 Nov 2024 14:29:31 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v9]
In-Reply-To: <Oyz2VnEyiPMEx8inZTUalDGMIXn9PHN7KP_lB6FXa1s=.e058d113-f858-44ae-b04c-2d2516578de3@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <Oyz2VnEyiPMEx8inZTUalDGMIXn9PHN7KP_lB6FXa1s=.e058d113-f858-44ae-b04c-2d2516578de3@github.com>
Message-ID: <4RUG7fJhlj6bGn0lG6KisaeKTCYR528mUHIpvLA7mmo=.2c019424-b526-4934-a143-6d990cb37a89@github.com>

On Wed, 6 Nov 2024 12:03:56 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.
>
> Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Replaced Paths.get with Path.of

This looks good to me. 

I'd suggest logging a new JBS issue to track removal of the Debug.getInstance("pkcs12") use case and substituting it with getInstance("keystore") code (esp. since pkcs12 is now the default keystore type)

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

Marked as reviewed by coffeys (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20414#pullrequestreview-2418430330

From szaldana at openjdk.org  Wed Nov  6 14:39:41 2024
From: szaldana at openjdk.org (Sonia Zaldana Calles)
Date: Wed, 6 Nov 2024 14:39:41 GMT
Subject: RFR: 8339890: javax/script/ProviderTest.sh ignore vm flags
Message-ID: <Ws8NuvfC3c5-hwXubosGIHIFAxtthz_Fq_DFc7zcGq4=.c790b5b8-d48c-4a1d-9c1a-82d35aea87d3@github.com>

Hi all, 

This PR addresses [8339890](https://bugs.openjdk.org/browse/JDK-8339890) where vm flags specified via javaopts were getting ignored. I added the flags to the test. 

Thanks, 
Sonia

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

Commit messages:
 - 8339890: javax/script/ProviderTest.sh ignore vm flags

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

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

From pminborg at openjdk.org  Wed Nov  6 14:56:46 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 6 Nov 2024 14:56:46 GMT
Subject: RFR: 8334107: Specification for MemorySegment::get/setString could use
 some clarification
Message-ID: <U-YFiGau2bynPVoOpPTB6SMseinf264wWJ_wxlEPQkE=.d1489660-3db0-4d00-8c1a-ad244fd1f67a@github.com>

This PR proposes to add additional text for the `@param charset` tags in the `MemorySegment.(get|set)String` overloads that take a `charset`. 

This PR does not need a CSR, as the specs already state that an exception will be thrown if the provided `charset` is not a standard charset.

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

Commit messages:
 - Add param text to string operations in MemorySegment

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

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

From duke at openjdk.org  Wed Nov  6 15:00:54 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 6 Nov 2024 15:00:54 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg
Message-ID: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>

This change optimizes the runtime of `Class.getMethod(String, Class<?>[])` in two ways:

1. While iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name.  This check is substantially faster.
2. While iterating (existing logic) if the requested method has no arguments, the loop terminates early after finding one match.  This works because there can only be one zero-arg method with the matching name in the specific class.

A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target.

Base:

Benchmark                          Mode  Cnt     Score    Error  Units
ClassGetMethod.getConcreteFiveArg  avgt    6    90.866 ?  2.698  ns/op
ClassGetMethod.getConcreteNoArg    avgt    6    72.472 ? 10.225  ns/op
ClassGetMethod.getIntfFiveArg      avgt    6   198.524 ?  7.089  ns/op
ClassGetMethod.getIntfNoArg        avgt    6   191.739 ?  4.695  ns/op
ClassGetMethod.getNoSuchMethod     avgt   10  2254.308 ? 42.829  ns/op
ClassGetMethod.getSuperFiveArg     avgt    6   165.897 ?  4.370  ns/op
ClassGetMethod.getSuperNoArg       avgt    6   148.361 ?  4.573  ns/op


Modified:

Benchmark                          Mode  Cnt     Score    Error  Units
ClassGetMethod.getConcreteFiveArg  avgt    6    77.059 ?  2.644  ns/op
ClassGetMethod.getConcreteNoArg    avgt    6    47.666 ?  6.544  ns/op
ClassGetMethod.getIntfFiveArg      avgt    6   164.427 ?  4.356  ns/op
ClassGetMethod.getIntfNoArg        avgt    6   161.256 ?  6.832  ns/op
ClassGetMethod.getNoSuchMethod     avgt   10  2158.844 ? 43.716  ns/op
ClassGetMethod.getSuperFiveArg     avgt    6   129.047 ?  4.414  ns/op
ClassGetMethod.getSuperNoArg       avgt    6   123.728 ?  6.182  ns/op

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

Commit messages:
 - Adding copyright statements
 - 8343559: Optimize Class.getMethod(String, Class<?>...)

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

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

From pkoppula at openjdk.org  Wed Nov  6 15:02:29 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Wed, 6 Nov 2024 15:02:29 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v10]
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <cru_CeFPY4IspAUftrW8Ws6v4UnrjZjr35YKa5JWwhE=.37819b2e-560e-4158-b672-e0d0c04e5117@github.com>

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

Prasadrao Koppula has updated the pull request incrementally with one additional commit since the last revision:

  initialized storeName with empty string

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/20414/files
  - new: https://git.openjdk.org/jdk/pull/20414/files/8648125b..7b4760a6

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

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

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

From jvernee at openjdk.org  Wed Nov  6 15:07:38 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Nov 2024 15:07:38 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v13]
In-Reply-To: <e5AoQnwnl2vLztV4xKNjhSxusEDjOk7cCb_4RwVdVk4=.003bb6ac-f1eb-40ed-a25c-dae005cbc727@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <e5AoQnwnl2vLztV4xKNjhSxusEDjOk7cCb_4RwVdVk4=.003bb6ac-f1eb-40ed-a25c-dae005cbc727@github.com>
Message-ID: <LawuEa23JaOsGyhzvMd2OBz8CsLM9svCKcIRvPANiMk=.3f16cca7-2188-4cd5-8045-fdd19f5fb965@github.com>

On Wed, 6 Nov 2024 14:18:50 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 30 additional commits since the last revision:
> 
>  - Simplify exception testing
>  - Merge branch 'master' into linker-padding-layout-only
>  - Remove redundant check
>  - Rephrase doc
>  - Improve language
>  - Add checks of exception messages
>  - Update test/jdk/java/foreign/TestLinker.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - ... and 20 more: https://git.openjdk.org/jdk/compare/3c99454c...6a97fe5d

I think some of the code could be simplified further, left some inline comments.

I also noticed that some cases involving unions are not handled as expected. For example:


MemoryLayout.unionLayout(MemoryLayout.paddingLayout(4), ValueLayout.JAVA_INT);
MemoryLayout.unionLayout(MemoryLayout.paddingLayout(2), ValueLayout.JAVA_INT);


Are both accepted, but I don't think they should be (they contains superfluous padding after all).

For the case:


MemoryLayout.unionLayout(MemoryLayout.paddingLayout(5), ValueLayout.JAVA_INT):


The exception message is: `The padding layout x5 is not of minimum size to align i4(with byte alignment 4) in [x5|i4]`, which is also a bit surprising, since in the case of unions, paddings are not used to align members, but only the union itself.

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 242:

> 240:                 }
> 241:             }
> 242:         }

We are already looping over the members in `checkLayoutRecursive` I suggest adding to that loop instead of adding another one here.

Alignment of members is already handled by `checkMemberOffset` (the new loop also checks union members, which seems incorrect), so the only new thing that is needed from here is the check for consecutive padding layouts. It should be possible to handle that by keeping track of the previous layout, and then checking against the previous layout when we encounter a padding layout, inside the loop in `checkLayoutRecursive`.

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 247:

> 245:                 gl.memberLayouts().getLast() instanceof PaddingLayout pl) {
> 246:             assertIsAlignedBy(null, 0, pl, gl);
> 247:         }

This was already being checked by the existing size check (currently at the end of this method). I don't think we need both checks?

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 259:

> 257:     }
> 258: 
> 259:     private static void assertIsAlignedBy(GroupLayout gl, long index, PaddingLayout padding, MemoryLayout element) {

`index` is not used here.

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

PR Review: https://git.openjdk.org/jdk/pull/21041#pullrequestreview-2418470626
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1831144411
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1831137080
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1831155055

From ihse at openjdk.org  Wed Nov  6 15:21:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Nov 2024 15:21:10 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove FIXME

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/9b10e74c..de3c773a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=30
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=29-30

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

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

From ihse at openjdk.org  Wed Nov  6 15:21:10 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Nov 2024 15:21:10 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
Message-ID: <1C4ITw6Oql1qCggf80rAZ73NIjGNwdYQzWHUfb_8LLE=.0140fca3-d921-4ec3-bd82-1f9cf7bb0a31@github.com>

On Tue, 5 Nov 2024 16:28:04 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_windows.cpp line 5820:
> 
>> 5818: }
>> 5819: 
>> 5820: // FIXME
> 
> ???

I apologize this slipped through. It was a marker for myself which I added when searching for code that did _stdcall name mangling operations.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831227000

From badalov.turxan at gmail.com  Wed Nov  6 15:22:11 2024
From: badalov.turxan at gmail.com (Turkhan Badalov)
Date: Wed, 6 Nov 2024 19:22:11 +0400
Subject: Should the documentation state peekFirst() as equivalent to
 Stack's peek()?
In-Reply-To: <CH3PR10MB76776DB1E0785202759C910BA2AB2@CH3PR10MB7677.namprd10.prod.outlook.com>
References: <CACQZjSOmYz0mBpi1PYbPVuS5HpSrvcK7CyDyB4iHdmF_aM46uw@mail.gmail.com>
 <CH3PR10MB76776DB1E0785202759C910BA2AB2@CH3PR10MB7677.namprd10.prod.outlook.com>
Message-ID: <CACQZjSNcWi5KH9x6wpZNkWkN+U+gWTvtWwgmhzy2J6dR-yYMhg@mail.gmail.com>

Hi!

After this commit
https://github.com/openjdk/jdk/commit/1846a65e32624f6da691c1072f44fcb762b43233#diff-f7198d7dbc99fe4e161d39db820508c743fe03ecf004085625ab241255c98e76L164,
I was expecting the docs to get updated with the release of Java 23.

However, the typo is still there:
https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Deque.html

Wondering when is the change supposed to take effect or does it mean the
fix is not complete?

Regards,
Turkhan


On Thu, Jul 25, 2024 at 3:57?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Turkhan, this mail belongs to core-libs-dev list. I have forwarded your
> mail to the right list.
>
> Indeed, we should claim that peek() is equivalent to peekFirst(); the
> information in stack section should be a typo, as peek() being the same as
> peekFirst() is claimed by the deque section and the peek() specification.
>
> I have created a ticket on the Java Bug System to track this issue: [JDK-8337205]
> Typo in Stack vs Deque Method table in Deque specification - Java Bug
> System (openjdk.org) <https://bugs.openjdk.org/browse/JDK-8337205>
>
> Feel free to open a pull request to jdk to fix this bug.
>
> Best, Chen Liang
> ------------------------------
> *From:* jdk-dev <jdk-dev-retn at openjdk.org> on behalf of Turkhan Badalov <
> badalov.turxan at gmail.com>
> *Sent:* Thursday, July 25, 2024 4:58 AM
> *To:* jdk-dev at openjdk.org <jdk-dev at openjdk.org>
> *Subject:* Should the documentation state peekFirst() as equivalent to
> Stack's peek()?
>
> Here is the table "Comparison of Stack and Deque methods" that lists
> equivalent Deque methods compared to Stack methods:
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html
>
> At the moment, getFirst() is said to be equivalent to peek(). Since peek()
> doesn't throw an exception when the queue/stack is empty, peekFirst() could
> be a better equivalent because getFirst() throws.
>
> In fact, the documentation of the peek() method itself says that this
> method is equivalent to peekFirst():
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html#peek()
> .
>
> If this should be posted somewhere else, please let me know. I am still
> new to using mailing lists. Cheers.
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241106/cf3dd8b9/attachment.htm>

From liach at openjdk.org  Wed Nov  6 15:23:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 6 Nov 2024 15:23:38 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg
In-Reply-To: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
Message-ID: <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>

On Wed, 6 Nov 2024 14:15:42 GMT, jengebr <duke at openjdk.org> wrote:

> This change optimizes the runtime of `Class.getMethod(String, Class<?>[])` in two ways:
> 
> 1. While iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name.  This check is substantially faster.
> 2. While iterating (existing logic) if the requested method has no arguments, the loop terminates early after finding one match.  This works because there can only be one zero-arg method with the matching name in the specific class.
> 
> A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target.
> 
> Base:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    90.866 ?  2.698  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    72.472 ? 10.225  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   198.524 ?  7.089  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   191.739 ?  4.695  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2254.308 ? 42.829  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   165.897 ?  4.370  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   148.361 ?  4.573  ns/op
> 
> 
> Modified:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    77.059 ?  2.644  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    47.666 ?  6.544  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   164.427 ?  4.356  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   161.256 ?  6.832  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2158.844 ? 43.716  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   129.047 ?  4.414  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   123.728 ?  6.182  ns/op

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/lang/PublicMethods.java line 108:

> 106:                                Class<?>[] ptypes) {
> 107:             // check for matching param types length, then name, then param type equality
> 108:             return method.getParameterCount() == ptypes.length &&

Length check is already present in `equals`.  If you want this fast path, I think moving arrays equals check first is better.

src/java.base/share/classes/java/lang/PublicMethods.java line 157:

> 155:                         head = tail = new MethodList(method);
> 156:                         if (ptypes.length == 0) {
> 157:                             // zero args can only have one match - stop looking

This is wrong: if superclass has `Object work()` and this class has `Integer work()`, bytecode for this class will have a synthetic final `Object work()` that delegates call to `Integer work()`.

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

PR Review: https://git.openjdk.org/jdk/pull/21929#pullrequestreview-2418640017
PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831230782
PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831232688

From sgehwolf at openjdk.org  Wed Nov  6 15:25:52 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 6 Nov 2024 15:25:52 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <hAQ0t6h7-4RW0a43Jsn0o9AwJzFoDoOKsXm7OhlmcLY=.f5980637-2622-4d0c-8481-cdbc4ef46572@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <n2hkylB3HsgWYwZ37GvdJe2SAEX-c9geJJtSN_8NiYY=.20707bda-2fd7-4e09-b42d-319407f40ac6@github.com>
 <hAQ0t6h7-4RW0a43Jsn0o9AwJzFoDoOKsXm7OhlmcLY=.f5980637-2622-4d0c-8481-cdbc4ef46572@github.com>
Message-ID: <yclGOv7fWJZpisSncBwWnDbAl6SotsJwnr5z6zymlTk=.24557eab-a216-4c80-8c7e-ae5458c92059@github.com>

On Fri, 1 Nov 2024 18:03:16 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> I expect that the jmodless tests will first build an image (say `image1`) using jlink `--generate-linkable-runtime` option and then verify `image1/bin/jlink` that links from the run-time image.    I don't see `--generate-linkable-runtime` option is used from jmodless tests.   I looked at `AbstractLinkableRuntimeTest` which provides the support to create linkable runtime image but not obvious to me.   Can you describe the idea of this test framework?
>
>> I expect that the jmodless tests will first build an image (say `image1`) using jlink `--generate-linkable-runtime` option and then verify `image1/bin/jlink` that links from the run-time image. I don't see `--generate-linkable-runtime` option is used from jmodless tests. I looked at `AbstractLinkableRuntimeTest` which provides the support to create linkable runtime image but not obvious to me. Can you describe the idea of this test framework?
> 
> OK.  I see this now (`@requires jlink.runtime.linkable` in all jmodless tests).  I.e. No test for the default JDK build.
> 
> I think this feature needs test verification even for the default JDK build.   One way to do that is to build a test image (say `base-image`) using jlink `--generate-linkable-runtime` option and then verify `base-image/bin/jlink` instead of the JDK.

Thanks for the reviews so far! Especially @mlchung who was tremendously helpful! I very much appreciate the support, Mandy!

I think I've addressed all the comments and hope this will be ready for integration soon. The JEP has been targeted and that leaves about a month for this PR to be integrated. I do hope, though, that we can integrate it a few weeks before RDP1 of JDK 24 so as to avoid the last minute crunch time. I'd be happy to fix any remaining blockers and then follow-up with any needed tasks after initial integration of course.

Therefore, paging @AlanBateman @mlchung @mbreinhold @magicus for their final thoughts. Thank you!

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

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2460054319

From jvernee at openjdk.org  Wed Nov  6 15:27:32 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Nov 2024 15:27:32 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v13]
In-Reply-To: <LawuEa23JaOsGyhzvMd2OBz8CsLM9svCKcIRvPANiMk=.3f16cca7-2188-4cd5-8045-fdd19f5fb965@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <e5AoQnwnl2vLztV4xKNjhSxusEDjOk7cCb_4RwVdVk4=.003bb6ac-f1eb-40ed-a25c-dae005cbc727@github.com>
 <LawuEa23JaOsGyhzvMd2OBz8CsLM9svCKcIRvPANiMk=.3f16cca7-2188-4cd5-8045-fdd19f5fb965@github.com>
Message-ID: <USOSWDBf9RVnSHwWTBLioLapegwVCQDYJ6N25uFTOXk=.2601aac7-1bc3-45aa-bc36-30e01f900961@github.com>

On Wed, 6 Nov 2024 15:04:24 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> P.S. AFAICT, there are only 3 new checks we need to implement, the other rules should already be handled by the existing code:
> 
>     * No consecutive padding layouts in structs.
> 
>     * Not more than 1 padding layout in unions (to align the union itself).
> 
>     * No non-empty struct/union that contains _only_ a padding layout.

Maybe we should also check that padding layouts have natural alignment? The alignment of padding layouts can affect the alignment of the enclosing container.

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

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2460061254

From liach at openjdk.org  Wed Nov  6 15:29:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 6 Nov 2024 15:29:31 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg
In-Reply-To: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
Message-ID: <860VQbrkX8XeTq8XUhPUvci5qW0OwV_FGBwleeTUKig=.171267e0-b6a6-4ba8-9555-f60d70cc308a@github.com>

On Wed, 6 Nov 2024 14:15:42 GMT, jengebr <duke at openjdk.org> wrote:

> This change optimizes the runtime of `Class.getMethod(String, Class<?>[])` in two ways:
> 
> 1. While iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name.  This check is substantially faster.
> 2. While iterating (existing logic) if the requested method has no arguments, the loop terminates early after finding one match.  This works because there can only be one zero-arg method with the matching name in the specific class.
> 
> A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target.
> 
> Base:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    90.866 ?  2.698  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    72.472 ? 10.225  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   198.524 ?  7.089  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   191.739 ?  4.695  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2254.308 ? 42.829  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   165.897 ?  4.370  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   148.361 ?  4.573  ns/op
> 
> 
> Modified:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    77.059 ?  2.644  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    47.666 ?  6.544  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   164.427 ?  4.356  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   161.256 ?  6.832  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2158.844 ? 43.716  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   129.047 ?  4.414  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   123.728 ?  6.182  ns/op

I have a patch trying to avoid MethodList allocation for getMethod lookup: https://github.com/liachmodded/jdk/commit/789c72c4a258181f6fd7c75b9e2ad50b32d37982

However, another approach is to update the cache for ReflectionData, so we compute a Map from name+parameter key to the most specific method, when we compute `getMethods()`.  Note that if we cannot find the method in the immediately declared methods, we always have to explore all declared methods from superclasses and superinterfaces, which has the same cost as `getMethods()`.

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

PR Comment: https://git.openjdk.org/jdk/pull/21929#issuecomment-2460065177

From ihse at openjdk.org  Wed Nov  6 15:29:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Nov 2024 15:29:49 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
Message-ID: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>

On Tue, 5 Nov 2024 08:58:00 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_windows.cpp line 5863:
> 
>> 5861:     return nullptr;
>> 5862:   }
>> 5863: 
> 
> [pre-existing, and can't comment on line 5858 because it's not sufficiently near a change.]
> The calculation of `len` is wasting a byte when `lib_name` is null.  The `+2` accounts for the
> terminating `NUL` and the underscore separator between the sym_name part and the lib_name
> part.  That underscore isn't added when there isn't a lib_name part.  I think the simplest fix would
> be to change `name_len` to `(name_len +1)` and `+2` to `+1` in that calculation.  And add some
> commentary.
> 
> This might be deemed not worth fixing as there is likely often no actual wastage, due to alignment
> padding, and it slightly further complicates the calculation.  But additional commentary would still
> be desirable, to guide the next careful reader.  In which case it might be simpler to describe the
> fixed version.
> 
> Since this is pre-existing and relatively harmless in execution, it can be addressed in a followup
> change.

I've created https://bugs.openjdk.org/browse/JDK-8343703 for this, amongst other things.

> src/hotspot/share/include/jvm.h line 1165:
> 
>> 1163: #define AGENT_ONLOAD_SYMBOLS    {"Agent_OnLoad"}
>> 1164: #define AGENT_ONUNLOAD_SYMBOLS  {"Agent_OnUnload"}
>> 1165: #define AGENT_ONATTACH_SYMBOLS  {"Agent_OnAttach"}
> 
> There is more cleanup that can be done here.  These definitions are used as
> array initializers (hence the surrounding curly braces).  They are now always
> singleton, rather than sometimes having 2 elements.  The uses iterate over the
> now always singleton arrays.  Those iterations are no longer needed and could
> be eliminated.  And these macros could be eliminated, using the corresponding
> string directly in each use.  This can all be done as a followup change.

Handled by https://bugs.openjdk.org/browse/JDK-8343703.

> src/java.base/share/native/libjava/NativeLibraries.c line 67:
> 
>> 65:         strcat(jniEntryName, "_");
>> 66:         strcat(jniEntryName, cname);
>> 67:     }
> 
> I would prefer this be directly inlined at the sole call (in findJniFunction),
> to make it easier to verify there aren't any buffer overrun problems. (I don't
> think there are, but looking at this in isolation triggered warnings in my
> head.)
> 
> Also, it looks like all callers of findJniFunction ensure the cname argument
> is non-null. So there should be no need to handle the null case in
> findJniFunction (other than perhaps an assert or something). That could be
> addressed in a followup. (I've already implicitly suggested elsewhere in this
> PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS
> thing.)

@kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240264
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831240942
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831243370

From ihse at openjdk.org  Wed Nov  6 15:34:53 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 6 Nov 2024 15:34:53 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v45]
In-Reply-To: <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
Message-ID: <SbQO4VvGNbmOLV6WgeART5fNdd1-t6JOj2EVhcxE5nY=.6e3c5634-0183-404a-b954-627757dfe759@github.com>

On Wed, 6 Nov 2024 11:24:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Make capability in --help human readable
>  - Fix comment
>  - Fix SystemModulesTest2 when linkable runtime but no packaged modules
>  - Rename PackagedModulesVsJmodLessTest => PackagedModulesVsRuntimeImageLinkTest
>  - Rename JmodLess => runtimeImage
>  - Refactor tests so that they run for default build
>    
>    When a default JDK build is being produced, the tests create a run-time
>    image capable JDK as an interim step before everything else is being
>    verified.
>    
>    For a build that has the run-time image link capability already turned
>    on, this extra step is being omitted.
>  - Mandy's feedback
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Some test fixes
>  - ... and 170 more: https://git.openjdk.org/jdk/compare/83f3d42d...e83b9584

Build changes still look good.

(On a side note, I'm very happy the way this turned out wrt to the build system, compared to the initial prototype with a lot more heavy-handed build patches!)

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

Marked as reviewed by ihse (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2418671609

From duke at openjdk.org  Wed Nov  6 15:36:28 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 6 Nov 2024 15:36:28 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg
In-Reply-To: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
Message-ID: <Sgdp2L2KirbIVh7CJECfRTiKXmHo5MtIFpL4q3ZBcQk=.08f167f3-5bd6-4144-b6b5-02fac299275d@github.com>

On Wed, 6 Nov 2024 14:15:42 GMT, jengebr <duke at openjdk.org> wrote:

> This change optimizes the runtime of `Class.getMethod(String, Class<?>[])` in two ways:
> 
> 1. While iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name.  This check is substantially faster.
> 2. While iterating (existing logic) if the requested method has no arguments, the loop terminates early after finding one match.  This works because there can only be one zero-arg method with the matching name in the specific class.
> 
> A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target.
> 
> Base:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    90.866 ?  2.698  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    72.472 ? 10.225  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   198.524 ?  7.089  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   191.739 ?  4.695  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2254.308 ? 42.829  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   165.897 ?  4.370  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   148.361 ?  4.573  ns/op
> 
> 
> Modified:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    77.059 ?  2.644  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    47.666 ?  6.544  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   164.427 ?  4.356  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   161.256 ?  6.832  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2158.844 ? 43.716  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   129.047 ?  4.414  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   123.728 ?  6.182  ns/op

> I have a patch trying to avoid MethodList allocation for getMethod lookup: [liachmodded at 789c72c](https://github.com/liachmodded/jdk/commit/789c72c4a258181f6fd7c75b9e2ad50b32d37982)

I would love this - the memory cost of `getMethod()` is surprisingly high.

> However, another approach is to update the cache for ReflectionData, so we compute a Map from name+parameter key to the most specific method, when we compute `getMethods()`. Note that if we cannot find the method in the immediately declared methods, we always have to explore all declared methods from superclasses and superinterfaces, which has the same cost as `getMethods()`.

I see the runtime advantage but am concerned by the memory usage.  Our Spring + Tomcat applications would generate a rather large cache.

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

PR Comment: https://git.openjdk.org/jdk/pull/21929#issuecomment-2460087764

From duke at openjdk.org  Wed Nov  6 15:36:29 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 6 Nov 2024 15:36:29 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg
In-Reply-To: <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
 <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
Message-ID: <hlG0epaIw61mXpSBbDvcgU1u7Srh__lpY_r_StnseiQ=.f3bce677-440a-419e-8146-1d46015ddba4@github.com>

On Wed, 6 Nov 2024 15:20:42 GMT, Chen Liang <liach at openjdk.org> wrote:

>> This change optimizes the runtime of `Class.getMethod(String, Class<?>[])` in two ways:
>> 
>> 1. While iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name.  This check is substantially faster.
>> 2. While iterating (existing logic) if the requested method has no arguments, the loop terminates early after finding one match.  This works because there can only be one zero-arg method with the matching name in the specific class.
>> 
>> A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target.
>> 
>> Base:
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    90.866 ?  2.698  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    72.472 ? 10.225  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   198.524 ?  7.089  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   191.739 ?  4.695  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2254.308 ? 42.829  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   165.897 ?  4.370  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   148.361 ?  4.573  ns/op
>> 
>> 
>> Modified:
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    77.059 ?  2.644  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    47.666 ?  6.544  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   164.427 ?  4.356  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   161.256 ?  6.832  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2158.844 ? 43.716  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   129.047 ?  4.414  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   123.728 ?  6.182  ns/op
>
> src/java.base/share/classes/java/lang/PublicMethods.java line 157:
> 
>> 155:                         head = tail = new MethodList(method);
>> 156:                         if (ptypes.length == 0) {
>> 157:                             // zero args can only have one match - stop looking
> 
> This is wrong: if superclass has `Object work()` and this class has `Integer work()`, bytecode for this class will have a synthetic final `Object work()` that delegates call to `Integer work()`.

Gotcha, I'll remove the no-arg change.  Thanks!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831250497

From sspitsyn at openjdk.org  Wed Nov  6 16:00:59 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 16:00:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v30]
In-Reply-To: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1789ddda-b40d-4427-a0c1-8161504c0768@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <b8rs1NNHOC0at-ThUQEM7T-KRhS2hctkQ-jHb8b5w1A=.95e802cc-a27e-4141-8016-bb0d5d7b98fa@github.com>
 <Ex3o_n-aPorPnjda3NNsXGoaflMGFWWpsI2nekHKN3Q=.8321e077-7758-4850-b19a-dadbfa1cc232@github.com>
 <ErUMux1rvqoDRu-BMtfUTsGMMQkXO3JYGbwl5ftl6K4=.c9fe8efd-de61-4a47-921d-63e11afe57b9@github.com>
 <yz-sIo0o-VCcGKtdcrXm_crCEXvnjtCYyDAa_JIIwC4=.a1051197-abd9-40db-a17c-da1875eb42d2@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1789ddda-b40d-4427-a0c1-8161504c0768@github.com>
Message-ID: <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.b0e6bf31-c7dd-4702-ac97-043ed536821e@github.com>

On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So at some point I think we need to figure out how to make them go away  ...

Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes.

> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor...

The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though.

> That's the path a virtual thread will take if pinned. 

Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112

From sspitsyn at openjdk.org  Wed Nov  6 16:34:54 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 16:34:54 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v29]
In-Reply-To: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.14e90620-411b-41db-8455-14ffa4697f71@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.339387cd-bc5f-4a80-a5ff-039a25207525@github.com>
 <UUlFzhGjkErnE7Zozgv7AqczWNLt9B6oM_RYgHu69VA=.5b061d99-c52f-4c14-84de-ae1818fa16ab@github.com>
 <XgkDTw1pKkFMTL_Wxnjp-wmvr3pHH2SSVvLbVLM-k64=.b15aada9-604b-4e03-bc13-27a307a5735b@github.com>
 <tO4X4mf0RjW70EhK3Ot2B71no_UTqjSm4-RLKfAZ7P8=.d777059a-4a97-4307-a373-5febd3d48bd0@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.14e90620-411b-41db-8455-14ffa4697f71@github.com>
Message-ID: <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.483b5c46-cc7b-4cd5-80bf-b1462c684d36@github.com>

On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
>> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
>> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.
>
> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.
> 
> [1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.

> but does the specs say the event has to be posted in the context of the vthread?

As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.

> For pop_frame/early_ret checks ...

The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.

> Maybe we could go with this simplified code now and work on it later...

Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
It would be nice to fix a couple of nits though:
 - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
 - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766

From duke at openjdk.org  Wed Nov  6 17:15:06 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 6 Nov 2024 17:15:06 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg [v2]
In-Reply-To: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
Message-ID: <5W-emZh0ZpcKKeazo2i7SoPYh68aJorzHNPIJtJnWIM=.12515dbc-be82-4ebb-989f-08816e488f61@github.com>

> This change optimizes the runtime of `Class.getMethod(String, Class<?>[])` in two ways:
> 
> 1. While iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name.  This check is substantially faster.
> 2. While iterating (existing logic) if the requested method has no arguments, the loop terminates early after finding one match.  This works because there can only be one zero-arg method with the matching name in the specific class.
> 
> A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target.
> 
> Base:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    90.866 ?  2.698  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    72.472 ? 10.225  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   198.524 ?  7.089  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   191.739 ?  4.695  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2254.308 ? 42.829  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   165.897 ?  4.370  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   148.361 ?  4.573  ns/op
> 
> 
> Modified:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    77.059 ?  2.644  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    47.666 ?  6.544  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   164.427 ?  4.356  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   161.256 ?  6.832  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2158.844 ? 43.716  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   129.047 ?  4.414  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   123.728 ?  6.182  ns/op

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

 - Optimizing filter logic by internalizing loop
 - Enhancing benchmark + tests with additional 5-arg cases
 - Removing no-arg optimization

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

Changes:
  - all: https://git.openjdk.org/jdk/pull/21929/files
  - new: https://git.openjdk.org/jdk/pull/21929/files/4a007cc2..b0b63ecb

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

  Stats: 35 lines in 3 files changed: 27 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21929/head:pull/21929

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

From qamai at openjdk.org  Wed Nov  6 17:26:42 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:26:42 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v3]
In-Reply-To: <IwJMxVTlKOETKZ9T7VyYEn6f9CCzuL9f-z4LFuAQvFw=.bdcc0c3b-6192-4a77-8463-28eebcaa5cf2@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <H_jGObQ-aQDgT6Nvtb_bnN-kw_THKiegNphS0EhUsfs=.ef80d5bf-d11d-4e36-8c6f-6ceb6c510239@github.com>
 <IwJMxVTlKOETKZ9T7VyYEn6f9CCzuL9f-z4LFuAQvFw=.bdcc0c3b-6192-4a77-8463-28eebcaa5cf2@github.com>
Message-ID: <BFIaR-iotTQndXYoBn-YCdeW4CLAWopy8HWAvHifNWc=.74b30670-a032-429b-9097-48ea7528c3bb@github.com>

On Thu, 31 Oct 2024 23:08:40 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix benchmarks
>
> Actually, @JornVernee pointed out (great observation!) that this PR creates a new asymmetry between liveness and acquired state -- it would be possible to see an acquire failure (e.g. when passing a segment to a native call) while the segment scope still looks alive. We need to think about this some more.

@mcimadamore Could you please re-approve this patch, I still have not got used to the stricter integration check :)

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

PR Comment: https://git.openjdk.org/jdk/pull/21810#issuecomment-2460366996

From duke at openjdk.org  Wed Nov  6 17:31:33 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 6 Nov 2024 17:31:33 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg [v2]
In-Reply-To: <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
 <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
Message-ID: <4ZT226VcGPQltW-uje_qA0bdntPigpCmwIUeNpckcfo=.194b18ca-0c8e-4299-85bd-b60708a91227@github.com>

On Wed, 6 Nov 2024 15:19:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> jengebr has updated the pull request incrementally with three additional commits since the last revision:
>> 
>>  - Optimizing filter logic by internalizing loop
>>  - Enhancing benchmark + tests with additional 5-arg cases
>>  - Removing no-arg optimization
>
> src/java.base/share/classes/java/lang/PublicMethods.java line 108:
> 
>> 106:                                Class<?>[] ptypes) {
>> 107:             // check for matching param types length, then name, then param type equality
>> 108:             return method.getParameterCount() == ptypes.length &&
> 
> Length check is already present in `equals`.  If you want this fast path, I think moving arrays equals check first is better.

I benchmarked variations on this and got some surprises.  The noArg change was removed prior to any experiments, so this is strictly the `matches()` optimization.

Base case (no PR):

Benchmark                          Mode  Cnt     Score    Error  Units
ClassGetMethod.getConcreteFiveArg  avgt    6    94.586 ?  0.733  ns/op
ClassGetMethod.getConcreteNoArg    avgt    6    75.587 ? 11.300  ns/op
ClassGetMethod.getIntfFiveArg      avgt    6   215.794 ?  7.713  ns/op
ClassGetMethod.getIntfNoArg        avgt    6   200.418 ?  4.352  ns/op
ClassGetMethod.getNoSuchMethod     avgt   10  2207.928 ? 49.767  ns/op
ClassGetMethod.getSuperFiveArg     avgt    6   190.142 ?  1.995  ns/op
ClassGetMethod.getSuperNoArg       avgt    6   153.943 ?  7.491  ns/op


With `Arrays.equals()`, then name:

Benchmark                          Mode  Cnt     Score    Error  Units
ClassGetMethod.getConcreteFiveArg  avgt    6    82.949 ?  7.614  ns/op
ClassGetMethod.getConcreteNoArg    avgt    6    98.248 ? 11.482  ns/op
ClassGetMethod.getIntfFiveArg      avgt    6   204.604 ?  5.656  ns/op
ClassGetMethod.getIntfNoArg        avgt    6   225.582 ?  5.238  ns/op
ClassGetMethod.getNoSuchMethod     avgt   10  2216.038 ? 48.732  ns/op
ClassGetMethod.getSuperFiveArg     avgt    6   172.416 ?  3.211  ns/op
ClassGetMethod.getSuperNoArg       avgt    6   138.102 ? 16.215  ns/op

(faster in some cases, slower in others)

With paramCount, then name, then Arrays.equals():

Benchmark                          Mode  Cnt     Score    Error  Units
ClassGetMethod.getConcreteFiveArg  avgt    6    95.117 ?  1.574  ns/op
ClassGetMethod.getConcreteNoArg    avgt    6    77.915 ? 10.294  ns/op
ClassGetMethod.getIntfFiveArg      avgt    6   193.514 ?  4.611  ns/op
ClassGetMethod.getIntfNoArg        avgt    6   205.957 ?  4.475  ns/op
ClassGetMethod.getNoSuchMethod     avgt   10  2234.166 ? 51.249  ns/op
ClassGetMethod.getSuperFiveArg     avgt    6   164.650 ?  3.689  ns/op
ClassGetMethod.getSuperNoArg       avgt    6   128.969 ?  4.442  ns/op

(faster or neutral in all cases)

With paramCount, then name, then custom loop:

Benchmark                          Mode  Cnt     Score    Error  Units
ClassGetMethod.getConcreteFiveArg  avgt    6    64.802 ?  4.504  ns/op
ClassGetMethod.getConcreteNoArg    avgt    6    51.998 ?  5.645  ns/op
ClassGetMethod.getIntfFiveArg      avgt    6   194.252 ?  7.759  ns/op
ClassGetMethod.getIntfNoArg        avgt    6   199.110 ?  4.163  ns/op
ClassGetMethod.getNoSuchMethod     avgt   10  2216.636 ? 33.669  ns/op
ClassGetMethod.getSuperFiveArg     avgt    6   157.460 ? 19.412  ns/op
ClassGetMethod.getSuperNoArg       avgt    6   125.441 ?  2.990  ns/op

(fastest or neutral results in all cases)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831449004

From duke at openjdk.org  Wed Nov  6 17:31:34 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 6 Nov 2024 17:31:34 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg [v2]
In-Reply-To: <4ZT226VcGPQltW-uje_qA0bdntPigpCmwIUeNpckcfo=.194b18ca-0c8e-4299-85bd-b60708a91227@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
 <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
 <4ZT226VcGPQltW-uje_qA0bdntPigpCmwIUeNpckcfo=.194b18ca-0c8e-4299-85bd-b60708a91227@github.com>
Message-ID: <fIHbESK8uBQ5rip0SXs8ELTdXyDYSV6QVgDVqCBQGHI=.1e04cfd4-3773-4388-b685-63ab1912c489@github.com>

On Wed, 6 Nov 2024 17:28:08 GMT, jengebr <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/PublicMethods.java line 108:
>> 
>>> 106:                                Class<?>[] ptypes) {
>>> 107:             // check for matching param types length, then name, then param type equality
>>> 108:             return method.getParameterCount() == ptypes.length &&
>> 
>> Length check is already present in `equals`.  If you want this fast path, I think moving arrays equals check first is better.
>
> I benchmarked variations on this and got some surprises.  The noArg change was removed prior to any experiments, so this is strictly the `matches()` optimization.
> 
> Base case (no PR):
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    94.586 ?  0.733  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    75.587 ? 11.300  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   215.794 ?  7.713  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   200.418 ?  4.352  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2207.928 ? 49.767  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   190.142 ?  1.995  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   153.943 ?  7.491  ns/op
> 
> 
> With `Arrays.equals()`, then name:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    82.949 ?  7.614  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    98.248 ? 11.482  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   204.604 ?  5.656  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   225.582 ?  5.238  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2216.038 ? 48.732  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   172.416 ?  3.211  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   138.102 ? 16.215  ns/op
> 
> (faster in some cases, slower in others)
> 
> With paramCount, then name, then Arrays.equals():
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    95.117 ?  1.574  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    77.915 ? 10.294  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   193.514 ?  4.611  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   205.957 ?  4.475  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2234.166 ? 51.249  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   164.650 ?  3.689  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   128.969 ?  4.442  ns/op
> 
> (faster or neutral in all cases)
> 
> With paramCount, then name, then custom loop:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    64.802 ?  4.504  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    51.998 ?  5.645  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   194.252 ?  7.759  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   199.110 ?  4.163  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   1...

I don't like the style of a custom loop rather than `Arrays.equals()` but there is a perf benefit to it.  Curious what you think?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831450140

From liach at openjdk.org  Wed Nov  6 17:38:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 6 Nov 2024 17:38:28 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg [v2]
In-Reply-To: <fIHbESK8uBQ5rip0SXs8ELTdXyDYSV6QVgDVqCBQGHI=.1e04cfd4-3773-4388-b685-63ab1912c489@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
 <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
 <4ZT226VcGPQltW-uje_qA0bdntPigpCmwIUeNpckcfo=.194b18ca-0c8e-4299-85bd-b60708a91227@github.com>
 <fIHbESK8uBQ5rip0SXs8ELTdXyDYSV6QVgDVqCBQGHI=.1e04cfd4-3773-4388-b685-63ab1912c489@github.com>
Message-ID: <CwDFv6ndMA23N5btyJhOoi0-CYjNJiSQudUZelFaG54=.d9b99093-d52e-42c8-8e3d-a21b15551266@github.com>

On Wed, 6 Nov 2024 17:28:54 GMT, jengebr <duke at openjdk.org> wrote:

>> I benchmarked variations on this and got some surprises.  The noArg change was removed prior to any experiments, so this is strictly the `matches()` optimization.
>> 
>> Base case (no PR):
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    94.586 ?  0.733  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    75.587 ? 11.300  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   215.794 ?  7.713  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   200.418 ?  4.352  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2207.928 ? 49.767  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   190.142 ?  1.995  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   153.943 ?  7.491  ns/op
>> 
>> 
>> With `Arrays.equals()`, then name:
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    82.949 ?  7.614  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    98.248 ? 11.482  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   204.604 ?  5.656  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   225.582 ?  5.238  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2216.038 ? 48.732  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   172.416 ?  3.211  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   138.102 ? 16.215  ns/op
>> 
>> (faster in some cases, slower in others)
>> 
>> With paramCount, then name, then Arrays.equals():
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    95.117 ?  1.574  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    77.915 ? 10.294  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   193.514 ?  4.611  ns/op
>> ClassGetMethod.getIntfNoArg        avgt    6   205.957 ?  4.475  ns/op
>> ClassGetMethod.getNoSuchMethod     avgt   10  2234.166 ? 51.249  ns/op
>> ClassGetMethod.getSuperFiveArg     avgt    6   164.650 ?  3.689  ns/op
>> ClassGetMethod.getSuperNoArg       avgt    6   128.969 ?  4.442  ns/op
>> 
>> (faster or neutral in all cases)
>> 
>> With paramCount, then name, then custom loop:
>> 
>> Benchmark                          Mode  Cnt     Score    Error  Units
>> ClassGetMethod.getConcreteFiveArg  avgt    6    64.802 ?  4.504  ns/op
>> ClassGetMethod.getConcreteNoArg    avgt    6    51.998 ?  5.645  ns/op
>> ClassGetMethod.getIntfFiveArg      avgt    6   194.252 ?  7.759  ns/op
>> ClassGetMethod.getIn...
>
> I don't like the style of a custom loop rather than `Arrays.equals()` but there is a perf benefit to it.  Curious what you think?

Sure, moving param count ahead is fine.  Note that `Arrays.equals` is subject to profile pollution at runtime, so the benchmark results might not be applicable in practice.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831459646

From jbhateja at openjdk.org  Wed Nov  6 17:39:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:22 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86 VPMUL[U]DQ
 instruction
Message-ID: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>

This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
  

       MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
       MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
       MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
       MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
       MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
       MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)



 A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.

If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
 
VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.

Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
 

Sierra Forest :-
============
Baseline:-
Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms

With Optimization:-
Benchmark                                 (SIZE)   Mode  Cnt     Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  1299.407          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2   504.995          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2   327.544          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2   160.963          ops/ms

Granite Rapids:-
=============
Baseline:-
Benchmark                                 (SIZE)   Mode  Cnt     Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  2279.099          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  1148.609          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2   570.848          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2   268.872          ops/ms

With Optimization:-
Benchmark                                 (SIZE)   Mode  Cnt     Score   Error   Units
VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  2612.484          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  1308.187          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2   653.375          ops/ms
VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2   316.182          ops/ms


Kindly review and share your feedback.

Best Regards,
Jatin

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

Commit messages:
 - Removing target specific hooks
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
 - Review resoultions
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
 - Handle new I2L pattern, IR tests, Rewiring pattern inputs to MulVL further optimizes JIT code
 - Review resolutions
 - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

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

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

From jkarthikeyan at openjdk.org  Wed Nov  6 17:39:27 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Wed, 6 Nov 2024 17:39:27 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.42e3469d-3de0-4cc5-afd9-cca9cbd4d4a3@github.com>

On Sun, 29 Sep 2024 04:21:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

> Hi @jaskarth , Bigger pattern matching is sensitive to [IR level node sharing](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/matcher.cpp#L1724), thus it may not full proof for above 4 patterns. Current patch takes care of this limitation.

I think this is a good point. I've taken a look at the patch and added some comments below.

Hmm, do you think this pattern could be matched in the ad-files instead of the middle end? I think that might be a lot cleaner since the backend already has systems for matching node trees, which could avoid a lot of the complexity here. I think it could make the patch a lot smaller and simpler.

For the record I think in this PR we could simply match the IR patterns in the ad file, since (from my understanding) the patterns we are matching could be supported there. We should do platform-specific lowering in a separate patch because it is pretty nuanced, and we could potentially move it to the new system afterwards.

I'm pretty ambivalent, I think implementing it either way would be alright. Especially with unit tests, I think the lowering implementation wouldn't be that difficult. Maybe another reviewer has an opinion?

About PhaseLowering though, I've found some more interesting things we could do with it, especially with improving vectorization support in the backend. @merykitty have you already started to work on it? I was thinking about prototyping it soon. Just wanted to make sure we're not doing the same work twice :)

BTW, from the last conversation I had started working on PhaseLowering myself, you can see my work so far on my branch: https://github.com/jaskarth/jdk/tree/phase-lowering. I think I can publish an RFE in the coming two or three days (there were some optimizations and cleanup I was prototyping, I will remove them before sending a PR.) Do you think we should continue with my branch or do you want to approach the problem from a different way? Just want to check again to make sure we don't end up re-doing the same work :)

src/hotspot/cpu/x86/matcher_x86.hpp line 184:

> 182:   // Does the CPU supports doubleword multiplication with quadword saturation.
> 183:   static constexpr bool supports_double_word_mult_with_quadword_staturation(void) {
> 184:     return true;

Should this be `UseAVX > 0`? I'm wondering since we have a `MulVL` rule that applies when `UseAVX == 0`.

src/hotspot/share/opto/vectornode.cpp line 2089:

> 2087:   if (Matcher::supports_double_word_mult_with_quadword_staturation() &&
> 2088:       !is_mult_lower_double_word()) {
> 2089:     auto is_clear_upper_double_word_uright_shift_op = [](const Node *n) {

Suggestion:

    auto is_clear_upper_double_word_uright_shift_op = [](const Node* n) {

src/hotspot/share/opto/vectornode.cpp line 2093:

> 2091:              n->in(2)->Opcode() == Op_RShiftCntV && n->in(2)->in(1)->is_Con() &&
> 2092:              n->in(2)->in(1)->bottom_type()->isa_int() &&
> 2093:              n->in(2)->in(1)->bottom_type()->is_int()->get_con() == 32L;

Suggestion:

             n->in(2)->in(1)->bottom_type()->is_int()->get_con() == 32;

Since you are comparing with a `TypeInt` I think this shouldn't be `32L`.

src/hotspot/share/opto/vectornode.cpp line 2098:

> 2096:     auto is_lower_double_word_and_mask_op = [](const Node *n) {
> 2097:       if (n->Opcode() == Op_AndV) {
> 2098:         Node *replicate_operand = n->in(1)->Opcode() == Op_Replicate ? n->in(1)

Suggestion:

        Node* replicate_operand = n->in(1)->Opcode() == Op_Replicate ? n->in(1)

src/hotspot/share/opto/vectornode.cpp line 2124:

> 2122:     // MulL ( And  SRC1,  0xFFFFFFFF) (URShift SRC2 , 32)
> 2123:     if ((is_lower_double_word_and_mask_op(in(1)) ||
> 2124:          is_lower_double_word_and_mask_op(in(1)) ||

`is_lower_double_word_and_mask_op(in(1)) || is_lower_double_word_and_mask_op(in(1))` is redundant, right? Shouldn't you only need it once? Same for the other 3 calls, which are similarly repeated.

test/hotspot/jtreg/compiler/vectorapi/VectorMultiplyOpt.java line 41:

> 39:  */
> 40: 
> 41: public class VectorMultiplyOpt {

Could it be possible to also do IR verification in this test? It would be good to check that we don't generate `AndVL` or `URShiftVL` with this transform.

test/hotspot/jtreg/compiler/vectorapi/VectorMultiplyOpt.java line 43:

> 41: public class VectorMultiplyOpt {
> 42: 
> 43:     public static long [] src1;

Suggestion:

    public static long[] src1;

And for the rest of the `long []` in this file too.

test/micro/org/openjdk/bench/jdk/incubator/vector/VectorXXH3HashingBenchmark.java line 39:

> 37:     @Param({"1024", "2048", "4096", "8192"})
> 38:     private int  SIZE;
> 39:     private long [] accumulators;

Suggestion:

    private long[] accumulators;

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

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2367683334
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2407658405
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2411538179
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2414553899
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2422700344
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800159123
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800153755
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800153568
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800153842
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800151177
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800167403
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800165261
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1800169840

From jbhateja at openjdk.org  Wed Nov  6 17:39:27 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:27 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <QFyjgifYwi6F953gcME5Zz2m4gczLO5wKt2oUabgNZo=.7ddb9ab3-ad73-4e49-8f5b-9b9c0e1d1505@github.com>

On Sun, 29 Sep 2024 04:21:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Hi @iwanowww , @sviswa7, @merykitty, Can you kindly review this.

I re-evaluated the solution and feel that lowering pass will compliment such transformation, specially in light of re-wiring logic to directly feed the pattern inputs to Multiplier, while x86 VMULUDQ expects to operate on lower doubleword of each quadword lane, AARCH64 SVE has instructions which considers upper doubleword of quadword multiplier and multiplicand and hence can optimize following pattern too
` MulVL  ( SRC1 << 32 ) *  ( SRC2 << 32 ) 
`

https://www.felixcloutier.com/x86/pmuludq
https://dougallj.github.io/asil/doc/umullt_z_zz_32.html
 
I am in process of introducing a PhaseLowering which will have target specific IR transformations for nodes of interest, till then moving the PR to draft stage.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2401895553
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2422634178

From qamai at openjdk.org  Wed Nov  6 17:39:29 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:29 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>

On Sun, 29 Sep 2024 04:21:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Another approach is to do similarly to `MacroLogicVNode`. You can make another node and transform `MulVL` to it before matching, this is more flexible than using match rules. I am having a similar idea that is to group those transformations together into a `Phase` called `PhaseLowering`. It can be used to do e.g split `ExtractI` into the 128-bit lane extraction and the element extraction from that lane. This allows us to do `GVN` on those and `v.lane(5) + v.lane(7)` can be compiled nicely as:

    vextracti128 xmm0, ymm1, 1
    pextrd eax, xmm0, 1
    // vextracti128 xmm0, ymm1, 1 here will be gvn-ed
    pextrd ecx, xmm0, 3
    add eax, ecx

Personally, I think this optimization is not essential, so we should proceed with introducing lowering first, then add this transformation to that phase, instead of trying to integrate this transformation then refactor it into phase lowering, which seems like a net extra step.

The issues I have with this patch are that:
- It convolutes the graph with machine-dependent nodes early in the compiling process.
- It overloads `MulVL` with alternative behaviours, it is fine now as we do not perform much analysis on this node but it would be problematic later. I think it is more preferable to have a separate IR node for this like `MulVLowIToLNode`, or have this transformation be done only just before matching, or both.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2407793168
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2414491182
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421157206

From jkarthikeyan at openjdk.org  Wed Nov  6 17:39:29 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Wed, 6 Nov 2024 17:39:29 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
Message-ID: <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.e1960473-52da-4588-9be0-867fde9fec42@github.com>

On Fri, 11 Oct 2024 16:54:23 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> I am having a similar idea that is to group those transformations together into a `Phase` called `PhaseLowering`

I think such a phase could be quite useful in general. Recently I was trying to implement the BMI1 instruction `bextr` for better performance with bit masks, but ran into a problem where it doesn't have an immediate encoding so we'd need to manifest a constant into a temporary register every time. With an (x86-specific) ideal node, we could simply let the register allocator handle placing the constant. It would also be nice to avoid needing to put similar backend-specific lowerings (such as `MacroLogicV`) in shared code.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2407821557

From jbhateja at openjdk.org  Wed Nov  6 17:39:29 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:29 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.e1960473-52da-4588-9be0-867fde9fec42@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.e1960473-52da-4588-9be0-867fde9fec42@github.com>
Message-ID: <aENxkYVram8hqkBGhMQ1V9RaKr0qmpeT61KZ78-yRmQ=.73847a0d-7cf3-402f-af4f-8ac664025f48@github.com>

On Fri, 11 Oct 2024 17:12:49 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

> > I am having a similar idea that is to group those transformations together into a `Phase` called `PhaseLowering`
> 
> I think such a phase could be quite useful in general. Recently I was trying to implement the BMI1 instruction `bextr` for better performance with bit masks, but ran into a problem where it doesn't have an immediate encoding so we'd need to manifest a constant into a temporary register every time. With an (x86-specific) ideal node, we could simply let the register allocator handle placing the constant. It would also be nice to avoid needing to put similar backend-specific lowerings (such as `MacroLogicV`) in shared code.

Hey @jaskarth , @merykitty ,  we already have an infrastructure where during parsing we create Macro Nodes which can be lowered / expanded to multiple IRs nodes during macro expansion, what we need in this case is a target specific IR pattern check since not all targets may support 32x32 multiplication with quadword saturation, idea is to avoid creating a new IR and piggyback needed information on existing MulVL IR, we already use such tricks for relaxed unsafe reductions. Going forward, infusion of KnownBits into our data flow analysis infrastructure will streamline such optimizations, this patch is performing point optimization for specific set of constrained multiplication patterns.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2411053693

From pchilanomate at openjdk.org  Wed Nov  6 17:39:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:39:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads without
 Pinning
Message-ID: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>

This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.

In order to make the code review easier the changes have been split into the following initial 4 commits:

- Changes to allow unmounting a virtual thread that is currently holding monitors.
- Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
- Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
- Changes to tests, JFR pinned event, and other changes in the JDK libraries.

The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.

The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.


## Summary of changes

### Unmount virtual thread while holding monitors

As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:

- We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.

- For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.

#### General notes about this part:

- Since virtual threads don't need to worry about holding monitors anymore, we don't need to count them, except for `LM_LEGACY`. So the majority of the platform dependent changes in this commit have to do with correcting this.
- Zero and x86 (32 bits) where counting monitors even though they don't implement continuations, so I fixed that to stop counting. The idea is to remove all the counting code once we remove `LM_LEGACY`.
- Macro `LOOM_MONITOR_SUPPORT` was added at the time to exclude ports that implement continuations but don't yet implement monitor support. It is removed later with the ppc commit changes.
- Since now a virtual thread can be unmounted while holding monitors, JVMTI methods `GetOwnedMonitorInfo` and `GetOwnedMonitorStackDepthInfo` had to be adapted.

#### Notes specific to the tid changes:

- The tid is cached in the JavaThread object under `_lock_id`. It is set on JavaThread creation and changed on mount/unmount.
- Changes in the ObjectMonitor class in this commit are pretty much exclusively related to changing `_owner` and `_succ` from `void*` and `JavaThread*` respectively to `int64_t`.
- Although we are not trying to fix `LM_LEGACY` the tid changes apply to it as well since the inflated path is shared. Thus, in case of inflation by a contending thread, the `BasicLock*` cannot be stored in the `_owner` field as before. The `_owner` is instead set to anonymous as we do in `LM_LIGHTWEIGHT`, and the `BasicLock*` is stored in the new field `_stack_locker`.
- We already assume 32 bit platforms can handle 64 bit atomics, including `cmpxchg` ([JDK-8318776](https://bugs.openjdk.org/browse/JDK-8318776)) so the shared code can stay the same. The assembly code for the c2 fast paths has to be adapted though. On arm (32bits) we already jump directly to the slow path on inflated monitor case so there is nothing to do. For x86 (32bits), since the port is moving towards deprecation ([JDK-8338285](https://bugs.openjdk.org/browse/JDK-8338285)) there is no point in trying to optimize, so the code was changed to do the same thing we do for arm (32bits).

### Unmounting a virtual thread blocked on synchronized

Currently virtual thread unmounting is always started from Java, either because of a voluntarily call to `Thread.yield()` or because of performing some blocking operation such as I/O. Now we allow to unmount from inside the VM too, specifically when facing contention trying to acquire a Java monitor.

On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic. Once the owner releases the monitor and selects it as the next successor the virtual thread will be added again to the scheduler queue to run again. The virtual thread will run and attempt to acquire the monitor again. If it succeeds then it will thaw frames as usual to continue execution back were it left off. If it fails it will unmount and wait again to be unblocked.

#### General notes about this part:

- The easiest way to review these changes is to start from the monitorenter call in the interpreter and follow all the flow of the virtual thread, from unmounting to running again.
- Currently we use a dedicated unblocker thread to submit the virtual threads back to the scheduler queue. This avoids calls to Java from monitorexit. We are experimenting on removing this limitation, but that will be left as an enhancement for a future change.
- We cannot unmount the virtual thread when the monitor enter call is coming from `jni_enter()` or `ObjectLocker` since we would need to freeze native frames.
- If freezing fails, which almost always will be due to having native frames on the stack, the virtual thread will follow the normal platform thread logic but will do a timed-park instead. This is to alleviate some deadlocks cases where the successor picked is an unmounted virtual thread that cannot run, which can happen during class loading or class initiatialization.
- After freezing all frames, and while adding itself to the `_cxq` the virtual thread could?have successfully acquired the monitor. In that case we mark the preemption as cancelled. The virtual thread will still need to go back to the preempt stub to cleanup the physical stack but instead of unmounting it will call thaw to continue execution.
- The way we jump to the preempt stub is slightly different in the compiler and interpreter. For the compiled case we just patch a return address, so no new code is added. For the interpreter we cannot do this on all platforms so we just check a flag back in the interpreter. For the latter we also need to manually restore some state after we finally acquire the monitor and resume execution. All that logic is contained in new assembler method `call_VM_preemptable()`.

#### Notes specific to JVMTI changes:
- Since we are not unmounting from Java, there is no call to `VirtualThread.yieldContinuation()`. This means that we have to execute the equivalent of `notifyJvmtiUnmount(/*hide*/true)` for unmount, and of `notifyJvmtiMount(/*hide*/false)` for mount in the VM. The former is implemented with `JvmtiUnmountBeginMark` in `Continuation::try_preempt()`. The latter is implemented in method `jvmti_mount_end()` in `ContinuationFreezeThaw` at the end of thaw.
- When unmounting from Java the vthread unmount event is posted before we try to freeze the continuation. If that fails then we post the mount event. This all happens in `VirtualThread.yieldContinuation()`. When unmounting from the VM we only post the event once we know the freeze succeeded. Since at that point we are in the middle of the VTMS transition, posting the event is done in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()` after the transition finishes. Maybe the same thing should be done when unmounting from Java.

### Unmounting a virtual thread blocked on `Object.wait()`

This commit just extends the previous mechanism to be able to unmount inside the VM on `ObjectMonitor::wait`.

####  General notes about this part:
- The mechanism works as before with the difference that now the call will come from the native wrapper. This requires to add support to the continuation code to handle native wrapper frames, which is a main part of the changes in this commit.
- Both the compiled and interpreted native wrapper code will check for preemption on return from the wait call, after we have transitioned back to `_thread_in_Java`.

####  Note specific to JVMTI changes:
- If the monitor waited event is enabled we need to post it after the wait is done but before re-acquiring the monitor. Since the virtual thread is inside the VTMS transition at that point, we cannot do that directly. Currently in the code we end the transition, post the event and start the transition again. This is not ideal, and maybe we should unmount, post the event and then run again to try reacquire the monitor.


### Test changes + JFR Updates + Library code changes

#### Tests 

- The tests in `java/lang/Thread/virtual` are updated to add more tests for monitor enter/exit and Object.wait/notify. New tests are added for JFR events, synchronized native methods, and stress testing for several scenarios.
- `test/hotspot/gtest/nmt/test_vmatree.cpp` is changed due to an alias that conflicts. 
- A small number of tests, e.g.` test/hotspot/jtreg/serviceability/sa/ClhsdbInspect.java` and `test/hotspot/jtreg/vmTestbase/nsk/jvmti/scenarios/bcinstr/BI04/bi04t002`, are updated so they are in sync with the JDK code. 
- A number of JVMTI tests are updated to fix various issues, e.g. some tests saved a JNIEnv in a static. 

#### Diagnosing remaining pinning issues

- The diagnostic option `jdk.tracePinnedThreads` is removed. 
- The JFR `jdk.VirtualThreadPinned` event is changed so that it's now recorded in the VM, and for the following cases: parking when pinned, blocking in monitor enter when pinned, Object.wait when pinned, and waiting for a class to be initialized by another thread. The changes to object monitors should mean that only a few events are recorded. Future work may change this to a sampling approach.

#### Other changes to VirtualThread class

The VirtualThread implementation includes a few robustness changes. The `park/parkNanos` methods now park on the carrier if the freeze throws OOME. Moreover, the use of transitions is reduced so that the call out to the scheduler no longer requires a temporary transition. 

#### Other changes to libraries: 

- `ReferenceQueue` is reverted to use `synchronized`, the subclass based on `ReentrantLock` is removed. This change is done now because the changes for object monitors impact this area when there is preemption polling a reference queue. 
- `java.io` is reverted to use `synchronized`. This change has been important for testing virtual threads. There will be follow-up cleanup in main-line after the JEP is integrated to remove `InternalLock` and its uses in `java.io`. 
- The epoll and kqueue based Selectors are changed to preempt when doing blocking selects. This has been useful for testing virtual threads with some libraries, e.g. JDBC drivers. We could potentially separate this update if needed but it has been included in all testing and EA builds. 
- `sun.security.ssl.X509TrustManagerImpl` is changed to eagerly initialize AnchorCertificates, a forced change due to deadlocks in this code when testing. 

## Testing 

The changes have been running in the Loom pipeline for several months now. They have also been included in EA builds throughout the year at different stages (EA builds from earlier this year did not had Object.wait() support yet but more recent ones did) so there has been some external exposure too.

The current patch has been run through mach5 tiers 1-8. I'll keep running tests periodically until integration time.

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

Commit messages:
 - Use is_top_frame boolean in FreezeBase::check_valid_fast_path()
 - Move load of _lock_id in C2_MacroAssembler::fast_lock
 - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java
 - Update comment for _cont_fastpath
 - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt
 - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()
 - Fixes to JFR metadata.xml
 - Fix return miss prediction in generate_native_entry for riscv
 - Fix s390x failures
 - Add oopDesc::has_klass_gap() check
 - ... and 70 more: https://git.openjdk.org/jdk/compare/751a914b...211c6c81

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338383
  Stats: 9914 lines in 246 files changed: 7105 ins; 1629 del; 1180 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

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

From qamai at openjdk.org  Wed Nov  6 17:39:30 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:30 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <aENxkYVram8hqkBGhMQ1V9RaKr0qmpeT61KZ78-yRmQ=.73847a0d-7cf3-402f-af4f-8ac664025f48@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <dFk8CH3PN2SgyZ_VAef0uhWsdqj8D73_c1RTBsYUBrw=.e1960473-52da-4588-9be0-867fde9fec42@github.com>
 <aENxkYVram8hqkBGhMQ1V9RaKr0qmpeT61KZ78-yRmQ=.73847a0d-7cf3-402f-af4f-8ac664025f48@github.com>
Message-ID: <2g_Hm5UuVBqoklekkaxtnYn05JYKmosnzaMefQi_q3s=.916470fa-352d-410c-b187-f6453bb53630@github.com>

On Mon, 14 Oct 2024 12:12:58 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> I am having a similar idea that is to group those transformations together into a `Phase` called `PhaseLowering`
>> 
>> I think such a phase could be quite useful in general. Recently I was trying to implement the BMI1 instruction `bextr` for better performance with bit masks, but ran into a problem where it doesn't have an immediate encoding so we'd need to manifest a constant into a temporary register every time. With an (x86-specific) ideal node, we could simply let the register allocator handle placing the constant. It would also be nice to avoid needing to put similar backend-specific lowerings (such as `MacroLogicV`) in shared code.
>
>> > I am having a similar idea that is to group those transformations together into a `Phase` called `PhaseLowering`
>> 
>> I think such a phase could be quite useful in general. Recently I was trying to implement the BMI1 instruction `bextr` for better performance with bit masks, but ran into a problem where it doesn't have an immediate encoding so we'd need to manifest a constant into a temporary register every time. With an (x86-specific) ideal node, we could simply let the register allocator handle placing the constant. It would also be nice to avoid needing to put similar backend-specific lowerings (such as `MacroLogicV`) in shared code.
> 
> Hey @jaskarth , @merykitty ,  we already have an infrastructure where during parsing we create Macro Nodes which can be lowered / expanded to multiple IRs nodes during macro expansion, what we need in this case is a target specific IR pattern check since not all targets may support 32x32 multiplication with quadword saturation, idea is to avoid creating a new IR and piggyback needed information on existing MulVL IR, we already use such tricks for relaxed unsafe reductions. Going forward, infusion of KnownBits into our data flow analysis infrastructure will streamline such optimizations, this patch is performing point optimization for specific set of constrained multiplication patterns.

@jatin-bhateja That is machine-independent lowering, we are talking about machine-dependent lowering to which `MacroLogicV` transformation belongs. You can have `phaselowering_x86` and not have to add another method to `Matcher` as well as add default implementations to various architecture files. You can reuse `MulVL` node for that but I believe these transformations should be done as late as possible.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2411389030

From jbhateja at openjdk.org  Wed Nov  6 17:39:31 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:31 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.42e3469d-3de0-4cc5-afd9-cca9cbd4d4a3@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.42e3469d-3de0-4cc5-afd9-cca9cbd4d4a3@github.com>
Message-ID: <To-H_9U4QY2FqB2D_kRKrHxAND2gSmcN3iQhMKW9quw=.a69372e5-1504-4c43-bafd-758a3e5ce6f5@github.com>

On Mon, 14 Oct 2024 15:04:54 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

> For the record I think in this PR we could simply match the IR patterns in the ad file, since (from my understanding) the patterns we are matching could be supported there. We should do platform-specific lowering in a separate patch because it is pretty nuanced, and we could potentially move it to the new system afterwards.

Hi @jaskarth , Bigger pattern matching is sensitive to [IR level node sharing](https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/matcher.cpp#L1724), thus it may not be full proof for above 4 patterns. Current patch takes care of this limitation. 

> @jatin-bhateja That is machine-independent lowering, we are talking about machine-dependent lowering to which `MacroLogicV` transformation belongs. You can have `phaselowering_x86` and not have to add another method to `Matcher` as well as add default implementations to various architecture files. You can reuse `MulVL` node for that but I believe these transformations should be done as late as possible.

Hi @merykitty, I see some scope of refactoring and carving out a separate target specific lowering pass going forward, I have brough this up in past too. Existing optimizations are in line with current infrastructure and guards target specific optimizations with target specific match_rule_supported checks e.g. https://github.com/openjdk/jdk/blob/master/src/hotspot/share/opto/compile.cpp#L2898. As @jaskarth suggests we can pick this up going forward.

> BTW, from the last conversation I had started working on PhaseLowering myself, you can see my work so far on my branch: https://github.com/jaskarth/jdk/tree/phase-lowering. I think I can publish an RFE in the coming two or three days (there were some optimizations and cleanup I was prototyping, I will remove them before sending a PR.) Do you think we should continue with my branch or do you want to approach the problem from a different way? Just want to check again to make sure we don't end up re-doing the same work :)

Hi @jaskarth ,
Please add PhaseLowering skeleton code only and then we can add applicable lowering transforms in seperate patches e.g . I volenteer to move x86 side lowering transforms like MacroLogic Optimization along with this doubleword multiplication pass.

We need to carefully take such decisions keeping in the view the code duplication aspects, so only very specific IR transforms should be lowered,  common transforms should still be part of shared code. 

Let me know if you have any concerns.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2411884206
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2422981643

From aboldtch at openjdk.org  Wed Nov  6 17:39:21 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 17:39:21 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

I've done an initial look through of the hotspot changes.

In addition to my comments, I have looked at two more things.

One is to remove the _waiters reference counter from deflation and only use the _contentions reference counter. As well as tying the _contentions reference counter to the ObjectWaiter, so that it is easier to follow its lifetime, instead of these naked add_to_contentions, now that the ObjectWaiter does not have a straight forward scope, but can be frozen, and thawed on different threads. 46dacdf96999154e808d21e80b4d4e87f73bc802

Then I looked at typing up the thread / lock ids as an enum class 34221f4a50a492cad4785cfcbb4bef8fa51d6f23

Either of these could be future RFEs.

Good work! I'll approve the GC related changes.

There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.

Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.

A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.

// the sp of the oldest known interpreted/call_stub frame inside the
// continuation that we know about

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231:

> 229: 
> 230: StubFrame::~StubFrame() {
> 231:   __ epilogue(_use_pop_on_epilogue);

Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return?
e.g.
```C++
enum return_state_t {
  does_not_return, requires_return, requires_pop_epilogue_return
};

StubFrame::~StubFrame() {
  if (_return_state == does_not_return) {
    __ should_not_reach_here();
  } else {
    __ epilogue(_return_state == requires_pop_epilogue_return);
  }
}

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115:

> 113:   // The object's monitor m is unlocked iff m->owner == nullptr,
> 114:   // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY,
> 115:   // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT.

Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code.

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:

> 378:     lea(t2_owner_addr, owner_address);
> 379: 
> 380:     // CAS owner (null => current thread id).

I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 

Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:

> 298:   CodeBlob* cb = top.cb();
> 299: 
> 300:   if (cb->frame_size() == 2) {

Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313:

> 311: 
> 312:     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
> 313:                                               " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]);

Is there a reason for the mix of `2` and `frame::metadata_words`?

Maybe this could be
```C++
    intptr_t* const unadjusted_sp = sp;
    sp -= frame::metadata_words;
    sp[-2] = unadjusted_sp[-2];
    sp[-1] = unadjusted_sp[-1];

    log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
                                              " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]);

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275:

> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) {
> 1274:   ::continuation_enter_cleanup(masm);
> 1275: }

Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function.

src/hotspot/cpu/x86/assembler_x86.cpp line 2866:

> 2864:     emit_int32(0);
> 2865:   }
> 2866: }

Is it possible to make this more general and explicit instead of a sequence of bytes?

Something along the lines of:
```C++
  const address tar = L.is_bound() ? target(L) : pc();
  const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);

  InstructionMark im(this);
  emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
  if (!L.is_bound()) {
    // Patch @0x8D opcode
    L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
  }
  // Register and [rip+disp] operand
  emit_modrm(0b00, raw_encode(dst), 0b101);
  // Adjust displacement by sizeof lea instruction
  int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
  assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
  emit_int32(disp);


and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.

src/hotspot/share/oops/stackChunkOop.cpp line 445:

> 443: 
> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();

Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 

There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

src/hotspot/share/oops/stackChunkOop.cpp line 460:

> 458:     } else {
> 459:       oop value = *reinterpret_cast<oop*>(at);
> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);

Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

src/hotspot/share/oops/stackChunkOop.cpp line 471:

> 469:     }
> 470:   }
> 471: }

Can we turn these three very similar loops into one? In my opinion, it is easier to parse.

```C++
void stackChunkOopDesc::copy_lockstack(oop* dst) {
  const int cnt = lockstack_size();
  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
  const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops;
  const auto get_obj = [&](intptr_t* at) -> oop {
    if (requires_gc_barriers) {
      if (requires_uncompress) {
        return HeapAccess<>::oop_load(reinterpret_cast<narrowOop*>(at));
      }
      return HeapAccess<>::oop_load(reinterpret_cast<oop*>(at));
    }
    return *reinterpret_cast<oop*>(at);
  };

  intptr_t* lockstack_start = start_address();
  for (int i = 0; i < cnt; i++) {
    oop mon_owner = get_obj(&lockstack_start[i]);
    assert(oopDesc::is_oop(mon_owner), "not an oop");
    dst[i] = mon_owner;
  }
}

src/hotspot/share/prims/jvmtiExport.cpp line 1681:

> 1679:   EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread));
> 1680: 
> 1681:   // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop.

Suggestion:

  // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:

> 2232:     retry_fast_path = true;
> 2233:   } else {
> 2234:     relativize_chunk_concurrently(chunk);

Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 

While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:

> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
> 2246: 
> 2247:     chunk->set_lockstack_size(0);

After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.

Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.


diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
index d3d63533eed..f737bd2db71 100644
--- a/src/hotspot/share/oops/stackChunkOop.cpp
+++ b/src/hotspot/share/oops/stackChunkOop.cpp
@@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
   }
 }
 
+void stackChunkOopDesc::clear_lockstack() {
+  const int cnt = lockstack_size();
+  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
+  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
+  const auto clear_obj = [&](intptr_t* at) {
+    if (requires_uncompress) {
+      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
+    } else {
+      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
+    }
+  };
+
+  if (requires_gc_barriers) {
+    intptr_t* lockstack_start = start_address();
+    for (int i = 0; i < cnt; i++) {
+      clear_obj(&lockstack_start[i]);
+    }
+  }
+  set_lockstack_size(0);
+  set_has_lockstack(false);
+}
+
 void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
   if (*((juint*)this) == badHeapWordVal) {
     st->print_cr("BAD WORD");
diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
index 28e0576801e..928e94dd695 100644
--- a/src/hotspot/share/oops/stackChunkOop.hpp
+++ b/src/hotspot/share/oops/stackChunkOop.hpp
@@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
   void fix_thawed_frame(const frame& f, const RegisterMapT* map);
 
   void copy_lockstack(oop* start);
+  void clear_lockstack();
 
   template <typename OopT, class StackChunkLockStackClosureType>
   inline void iterate_lockstack(StackChunkLockStackClosureType* closure);
diff --git a/src/hotspot/share/runtime/continuationFreezeThaw.cpp b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
index 5b6e48a02f3..e7d505bb9b1 100644
--- a/src/hotspot/share/runtime/continuationFreezeThaw.cpp
+++ b/src/hotspot/share/runtime/continuationFreezeThaw.cpp
@@ -2244,8 +2244,7 @@ NOINLINE intptr_t* Thaw<ConfigT>::thaw_slow(stackChunkOop chunk, Continuation::t
     chunk->copy_lockstack(tmp_lockstack);
     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
 
-    chunk->set_lockstack_size(0);
-    chunk->set_has_lockstack(false);
+    chunk->clear_lockstack();
     retry_fast_path = true;
   }
 ```

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538:

> 2536:   Method* m = hf.interpreter_frame_method();
> 2537:   // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler).
> 2538:   const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2;

Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places.

src/hotspot/share/runtime/frame.cpp line 535:

> 533:   assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address");
> 534:   return thread_addr;
> 535: #endif

With this ifdef, it seems like this belongs in the platform dependent part of the frame class.

src/hotspot/share/runtime/javaThread.cpp line 1545:

> 1543:     if (is_vthread_mounted()) {
> 1544:       // _lock_id is the thread ID of the mounted virtual thread
> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());

What is the interaction here with `switchToCarrierThread` and the window between?

        carrier.setCurrentThread(carrier);
        Thread.setCurrentLockId(this.threadId());

Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).

src/hotspot/share/runtime/objectMonitor.hpp line 184:

> 182:   // - We test for anonymous owner by testing for the lowest bit, therefore
> 183:   //   DEFLATER_MARKER must *not* have that bit set.
> 184:   static const int64_t DEFLATER_MARKER = 2;

The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch).

src/hotspot/share/runtime/objectMonitor.hpp line 186:

> 184:   static const int64_t DEFLATER_MARKER = 2;
> 185: 
> 186:   int64_t volatile _owner;  // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER.

Suggestion:

  int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.

src/hotspot/share/runtime/objectMonitor.inline.hpp line 50:

> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");

Suggestion:

  assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

src/hotspot/share/runtime/synchronizer.cpp line 1467:

> 1465:       markWord dmw = inf->header();
> 1466:       assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value());
> 1467:       if (inf->is_owner_anonymous() && inflating_thread != nullptr) {

Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze?

src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:

> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
> 61:         MONITOR(3, "Monitor held"),
> 62:         CRITICAL_SECTION(4, "In critical section");

Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 

I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2381051930
Marked as reviewed by aboldtch (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417363171
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808181783
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808189977
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808208652
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808282892
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808261926
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808318304
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808358874
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825949756
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825942254
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808706427
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808809374
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810772765
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810764911
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808460330
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809032469
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809065834
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809091338
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809092367
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829464866
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809111830
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827276764

From dholmes at openjdk.org  Wed Nov  6 17:39:47 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:39:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

First, congratulations on an exceptional piece of work @pchilano .  

Also thank you for the very clear breakdown and description in the PR as that helps immensely with trying to digest a change of this size.

The overall operational behaviour of this change seems very solid. My only concern is whether the unparker thread may become a bottleneck in some scenarios, but that is a bridge we will have to cross if we come to it.

My initial comments mainly come from just trying to understand the top-level changes around the use of the thread-id as the monitor owner. I have a number of suggestions on naming (mainly `is_x` versus `has_x`) and on documenting the API methods more clearly. None of which are showstoppers and some of which pre-exist. Unfortunately though you will need to fix the spelling of `succesor`.

Thanks

Thanks for those updates.

Thanks for updates. (I need to add a Review comment so I get a checkpoint to track further updates.)

Next batch of comments ...

Updates look good - thanks.

I think I have nothing further in terms of the review process. Great work!

Marked as reviewed by dholmes (Reviewer).

Marked as reviewed by dholmes (Reviewer).

> The tid is cached in the JavaThread object under _lock_id. It is set on JavaThread creation and changed on mount/unmount.

Why do we need to cache it? Is it the implicit barriers related to accessing the `threadObj` oop each time?

Keeping this value up-to-date is a part I find quite confusing.

src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:

> 2380:   __ bind(after_transition);
> 2381: 
> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {

It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?

src/hotspot/share/classfile/javaClasses.cpp line 2082:

> 2080: }
> 2081: 
> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) {

Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?

I'm struggling to understand how a thread can already be on this list?

src/hotspot/share/classfile/javaClasses.cpp line 2086:

> 2084:   jboolean vthread_on_list = Atomic::load(addr);
> 2085:   if (!vthread_on_list) {
> 2086:     vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE);

It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions?

src/hotspot/share/classfile/javaClasses.cpp line 2107:

> 2105: 
> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
> 2107:   return vthread->long_field(_timeout_offset);

Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

src/hotspot/share/code/nmethod.cpp line 711:

> 709:   // handle the case of an anchor explicitly set in continuation code that doesn't have a callee
> 710:   JavaThread* thread = reg_map->thread();
> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

Suggestion:

  if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) 
      JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

src/hotspot/share/prims/jvm.cpp line 4012:

> 4010:     }
> 4011:     ThreadBlockInVM tbivm(THREAD);
> 4012:     parkEvent->park();

What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:

> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
> 888:   } else {
> 889:     // frame can't be freezed. Most likely the call_stub or upcall_stub

Suggestion:

    // Frame can't be frozen. Most likely the call_stub or upcall_stub

src/hotspot/share/runtime/javaThread.hpp line 165:

> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporal value.

Suggestion:

  // attached thread cases where this field can have a temporary value.

Presumably this is for when the attaching thread is executing the Thread constructor?

src/hotspot/share/runtime/javaThread.hpp line 166:

> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporary value. Also,
> 166:   // calls to VirtualThread.switchToCarrierThread will temporary change _vthread

s/temporary change/temporarily change/

src/hotspot/share/runtime/objectMonitor.cpp line 132:

> 130: 
> 131: // -----------------------------------------------------------------------------
> 132: // Theory of operations -- Monitors lists, thread residency, etc:

This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage

src/hotspot/share/runtime/objectMonitor.cpp line 1140:

> 1138: }
> 1139: 
> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) {

Explanatory comment would be good - thanks.

src/hotspot/share/runtime/objectMonitor.cpp line 1532:

> 1530:   } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) {
> 1531:     // Virtual thread case.
> 1532:     Trigger->unpark();

So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed?

src/hotspot/share/runtime/objectMonitor.cpp line 1673:

> 1671: 
> 1672:   ContinuationEntry* ce = current->last_continuation();
> 1673:   if (interruptible && ce != nullptr && ce->is_virtual_thread()) {

So IIUC this use of `interruptible` would be explained as follows:

// Some calls to wait() occur in contexts that still have to pin a vthread to its carrier.
// All such contexts perform non-interruptible waits, so by checking `interruptible` we know 
// this is a regular Object.wait call.

src/hotspot/share/runtime/objectMonitor.cpp line 1706:

> 1704:     // on _WaitSetLock so it's not profitable to reduce the length of the
> 1705:     // critical section.
> 1706: 

Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't.

src/hotspot/share/runtime/objectMonitor.cpp line 2028:

> 2026:   // First time we run after being preempted on Object.wait().
> 2027:   // Check if we were interrupted or the wait timed-out, and in
> 2028:   // that case remove ourselves from the _WaitSet queue.

I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.

src/hotspot/share/runtime/objectMonitor.cpp line 2054:

> 2052:   // Mark that we are at reenter so that we don't call this method again.
> 2053:   node->_at_reenter = true;
> 2054:   assert(!has_owner(current), "invariant");

The position of this assert seems odd as it seems to be something that should hold at entry to this method.

src/hotspot/share/runtime/objectMonitor.hpp line 47:

> 45: // ParkEvent instead.  Beware, however, that the JVMTI code
> 46: // knows about ObjectWaiters, so we'll have to reconcile that code.
> 47: // See next_waiter(), first_waiter(), etc.

This to-do is likely no longer relevant with the current changes.

src/hotspot/share/runtime/objectMonitor.hpp line 174:

> 172: 
> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor

Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??

src/hotspot/share/runtime/objectMonitor.hpp line 207:

> 205: 
> 206:   static void Initialize();
> 207:   static void Initialize2();

Please add comment why this needs to be deferred - and till after what?

src/hotspot/share/runtime/objectMonitor.hpp line 288:

> 286:   // Returns true if this OM has an owner, false otherwise.
> 287:   bool      has_owner() const;
> 288:   int64_t   owner() const;  // Returns null if DEFLATER_MARKER is observed.

null is not an int64_t value.

src/hotspot/share/runtime/objectMonitor.hpp line 292:

> 290: 
> 291:   static int64_t owner_for(JavaThread* thread);
> 292:   static int64_t owner_for_oop(oop vthread);

Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?

src/hotspot/share/runtime/objectMonitor.hpp line 299:

> 297:   // Simply set _owner field to new_value; current value must match old_value.
> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 299:   // Same as above but uses tid of current as new value.

By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?

src/hotspot/share/runtime/objectMonitor.hpp line 302:

> 300:   // Simply set _owner field to new_value; current value must match old_value.
> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);

Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.

src/hotspot/share/runtime/objectMonitor.hpp line 302:

> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
> 302:   void      set_owner_from_BasicLock(JavaThread* current);

Shouldn't tid there be the basicLock?

src/hotspot/share/runtime/objectMonitor.hpp line 303:

> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 303:   // Simply set _owner field to current; current value must match basic_lock_p.

Comment is no longer accurate

src/hotspot/share/runtime/objectMonitor.hpp line 309:

> 307:   // _owner field. Returns the prior value of the _owner field.
> 308:   int64_t   try_set_owner_from_raw(int64_t old_value, int64_t new_value);
> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);

Similar to set_owner* need better comments describing API.

src/hotspot/share/runtime/objectMonitor.hpp line 311:

> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
> 310: 
> 311:   bool      is_succesor(JavaThread* thread);

I think `has_successor` is more appropriate here as it is not the monitor that is the successor.

src/hotspot/share/runtime/objectMonitor.hpp line 312:

> 310:   void      set_successor(JavaThread* thread);
> 311:   void      set_successor(oop vthread);
> 312:   void      clear_successor();

Needs descriptive comments, or at least a preceding comment explaining what a "successor" is.

src/hotspot/share/runtime/objectMonitor.hpp line 315:

> 313:   void      set_succesor(oop vthread);
> 314:   void      clear_succesor();
> 315:   bool      has_succesor();

Sorry but `successor` has two `s` before `or`.

src/hotspot/share/runtime/objectMonitor.hpp line 317:

> 315:   bool      has_succesor();
> 316: 
> 317:   bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); }

Again `has_owner` seems more appropriate

src/hotspot/share/runtime/objectMonitor.hpp line 323:

> 321:   }
> 322: 
> 323:   bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }

Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner.

src/hotspot/share/runtime/objectMonitor.hpp line 333:

> 331:   bool is_stack_locker(JavaThread* current);
> 332:   BasicLock* stack_locker() const;
> 333:   void set_stack_locker(BasicLock* locker);

Again `is` versus `has`, plus some general comments describing the API.

src/hotspot/share/runtime/objectMonitor.hpp line 334:

> 332: 
> 333:   // Returns true if BasicLock* stored in _stack_locker
> 334:   // points to current's stack, false othwerwise.

Suggestion:

  // points to current's stack, false otherwise.

src/hotspot/share/runtime/objectMonitor.hpp line 349:

> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }

This no longer looks correct if the waiter is a vthread. ??

src/hotspot/share/runtime/objectMonitor.inline.hpp line 110:

> 108: }
> 109: 
> 110: // Returns null if DEFLATER_MARKER is observed.

Comment needs updating

src/hotspot/share/runtime/objectMonitor.inline.hpp line 130:

> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise.
> 129: // This accessor is called when we really need to know if the owner
> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick.

Comment needs updating

src/hotspot/share/runtime/synchronizer.cpp line 670:

> 668:   // Top native frames in the stack will not be seen if we attempt
> 669:   // preemption, since we start walking from the last Java anchor.
> 670:   NoPreemptMark npm(current);

Don't we still pin for JNI monitor usage?

src/hotspot/share/runtime/synchronizer.cpp line 1440:

> 1438: }
> 1439: 
> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {

`inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?

src/hotspot/share/runtime/synchronizer.hpp line 172:

> 170: 
> 171:   // Iterate ObjectMonitors where the owner is thread; this does NOT include
> 172:   // ObjectMonitors where owner is set to a stack lock address in thread.

Comment needs updating

src/hotspot/share/runtime/threadIdentifier.cpp line 30:

> 28: 
> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp
> 30: static const int64_t INITIAL_TID = 3;

Can we express this in terms of those reserved values, or are they inaccessible?

src/hotspot/share/services/threadService.cpp line 467:

> 465:         if (waitingToLockMonitor->has_owner()) {
> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
> 467:           // If currentThread is nullptr we would like to know if the owner

Suggestion:

          // If currentThread is null we would like to know if the owner

src/hotspot/share/services/threadService.cpp line 474:

> 472:           // vthread we never record this as a deadlock. Note: unless there
> 473:           // is a bug in the VM, or a thread exits without releasing monitors
> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.

Suggestion:

          // acquired through JNI, null should imply an unmounted vthread owner.

src/java.base/share/classes/java/lang/Object.java line 383:

> 381:             try {
> 382:                 wait0(timeoutMillis);
> 383:             } catch (InterruptedException e) {

I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us.

src/java.base/share/classes/java/lang/Thread.java line 654:

> 652:      * {@link Thread#PRIMORDIAL_TID}&nbsp;+1 as this class cannot be used during
> 653:      * early startup to generate the identifier for the primordial thread. The
> 654:      * counter is off-heap and shared with the VM to allow it assign thread

Suggestion:

     * counter is off-heap and shared with the VM to allow it to assign thread

src/java.base/share/classes/java/lang/Thread.java line 655:

> 653:      * early startup to generate the identifier for the primordial thread. The
> 654:      * counter is off-heap and shared with the VM to allow it assign thread
> 655:      * identifiers to non-Java threads.

Why do non-JavaThreads need an identifier of this kind?

src/java.base/share/classes/java/lang/Thread.java line 731:

> 729: 
> 730:         if (attached && VM.initLevel() < 1) {
> 731:             this.tid = 3;  // primordial thread

The comment before the `ThreadIdentifiers` class needs updating to account for this change.

src/java.base/share/classes/java/lang/VirtualThread.java line 109:

> 107:      *
> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter

Should this say something similar to the parked case, about the "yield" being successful?

src/java.base/share/classes/java/lang/VirtualThread.java line 110:

> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue

Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry?

src/java.base/share/classes/java/lang/VirtualThread.java line 111:

> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter

Presumably this one means it acquired the monitor?

src/java.base/share/classes/java/lang/VirtualThread.java line 115:

> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
> 114:      *   WAITING -> WAITED         // waiting on monitor
> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner

Waiting to re-enter the monitor?

src/java.base/share/classes/java/lang/VirtualThread.java line 178:

> 176:     // timed-wait support
> 177:     private long waitTimeout;
> 178:     private byte timedWaitNonce;

Strange name - what does this mean?

src/java.base/share/classes/java/lang/VirtualThread.java line 530:

> 528:                 && carrier == Thread.currentCarrierThread();
> 529:         carrier.setCurrentThread(carrier);
> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread

I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??

src/java.base/share/classes/java/lang/VirtualThread.java line 631:

> 629:         // Object.wait
> 630:         if (s == WAITING || s == TIMED_WAITING) {
> 631:             byte nonce;

Suggestion:

            byte seqNo;

src/java.base/share/classes/java/lang/VirtualThread.java line 948:

> 946:      * This method does nothing if the thread has been woken by notify or interrupt.
> 947:      */
> 948:     private void waitTimeoutExpired(byte nounce) {

I assume you meant `nonce` here, but please change to `seqNo`.

src/java.base/share/classes/java/lang/VirtualThread.java line 952:

> 950:         for (;;) {
> 951:             boolean unblocked = false;
> 952:             synchronized (timedWaitLock()) {

Where is the overall design of the timed-wait protocol and it use of synchronization described?

src/java.base/share/classes/java/lang/VirtualThread.java line 1397:

> 1395: 
> 1396:     /**
> 1397:      * Returns a lock object to coordinating timed-wait setup and timeout handling.

Suggestion:

     * Returns a lock object for coordinating timed-wait setup and timeout handling.

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

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2384039238
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2387241944
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393910702
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2393922768
Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2406338095
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2409348761
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2417279456
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431004707
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818251880
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815838204
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815839094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827128518
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815840245
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814306675
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344054
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805616004
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814260043
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815985700
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815998417
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816002660
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816009160
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816014286
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816017269
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816018848
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810025380
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815956322
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816040287
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810027786
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810029858
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811912133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810032387
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811913172
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810033016
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810035434
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810037658
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815959203
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810036007
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810041017
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810046285
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810049295
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811914377
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815960013
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815967260
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815969101
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816043275
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816047142
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816041444
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810068395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825344940
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825345446
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814294622
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814158735
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814159210
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810076019
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810111255
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113028
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810113953
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810114488
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810116177
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810131339
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814169150
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814170953
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814171503
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814172621

From vlivanov at openjdk.org  Wed Nov  6 17:39:32 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:32 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>

On Sun, 29 Sep 2024 04:21:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Some time ago, there was a relevant experiment to optimize vectorized Poly1305 implementation by utilizing VPMULDQ instruction on x86 (see [JDK-8219881](https://bugs.openjdk.org/browse/JDK-8219881) for details). The implementation used int-to-long vector casts and produced the following IR shape: `MulVL (VectorCastI2X src1) (VectorCastI2X src2)`. Does it make sense to cover it as part of this particular enhancement?

IMO until C2 type system starts to track bitwise constant information ([JDK-8001436](https://bugs.openjdk.org/browse/JDK-8001436) et al), there are not enough benefits to rely on IGVN here. So far, all the discussed patterns are simple enough for matcher to handle them without too much tweaking.

Also, I briefly looked at #21599 in the context of this particular enhancement, but still don't see how it can improve the situation (except input rewiring part) and not simply duplicate what matcher already does well.

src/hotspot/share/opto/vectornode.cpp line 2122:

> 2120:     // MulL (URShift SRC1 , 32) (URShift SRC2, 32)
> 2121:     // MulL (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
> 2122:     // MulL ( And  SRC1,  0xFFFFFFFF) (URShift SRC2 , 32)

I don't understand how it works... According to the documentation, `VPMULDQ`/`VPMULUDQ` consume vectors of double words and produce a vector of quadwords. But it looks like `SRC1`/`SRC2` are always vectors of longs (quadwords). And `vmuludq_reg` in `x86.ad` just takes the immedate operands and pass them into `vpmuludq` which doesn't look right...

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2412582542
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421529658
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2436531693
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805886268

From coleenp at openjdk.org  Wed Nov  6 17:39:52 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:39:52 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

I've done a first pass over the first commit and have some comments and questions.

Round 2.  There are a lot of very helpful comments in the new code to explain what it's doing but I have some requests for some more.  And some questions.

Some more comments and questions on the latest commit, mostly minor.

I've traced through the runtime code (minus calculations for continuations) and found some typos on the way.  Excellent piece of work.

> Then I looked at typing up the thread / lock ids as an enum class https://github.com/openjdk/jdk/commit/34221f4a50a492cad4785cfcbb4bef8fa51d6f23

Both of these suggested changes should be discussed as different RFEs.  I don't really like this ThreadID change because it seems to introduce casting everywhere.

Noticed while downloading this that some copyrights need updating.

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:

> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
> 135:   *lspp = f.unextended_sp() - f.fp();

Can you write a comment what this is doing briefly and why?

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:

> 1548: #endif /* ASSERT */
> 1549: 
> 1550:   push_cont_fastpath();

One of the callers of this gives a clue what it does.

  __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about

Why do you do this here?  Oh please more comments...

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354:

> 5352:   str(rscratch2, dst);
> 5353:   Label ok;
> 5354:   tbz(rscratch2, 63, ok);

63?  Does this really need to have underflow checking?  That would alleviate the register use concerns if it didn't.  And it's only for legacy locking which should be stable until it's removed.

src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:

> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
> 2032:     __ push_cont_fastpath();

We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 2629:

> 2627:   addi(temp, displaced_header, in_bytes(ObjectMonitor::owner_offset()) - markWord::monitor_value);
> 2628:   Register thread_id = displaced_header;
> 2629:   ld(thread_id, in_bytes(JavaThread::lock_id_offset()), R16_thread);

Maybe to make things really clear, you could call this thread_lock_id ?  Seems to be used consistently as thread_id in much of the platform code.

src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231:

> 229: 
> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) {
> 231:   Address dst = Address(xthread, JavaThread::held_monitor_count_offset());

Address dst(xthread, JavaThread::held_monitor_count_offset());

src/hotspot/share/interpreter/oopMapCache.cpp line 268:

> 266:   }
> 267: 
> 268:   int num_oops() { return _num_oops; }

I can't find what uses this from OopMapCacheEntry.

src/hotspot/share/oops/stackChunkOop.inline.hpp line 189:

> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const {
> 188:   ObjectWaiter* waiter = object_waiter();
> 189:   if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) {

Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; }

Not sure what this is excluding.

src/hotspot/share/runtime/continuation.cpp line 89:

> 87:       // we would incorrectly throw it during the unmount logic in the carrier.
> 88:       if (_target->has_async_exception_condition()) {
> 89:         _failed = false;

This says "Don't" but then failed is false which doesn't make sense.  Should it be true?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:

> 1273: 
> 1274:   if (caller.is_interpreted_frame()) {
> 1275:     _total_align_size += frame::align_wiggle;

Please put a comment here about frame align-wiggle.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278:

> 1276:   }
> 1277: 
> 1278:   patch(f, hf, caller, false /*is_bottom_frame*/);

I also forgot what patch does.  Can you add a comment here too?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550:

> 1548:   assert(!cont.is_empty(), "");
> 1549:   // This is done for the sake of the enterSpecial frame
> 1550:   StackWatermarkSet::after_unwind(thread);

Is there a new place for this StackWatermark code?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657:

> 1655: }
> 1656: 
> 1657: template<typename ConfigT, bool preempt>

This function is kind of big, do we really want it duplicated to pass preempt as a template parameter?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235:

> 2233:       assert(!mon_acquired || mon->has_owner(_thread), "invariant");
> 2234:       if (!mon_acquired) {
> 2235:         // Failed to aquire monitor. Return to enterSpecial to unmount again.

typo: acquire

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492:

> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) {
> 2491:   ContinuationWrapper::SafepointOp so(current, _cont);
> 2492:   // Since we might safepoint set the anchor so that the stack can we walked.

typo: can be walked

src/hotspot/share/runtime/javaThread.cpp line 2002:

> 2000: #ifdef SUPPORT_MONITOR_COUNT
> 2001: 
> 2002: #ifdef LOOM_MONITOR_SUPPORT

If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ?

src/hotspot/share/runtime/javaThread.hpp line 334:

> 332:   bool                  _pending_jvmti_unmount_event;    // When preempting we post unmount event at unmount end rather than start
> 333:   bool                  _on_monitor_waited_event;        // Avoid callee arg processing for enterSpecial when posting waited event
> 334:   ObjectMonitor*        _contended_entered_monitor;      // Monitor por pending monitor_contended_entered callback

typo: Monitor **for** pending_contended_entered callback

src/hotspot/share/runtime/objectMonitor.cpp line 416:

> 414:     set_owner_from_BasicLock(cur, current);  // Convert from BasicLock* to Thread*.
> 415:     return true;
> 416:   }

Not needed? Oh I see, BasicLock is now in stack_locker.

src/hotspot/share/runtime/objectMonitor.cpp line 876:

> 874:   // and in doing so avoid some transitions ...
> 875: 
> 876:   // For virtual threads that are pinned do a timed-park instead, to

I had trouble parsing this first sentence.  I think it needs a comma after pinned and remove the comma after instead.

src/hotspot/share/runtime/objectMonitor.cpp line 1014:

> 1012:   assert_mark_word_consistency();
> 1013:   UnlinkAfterAcquire(current, currentNode);
> 1014:   if (is_succesor(current)) clear_succesor();

successor has two 's'.

src/hotspot/share/runtime/objectMonitor.cpp line 1158:

> 1156:     if (LockingMode != LM_LIGHTWEIGHT && current->is_lock_owned((address)cur)) {
> 1157:       assert(_recursions == 0, "invariant");
> 1158:       set_owner_from_BasicLock(cur, current);  // Convert from BasicLock* to Thread*.

This is nice you don't have to do this anymore.

src/hotspot/share/runtime/objectMonitor.cpp line 2305:

> 2303: }
> 2304: 
> 2305: void ObjectMonitor::Initialize2() {

Can you put a comment why there's a second initialize function?  Presumably after some state is set.

src/hotspot/share/runtime/objectMonitor.hpp line 43:

> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
> 43: // See next_waiter(), first_waiter(), etc.

Also a nice cleanup.  Did you reconcile the JVMTI code?

src/hotspot/share/runtime/objectMonitor.hpp line 71:

> 69:   bool is_wait()           { return _is_wait; }
> 70:   bool notified()          { return _notified; }
> 71:   bool at_reenter()        { return _at_reenter; }

should these be const member functions?

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2386614214
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2390813935
PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2396572570
Marked as reviewed by coleenp (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2405734604
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2430528701
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442058307
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813899129
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814081166
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811590155
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814084085
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811591482
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811595282
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817407075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823088425
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814905064
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815015410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815016232
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815245735
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815036910
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823233359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823252062
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811611376
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823091373
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811613400
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815445109
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811614453
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817415918
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815479877
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817419797
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420178

From qamai at openjdk.org  Wed Nov  6 17:39:33 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:33 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.42e3469d-3de0-4cc5-afd9-cca9cbd4d4a3@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.42e3469d-3de0-4cc5-afd9-cca9cbd4d4a3@github.com>
Message-ID: <HvR4CCPeXXjDit9Tz6g71KbKIoPkXtJo0h5d4iQLD44=.a3e17877-0041-4548-ac15-0320c27e31f1@github.com>

On Tue, 15 Oct 2024 17:00:26 GMT, Jasmine Karthikeyan <jkarthikeyan at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> I'm pretty ambivalent, I think implementing it either way would be alright. Especially with unit tests, I think the lowering implementation wouldn't be that difficult. Maybe another reviewer has an opinion?
> 
> About PhaseLowering though, I've found some more interesting things we could do with it, especially with improving vectorization support in the backend. @merykitty have you already started to work on it? I was thinking about prototyping it soon. Just wanted to make sure we're not doing the same work twice :)

@jaskarth Please proceed with it, I have a really simple prototype for it but I don't have any plan to proceed further soon. Thanks a lot :)

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2414605470

From jbhateja at openjdk.org  Wed Nov  6 17:39:33 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:33 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
Message-ID: <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>

On Tue, 15 Oct 2024 00:28:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> MulVL (VectorCastI2X src1) (VectorCastI2X src2

It looks unsafe to me, since VectorCastI2L sign-extends integer lanes, thus we may not be able to neglect partial products of upper doublewords while performing 64x64 bit multiplication. Existing patterns guarantees clearing of upper double words thereby result computation only depends on lower doubleword multiplication.  

> Personally, I think this optimization is not essential, so we should proceed with introducing lowering first, then add this transformation to that phase, instead of trying to integrate this transformation then refactor it into phase lowering, which seems like a net extra step.

I think we should not block inflight patches in anticipation of new refactoring. We can always tune it later. 

> I'm pretty ambivalent, I think implementing it either way would be alright. Especially with unit tests, I think the lowering implementation wouldn't be that difficult. Maybe another reviewer has an opinion?
> 
> About PhaseLowering though, I've found some more interesting things we could do with it, especially with improving vectorization support in the backend. @merykitty have you already started to work on it? I was thinking about prototyping it soon. Just wanted to make sure we're not doing the same work twice :)

It will be good to float an RFP with some use-cases upfront before development. As @jaskarth pointed out some vectorization improvements.

> IMO until C2 type system starts to track bitwise constant information ([JDK-8001436](https://bugs.openjdk.org/browse/JDK-8001436) et al), there are not enough benefits to rely on IGVN here. So far, all the discussed patterns are simple enough for matcher to handle them without too much tweaking.

Hi @iwanowww , 
I have implemented additional pattern you suggested.
In addition re-wiring pattern inputs to MulVL IR to avoid emitting upper doubleword clearing logic in applicable scenarios. 

Hi @jaskarth , @merykitty ,
As discussed, waiting on PhaseLowering skeleton to move some part of this patch to x86 specific lowering pass.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2420384086
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2423716135

From fbredberg at openjdk.org  Wed Nov  6 17:39:53 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:39:53 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Been learning a ton by reading the code changes and questions/answers from/to others.
But I still have some questions (and some small suggestions).

I'm done reviewing this piece of good-looking code, and I really enjoyed it. Thanks!

src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945:

> 943: 
> 944:   void inc_held_monitor_count();
> 945:   void dec_held_monitor_count();

I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. 

Suggestion:

  void inc_held_monitor_count(Register tmp);
  void dec_held_monitor_count(Register tmp);

src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740:

> 738: void MacroAssembler::clobber_nonvolatile_registers() {
> 739:   BLOCK_COMMENT("clobber nonvolatile registers {");
> 740:   Register regs[] = {

Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory.
Suggestion:

  static const Register regs[] = {

src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:

> 271:         ? frame_sp + fsize - frame::sender_sp_offset
> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
> 273:         : *(intptr_t**)(hf.sp() - 2);

Suggestion:

        : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);

src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793:

> 791: 
> 792:   void inc_held_monitor_count(Register tmp = t0);
> 793:   void dec_held_monitor_count(Register tmp = t0);

I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC.
Suggestion:

  void inc_held_monitor_count(Register tmp);
  void dec_held_monitor_count(Register tmp);

src/hotspot/share/runtime/continuation.cpp line 125:

> 123: };
> 124: 
> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) {

I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`.
Suggestion:

static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) {

src/hotspot/share/runtime/continuation.cpp line 135:

> 133: #endif // INCLUDE_JVMTI
> 134: 
> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) {

I think the code reads better if you change to `is_safe_to_preempt_vthread`.
Suggestion:

static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) {

src/hotspot/share/runtime/continuation.hpp line 66:

> 64: 
> 65:   enum preempt_kind {
> 66:     freeze_on_monitorenter = 1,

Is there a reason why the first enumerator doesn't start at zero?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:

> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
> 888:   } else {
> 889:     return freeze_pinned_native;

Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me.

src/hotspot/share/runtime/objectMonitor.cpp line 1193:

> 1191:   }
> 1192: 
> 1193:   assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, "");

In `ObjectMonitor::resume_operation()` the exact same line is a  `guarantee`- not an `assert`-line, is there any reason why?

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2404133418
Marked as reviewed by fbredberg (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410872086
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822551094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822696920
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822200193
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822537887
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824253403
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824255622
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824262945
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824405820
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824676122

From vlivanov at openjdk.org  Wed Nov  6 17:39:34 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:34 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>
Message-ID: <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.72ed3669-99d5-416a-81a9-65ba3919e9c7@github.com>

On Thu, 17 Oct 2024 19:40:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> MulVL (VectorCastI2X src1) (VectorCastI2X src2)

> It looks unsafe to me, since VectorCastI2L sign-extends integer lanes, ...

Hm, I don't see any problems with it if `VPMULDQ` is used. Sign extension becomes redundant when 64-bit multiplication is strength-reduced to 32-bit one (32x32->64). Am I missing something important here?

>> IMO until C2 type system starts to track bitwise constant information ([JDK-8001436](https://bugs.openjdk.org/browse/JDK-8001436) et al), there are not enough benefits to rely on IGVN here. So far, all the discussed patterns are simple enough for matcher to handle them without too much tweaking.
>
> Hi @iwanowww , 
> I have implemented additional pattern you suggested.
> In addition re-wiring pattern inputs to MulVL IR to avoid emitting upper doubleword clearing logic in applicable scenarios. 
> 
> Hi @jaskarth , @merykitty ,
> As discussed, waiting on PhaseLowering skeleton to move some part of this patch to x86 specific lowering pass.

Thanks, @jatin-bhateja. I took a look at the latest version and still think that IGVN is not the best place for it. 

First of all, flags on MulVL feel too adhoc and irregular. The original IR structure is still there (except the cases when inputs are rewired), so can be easily recomputed on demand.

I noticed that the patterns can be generalized: what matters is whether upper half is filled with zeros/sign bits or not, so small enough masks (and large enough shifts) are amenable to the same optimization. But, in such case, input rewiring becomes applicable only to particular constant inputs.

(BTW signed right shifts can be optimized in a similar way, since they populate upper half with the sign-bit.)

So, IMO the best way to move this particular enhancement forward is:
* perform the transformation during matching;
* match a single MulVL node and shape the checks on argument shape as predicates on AD instructions 
   * setting lower instruction costs should tell the matcher to prefer new specific instructions over generic ones;
* avoid input rewiring for now (VPMULDQ/VPMULUDQ give enough performance improvement on its own).

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2420668490
PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2436528498

From dlong at openjdk.org  Wed Nov  6 17:39:59 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:39:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Marked as reviewed by dlong (Reviewer).

> On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic.

During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub.  In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled.

Looking at this reminds me of a paper I read a long time ago, "Using continuations to implement thread management and communication in operating systems" (https://dl.acm.org/doi/10.1145/121133.121155).

For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java.  Is there a way to fix that?

I finished looking at this, and it looks good.  Nice work!

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188:

> 186:   // Avoid using a leave instruction when this frame may
> 187:   // have been frozen, since the current value of rfp
> 188:   // restored from the stub would be invalid. We still

It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI.  If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
Do we actually need FP set by the enter() prologue for stubs?  If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs.  We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.

src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191:

> 189:   // must restore the rfp value saved on enter though.
> 190:   if (use_pop) {
> 191:     ldp(rfp, lr, Address(post(sp, 2 * wordSize)));

leave() also calls authenticate_return_address(), which I assume we still want to call here.
How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`?

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133:

> 131: 
> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) {
> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");

Suggestion:

  assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame");

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:

> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
> 135:   *lspp = f.unextended_sp() - f.fp();

Suggestion:

  f.interpreter_frame_set_last_sp(f.unextended_sp());

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:

> 157: 
> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).

Suggestion:

  // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).

Isn't that 2 words, not 3?

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:

> 308:     sp -= 2;
> 309:     sp[-2] = sp[0];
> 310:     sp[-1] = sp[1];

This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?

src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338:

> 336:   // Make sure that extended_sp is kept relativized.
> 337:   DEBUG_ONLY(Method* m = hf.interpreter_frame_method();)
> 338:   DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata()

Isn't m->size_of_parameters() always correct?  Why is wait0 a special case?

src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:

> 75:     // Interpreter frames
> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only

This conflicts with sender_sp_offset.  Doesn't that cause a problem?

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:

> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 1554:   adr(rscratch1, resume_pc);
> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));

Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.

src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:

> 1565: 
> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
> 1567:   bind(resume_pc);

If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?

src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:

> 117:   return  mask.num_oops()
> 118:         + 1 // for the mirror oop
> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot

Where is this temp oop slot set and used?

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351:

> 1349:   // set result handler
> 1350:   __ mov(result_handler, r0);
> 1351:   __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize));

I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere.  I think this deserves a comment.

src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509:

> 1507:     Label no_oop;
> 1508:     __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
> 1509:     __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize));

We only need this when preempted, right?  So could this be moved into the block above, where we call restore_after_resume()?

src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223:

> 221: }
> 222: 
> 223: void StubAssembler::epilogue(bool use_pop) {

Is there a better name we could use, like `trust_fp` or `after_resume`?

src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643:

> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) {
> 642: #ifdef _LP64
> 643:   return r15_off / 2;

I think using r15_offset_in_bytes() would be less confusing.

src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324:

> 322:   movq(scrReg, tmpReg);
> 323:   xorq(tmpReg, tmpReg);
> 324:   movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset()));

I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt.

src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146:

> 144:   // Make sure that locals is already relativized.
> 145:   DEBUG_ONLY(Method* m = f.interpreter_frame_method();)
> 146:   DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;)

What is the + 2 for?  Is the check for is_native because of wait0?  Please add a comment what this line is doing.

src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:

> 357:   push_cont_fastpath();
> 358: 
> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.

>From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.

src/hotspot/cpu/x86/interp_masm_x86.cpp line 361:

> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 360:   lea(rscratch1, resume_pc);
> 361:   push(rscratch1);

Suggestion:

  push(rscratch1);  // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:

> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
> 3795:   __ testbool(rscratch1);
> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);

If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?

src/hotspot/share/c1/c1_Runtime1.hpp line 138:

> 136:   static void initialize_pd();
> 137: 
> 138:   static uint runtime_blob_current_thread_offset(frame f);

I think this returns an offset in wordSize units, but it's not documented.  In some places we always return an offset in bytes and let the caller convert.

src/hotspot/share/code/nmethod.cpp line 712:

> 710:   JavaThread* thread = reg_map->thread();
> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp())
> 712:       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

I'm guessing this is because JVMTI can cause a safepoint?  This might need a comment.

src/hotspot/share/code/nmethod.cpp line 1302:

> 1300:     _compiler_type           = type;
> 1301:     _orig_pc_offset          = 0;
> 1302:     _num_stack_arg_slots     = 0;

Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.

src/hotspot/share/oops/method.cpp line 870:

> 868: }
> 869: 
> 870: bool Method::is_object_wait0() const {

It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here.

src/hotspot/share/oops/stackChunkOop.inline.hpp line 255:

> 253:                          RegisterMap::WalkContinuation::include);
> 254:     full_map.set_include_argument_oops(false);
> 255:     closure->do_frame(f, map);

This could use a comment.  I guess we weren't looking at the stub frame before, only the caller.  Why is this using `map` instead of `full_map`?

src/hotspot/share/prims/jvmtiEnv.cpp line 1363:

> 1361:   }
> 1362: 
> 1363:   if (LockingMode == LM_LEGACY && java_thread == nullptr) {

Do we need to check for `java_thread == nullptr` for other locking modes?

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602:

> 1600:           // If the thread was found on the ObjectWaiter list, then
> 1601:           // it has not been notified.
> 1602:           Handle th(current_thread, w->threadObj());

Why use get_vthread_or_thread_oop() above but threadObj()?  It probably needs a comment.

src/hotspot/share/runtime/continuation.hpp line 50:

> 48: class JavaThread;
> 49: 
> 50: // should match Continuation.toPreemptStatus() in Continuation.java

I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match.

src/hotspot/share/runtime/continuation.hpp line 50:

> 48: class JavaThread;
> 49: 
> 50: // should match Continuation.PreemptStatus() in Continuation.java

As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.

src/hotspot/share/runtime/continuationEntry.cpp line 51:

> 49:   _return_pc = nm->code_begin() + _return_pc_offset;
> 50:   _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset;
> 51:   _cleanup_pc = nm->code_begin() + _cleanup_offset;

I don't see why we need these relative offsets.  Instead of doing

_thaw_call_pc_offset = __ pc() - start;

why not do

_thaw_call_pc = __ pc();

The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316:

> 314:     pc = ContinuationHelper::return_address_at(
> 315:            sp - frame::sender_sp_ret_address_offset());
> 316:   }

You could do this with an overload instead:

static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) {
  assert(pc != nullptr, "");
  [...]
}
static void set_anchor(JavaThread* thread, intptr_t* sp) {
  address pc = ContinuationHelper::return_address_at(
    sp - frame::sender_sp_ret_address_offset());
  set_anchor(thread, sp, pc);
}

but the compiler probably optmizes the above check just fine.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696:

> 694:   // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments.
> 695:   // They'll then be stored twice: in the chunk and in the parent chunk's top frame
> 696:   const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack;

`cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once.  Would it make sense to add a helper function named something like `total_cont_size()`?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063:

> 1061:   unwind_frames();
> 1062: 
> 1063:   chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words);

It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size).  I wonder if there is a way to simply these adjustments.  Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:

> 1409:     // zero out fields (but not the stack)
> 1410:     const size_t hs = oopDesc::header_size();
> 1411:     oopDesc::set_klass_gap(mem, 0);

Why, bug fix or cleanup?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659:

> 1657:   int i = 0;
> 1658:   for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) {
> 1659:     if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) {

OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842:

> 1840:   size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast
> 1841:   size += 2*frame::align_wiggle; // in case of alignments at the top and bottom
> 1842:   size += frame::metadata_words; // for preemption case (see possibly_adjust_frame)

So this means it's OK to over-estimate the size here?

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045:

> 2043:     // If we don't thaw the top compiled frame too, after restoring the saved
> 2044:     // registers back in Java, we would hit the return barrier to thaw one more
> 2045:     // frame effectively overwritting the restored registers during that call.

Suggestion:

    // frame effectively overwriting the restored registers during that call.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062:

> 2060:   }
> 2061: 
> 2062:   f.next(SmallRegisterMap::instance, true /* stop */);

Suggestion:

  f.next(SmallRegisterMap::instance(), true /* stop */);

This looks like a typo, so I wonder how it compiled.  I guess template magic is hiding it.

src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650:

> 2648:     _cont.tail()->do_barriers<stackChunkOopDesc::BarrierType::Store>(_stream, &map);
> 2649:   } else {
> 2650:     _stream.next(SmallRegisterMap::instance);

Suggestion:

    _stream.next(SmallRegisterMap::instance());

src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189:

> 187: 
> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) {
> 189:   return Atomic::load(chunk->field_addr<uint8_t>(_lockStackSize_offset));

If these accesses need to be atomic, could you add a comment explaining why?

src/hotspot/share/runtime/deoptimization.cpp line 125:

> 123: 
> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) {
> 125:   if (!nm->can_be_deoptimized()) {

Is this a performance optimization?

src/hotspot/share/runtime/objectMonitor.cpp line 1612:

> 1610: 
> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) {
> 1612:   // Since we might safepoint set the anchor so that the stack can we walked.

I was assuming the anchor would have been restored to what it was at preemption time.  What is the state of the anchor at resume time, and is it documented anywhere?
I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here.

src/hotspot/share/runtime/objectMonitor.inline.hpp line 44:

> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) {
> 43:   int64_t tid = thread->lock_id();
> 44:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");

Should the "3" be a named constant with a comment?

src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:

> 205: }
> 206: 
> 207: inline bool ObjectMonitor::has_successor() {

Why are _succ accesses atomic here when previously they were not?

src/hotspot/share/runtime/vframe.cpp line 289:

> 287:       current >= f.interpreter_frame_monitor_end();
> 288:       current = f.previous_monitor_in_interpreter_frame(current)) {
> 289:       oop owner = !heap_frame ? current->obj() : StackValue::create_stack_value_from_oop_location(stack_chunk(), (void*)current->obj_adr())->get_obj()();

It looks like we don't really need the StackValue.  We might want to make it possible to call oop_from_oop_location() directly.

src/hotspot/share/runtime/vframe.inline.hpp line 130:

> 128:       // Waited event after target vthread was preempted. Since all continuation frames
> 129:       // are freezed we get the top frame from the stackChunk instead.
> 130:       _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map);

What happens if we don't do this?  That might help explain why we are doing this.

src/hotspot/share/services/threadService.cpp line 467:

> 465:         if (waitingToLockMonitor->has_owner()) {
> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
> 467:         }

Please explain why it is safe to remvoe the above code.

src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108:

> 106:         processDeregisterQueue();
> 107: 
> 108:         if (Thread.currentThread().isVirtual()) {

It looks like we have two implementations, depending on if the current thread is virtual or not.  The two implementations differ in the way they signal interrupted.  Can we unify the two somehow?

src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:

> 55:     static {
> 56:         try {
> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);

Why is this needed?  A comment would help.

test/hotspot/gtest/nmt/test_vmatree.cpp line 34:

> 32: 
> 33: using Tree = VMATree;
> 34: using TNode = Tree::TreapNode;

Why is this needed?

test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42:

> 40:  *                   -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep
> 41:  *                   -XX:CompileCommand=exclude,java.lang.Thread::afterSleep
> 42:  *                   -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos

I'm guessing these changes have something to do with JDK-8279653?

test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73:

> 71: /* ========================================================================== */
> 72: 
> 73: static int prepare(JNIEnv* jni) {

Is this a bug fix?

test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30:

> 28:  *         by reflection API
> 29:  * @library /test/lib/
> 30:  * @requires vm.compMode != "Xcomp"

If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix.

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2410825883
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2439180320
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442765996
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2448962446
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2452534349
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817461936
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817426321
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817439076
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817437593
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817441437
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817464371
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817465037
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819964369
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817537666
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817539657
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817549144
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819973901
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820002377
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819979640
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819982432
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821434823
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819763504
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819996648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821706030
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817552633
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819981522
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821503185
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821506576
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821558267
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821571623
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594124
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821601480
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821617785
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821746421
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821623432
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821628036
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821632152
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821636581
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821644040
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821653194
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821656267
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821755997
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821670778
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821685316
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823640621
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823644339
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580051
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823663674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823665393
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825045757
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825050976
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825054769
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825111095
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825097245
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825109698
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107638
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817413638

From amitkumar at openjdk.org  Wed Nov  6 17:39:59 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 6 Nov 2024 17:39:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <jj6iCskb42eGr6L5b_roCs03SXecaECIHTT5TRMmOHg=.fa6f1075-44c4-467e-b760-fced28ad2499@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Hi @pchilano, 

I see couple of failures on s390x, can you apply this patch: 


diff --git a/src/hotspot/cpu/s390/macroAssembler_s390.cpp b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
index f342240f3ca..d28b4579824 100644
--- a/src/hotspot/cpu/s390/macroAssembler_s390.cpp
+++ b/src/hotspot/cpu/s390/macroAssembler_s390.cpp
@@ -3492,7 +3492,7 @@ void MacroAssembler::increment_counter_eq(address counter_address, Register tmp1
 void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_lock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp1;
@@ -3566,8 +3566,8 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
   // If csg succeeds then CR=EQ, otherwise, register zero is filled
   // with the current owner.
   z_lghi(zero, 0);
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_csg(zero, Z_R1_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_csg(zero, Z_R0_scratch, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner), monitor_tagged);
 
   // Store a non-null value into the box.
   z_stg(box, BasicLock::displaced_header_offset_in_bytes(), box);
@@ -3576,7 +3576,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 
   BLOCK_COMMENT("fast_path_recursive_lock {");
   // Check if we are already the owner (recursive lock)
-  z_cgr(Z_R1_scratch, zero); // owner is stored in zero by "z_csg" above
+  z_cgr(Z_R0_scratch, zero); // owner is stored in zero by "z_csg" above
   z_brne(done); // not a recursive lock
 
   // Current thread already owns the lock. Just increment recursion count.
@@ -3594,7 +3594,7 @@ void MacroAssembler::compiler_fast_lock_object(Register oop, Register box, Regis
 void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Register temp1, Register temp2) {
 
   assert(LockingMode != LM_LIGHTWEIGHT, "uses fast_unlock_lightweight");
-  assert_different_registers(oop, box, temp1, temp2);
+  assert_different_registers(oop, box, temp1, temp2, Z_R0_scratch);
 
   Register displacedHeader = temp1;
   Register currentHeader   = temp2;
@@ -3641,8 +3641,8 @@ void MacroAssembler::compiler_fast_unlock_object(Register oop, Register box, Reg
   // Handle existing monitor.
   bind(object_has_monitor);
 
-  z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-  z_cg(Z_R1_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
+  z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+  z_cg(Z_R0_scratch, Address(currentHeader, OM_OFFSET_NO_MONITOR_VALUE_TAG(owner)));
   z_brne(done);
 
   BLOCK_COMMENT("fast_path_recursive_unlock {");
@@ -6164,7 +6164,7 @@ void MacroAssembler::lightweight_unlock(Register obj, Register temp1, Register t
 }
 
 void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Register box, Register tmp1, Register tmp2) {
-  assert_different_registers(obj, box, tmp1, tmp2);
+  assert_different_registers(obj, box, tmp1, tmp2, Z_R0_scratch);
 
   // Handle inflated monitor.
   NearLabel inflated;
@@ -6296,12 +6296,12 @@ void MacroAssembler::compiler_fast_lock_lightweight_object(Register obj, Registe
     // If csg succeeds then CR=EQ, otherwise, register zero is filled
     // with the current owner.
     z_lghi(zero, 0);
-    z_l(Z_R1_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
-    z_csg(zero, Z_R1_scratch, owner_address);
+    z_lg(Z_R0_scratch, Address(Z_thread, JavaThread::lock_id_offset()));
+    z_csg(zero, Z_R0_scratch, owner_address);
     z_bre(monitor_locked);
 
     // Check if recursive.
-    z_cgr(Z_R1_scratch, zero); // zero contains the owner from z_csg instruction
+    z_cgr(Z_R0_scratch, zero); // zero contains the owner from z_csg instruction
     z_brne(slow_path);
 
     // Recursive


CC: @RealLucy

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

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2414585800

From vlivanov at openjdk.org  Wed Nov  6 17:39:34 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:34 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <HvR4CCPeXXjDit9Tz6g71KbKIoPkXtJo0h5d4iQLD44=.a3e17877-0041-4548-ac15-0320c27e31f1@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <F4-hAQ2RV1B2lq0I9A6NJwOnw6N7LP1MWMvtdgDoy2E=.42e3469d-3de0-4cc5-afd9-cca9cbd4d4a3@github.com>
 <HvR4CCPeXXjDit9Tz6g71KbKIoPkXtJo0h5d4iQLD44=.a3e17877-0041-4548-ac15-0320c27e31f1@github.com>
Message-ID: <b9wBuOTqWnB5l-dL9OOuVx8cOsPa7yPb1rtOJrjjyfU=.328949e8-83d9-49bd-86a9-e286790cf479@github.com>

On Tue, 15 Oct 2024 17:26:49 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> I'm pretty ambivalent, I think implementing it either way would be alright. Especially with unit tests, I think the lowering implementation wouldn't be that difficult. Maybe another reviewer has an opinion?
>> 
>> About PhaseLowering though, I've found some more interesting things we could do with it, especially with improving vectorization support in the backend. @merykitty have you already started to work on it? I was thinking about prototyping it soon. Just wanted to make sure we're not doing the same work twice :)
>
> @jaskarth Please proceed with it, I have a really simple prototype for it but I don't have any plan to proceed further soon. Thanks a lot :)

@merykitty The approach @jatin-bhateja proposes looks well-justified to me. Matching is essentially a lowering step which transforms platform-independent Ideal IR into platform-specific Mach IR. And collapsing non-trivial IR trees into platform-specific instructions is a well-established pattern in the code.

Indeed, there are some constraints matching imposes, so it may not be flexible enough to cover all use cases. In particular, for `VPTERNLOGD`/`VPTERNLOGQ` it was decided it's worth the effort to handle them specially (see `Compile::optimize_logic_cones()`). As it is implemented now, it's part of the shared code, but if there's platform-specific custom lowering phase available one day, it can be moved there, of course.

But speaking of `VPMULDQ`/`VPMULUDQ`, what kind of benefits do you see from custom logic to support them?

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2420732705

From jbhateja at openjdk.org  Wed Nov  6 17:39:34 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:34 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.72ed3669-99d5-416a-81a9-65ba3919e9c7@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>
 <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.72ed3669-99d5-416a-81a9-65ba3919e9c7@github.com>
Message-ID: <v-weAyRxbDmC2JXt5IDP-cS2LurHrhu-1dsoPoRd7R0=.6cdb02ed-e654-43b5-935a-762a1a7feb9c@github.com>

On Thu, 17 Oct 2024 21:53:16 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> > > MulVL (VectorCastI2X src1) (VectorCastI2X src2)
> 
> > It looks unsafe to me, since VectorCastI2L sign-extends integer lanes, ...
> 
> Hm, I don't see any problems with it if `VPMULDQ` is used. Sign extension becomes redundant when 64-bit multiplication is strength-reduced to 32-bit one (32x32->64). Am I missing something important here?

@iwanowww , Agree!, I missed noticing that you were talking about **VPMULDQ**, its a  signed doubleword multiplier with quadword saturation, so it should be ok to include suggested pattern.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421132055

From aph at openjdk.org  Wed Nov  6 17:40:00 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>     * We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.

This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible.

src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:

> 58: 
> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);

Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:

> 5339: 
> 5340: void MacroAssembler::inc_held_monitor_count() {
> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Suggestion:

// Clobbers: rscratch1 and rscratch2
void MacroAssembler::inc_held_monitor_count() {
  Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357:

> 5355: 
> 5356: void MacroAssembler::dec_held_monitor_count() {
> 5357:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Suggestion:

// Clobbers: rscratch1 and rscratch2
void MacroAssembler::dec_held_monitor_count() {
  Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2429587519
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810966647
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810987929
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810989022

From jbhateja at openjdk.org  Wed Nov  6 17:39:36 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:36 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
Message-ID: <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>

On Fri, 18 Oct 2024 02:41:47 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> The issues I have with this patch are that:
> 
> * It convolutes the graph with machine-dependent nodes early in the compiling process.

MulVL is a machine independent IR, we create a machine dependent IR post matching.

> * It overloads `MulVL` with alternative behaviours, it is fine now as we do not perform much analysis on this node but it would be problematic later. I think it is more preferable to have a separate IR node for this like `MulVLowIToLNode`, or have this transformation be done only just before matching, or both.

I see this is as a twostep optimization, in the first step we do analysis and annotate additional information on existing IR, which is later used by instruction selector.  I plan to subsume first stage with enhanced dataflow analysis going forward.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421300738

From alanb at openjdk.org  Wed Nov  6 17:40:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <ekXIc0jjx_4MlD-GhPzW5S5LA4GARcY2WSXvLmnRl04=.11a33af1-6caf-476f-a30f-38a15fc188d5@github.com>

On Tue, 22 Oct 2024 15:23:50 GMT, Andrew Haley <aph at openjdk.org> wrote:

> This last sentence has interesting consequences for user-defined schedulers. Would it make sense to throw an exception if a carrier thread is holding a monitor while mounting a virtual thread? Doing that would also have the advantage of making some kinds of deadlock impossible.

There's nothing exposed today to allow custom schedulers. The experiments/explorations going on right now have to be careful to not hold any locks. Throwing if holding a monitor is an option but only it would need to be backed by spec and would also shine light on the issue of j.u.concurrent locks as a carrier might independently hold a lock there too.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2431600434

From vlivanov at openjdk.org  Wed Nov  6 17:39:36 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:36 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
Message-ID: <34KZVRjCMAl5-KAG6hLnJUe2RZF2fThQAWuresTL5Pk=.a797f2d0-2915-4175-8c7c-3381fdc578cb@github.com>

On Fri, 18 Oct 2024 04:16:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> It convolutes the graph with machine-dependent nodes early in the compiling process.

Ah, I see your point now! I took a closer look at the patch and indeed `MulVLNode::_mult_lower_double_word` with `MulVLNode::Ideal()` don't look pretty. @jatin-bhateja why don't you turn the logic it into match rules instead?

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421372120

From coleenp at openjdk.org  Wed Nov  6 17:40:00 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
Message-ID: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>

On Wed, 23 Oct 2024 06:15:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Why do we need to cache it? Is it the implicit barriers related to accessing the threadObj oop each time?

We cache threadObj.thread_id in JavaThread::_lock_id so that the fast path c2_MacroAssembler code has one less load and code to find the offset of java.lang.Thread.threadId in the code.  Also, yes, we were worried about performance of the barrier in this path.

> src/hotspot/share/runtime/objectMonitor.hpp line 174:
> 
>> 172: 
>> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
>> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor
> 
> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??

I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id.


$ grep -r JFR_THREAD_ID
jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread))
jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id())
runtime/objectMonitor.cpp:    _previous_owner_tid = JFR_THREAD_ID(current);
runtime/objectMonitor.cpp:    iterator->_notifier_tid = JFR_THREAD_ID(current);
runtime/vmThread.cpp:  event->set_caller(JFR_THREAD_ID(op->calling_thread()));

> src/hotspot/share/runtime/synchronizer.cpp line 1440:
> 
>> 1438: }
>> 1439: 
>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {
> 
> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?

If it's always the current thread, then it should be called 'current' imo.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2433252605
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816550112
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816551794

From qamai at openjdk.org  Wed Nov  6 17:39:37 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:37 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
Message-ID: <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.94bb0177-364b-4013-a673-654f28be0135@github.com>

On Fri, 18 Oct 2024 04:16:15 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> I see this is as a twostep optimization, in the first step we do analysis and annotate additional information on existing IR, which is later used by instruction selector. I plan to subsume first stage with enhanced dataflow analysis going forward.

The issue is that a node is not immutable. This puts a burden on every place to keep the annotation sane when doing transformations, which is easily missed when there are a lot of kinds of `Node`s out there. That's why I think it is most suitable to be done only right before matching. `Node::Ideal` is invoked in a really generous manner so I would prefer not to add analysis to it that can be done more efficiently somewhere else. Additionally, if you have a separate IR node for this operation, you can do some more beneficial transformations such as `MulVL (AndV x max_juint) (AndV y max_juint)` into `MulVLowIToL x y`.

My suggestions are based on this PR as a standalone, so they may not be optimal when looking at a wider perspective, in case you think this approach would fit more nicely into a larger landscape of your planned enhancements please let us know. Thanks for your patience.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421376285

From mchung at openjdk.org  Wed Nov  6 17:40:00 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <FkxtznpxqChlt5BT4JAL3tkjv7vJu-QBC7sBeCg8wQc=.a602c21c-088a-4728-bd13-aaf8b348a3bb@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

I looked at java.lang.ref and java.lang.invoke changes.   ReferenceQueue was reverted back to use synchronized and also adding the code disable/enable preemption looks right.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438401789

From vlivanov at openjdk.org  Wed Nov  6 17:39:37 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:37 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.94bb0177-364b-4013-a673-654f28be0135@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.94bb0177-364b-4013-a673-654f28be0135@github.com>
Message-ID: <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.baae1153-9407-49ac-b993-99d29c0c2f97@github.com>

On Fri, 18 Oct 2024 05:05:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> The issue is that a node is not immutable.

I don't see any issues with mutability here. `MulVLNode::_mult_lower_double_word` is constant, so you have to allocate new node if you want to change its value. (And that's exactly what `MulVLNode::Ideal()` does.) But I agree with you that  a dedicated ideal node type (e.g., `MulVI2L`) is much cleaner than `MulVLNode::_mult_lower_double_word`. Still, I'd prefer to see the logic confined in matcher-related code instead.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421412061

From bpb at openjdk.org  Wed Nov  6 17:40:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <ZjehOI9RwnlCQfoK6WlUYkqoqU3nW6c8f80l0pSZ1YQ=.0a867f4a-3c4e-4aaf-9117-791a34392108@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

The `InternalLock` and `ByteArrayOutputStream` changes look all right. I'll follow up with [JDK-8343039](https://bugs.openjdk.org/browse/JDK-8343039) once this PR for [JEP 491](https://openjdk.org/jeps/491) is integrated.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2438461962

From qamai at openjdk.org  Wed Nov  6 17:39:37 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:37 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.baae1153-9407-49ac-b993-99d29c0c2f97@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.94bb0177-364b-4013-a673-654f28be0135@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.baae1153-9407-49ac-b993-99d29c0c2f97@github.com>
Message-ID: <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.56a0093d-676b-428c-90c5-32e51f69839d@github.com>

On Fri, 18 Oct 2024 05:16:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> I see this is as a twostep optimization, in the first step we do analysis and annotate additional information on existing IR, which is later used by instruction selector. I plan to subsume first stage with enhanced dataflow analysis going forward.
>> 
>> The issue is that a node is not immutable. This puts a burden on every place to keep the annotation sane when doing transformations, which is easily missed when there are a lot of kinds of `Node`s out there. That's why I think it is most suitable to be done only right before matching. `Node::Ideal` is invoked in a really generous manner so I would prefer not to add analysis to it that can be done more efficiently somewhere else. Additionally, if you have a separate IR node for this operation, you can do some more beneficial transformations such as `MulVL (AndV x max_juint) (AndV y max_juint)` into `MulVLowIToL x y`.
>> 
>> My suggestions are based on this PR as a standalone, so they may not be optimal when looking at a wider perspective, in case you think this approach would fit more nicely into a larger landscape of your planned enhancements please let us know. Thanks for your patience.
>
>> The issue is that a node is not immutable.
> 
> I don't see any issues with mutability here. `MulVLNode::_mult_lower_double_word` is constant, so you have to allocate new node if you want to change its value. (And that's exactly what `MulVLNode::Ideal()` does.) But I agree with you that  a dedicated ideal node type (e.g., `MulVI2L`) is much cleaner than `MulVLNode::_mult_lower_double_word`. Still, I'd prefer to see the logic confined in matcher-related code instead.

@iwanowww IMO there are 2 ways to view this:

- You can see a `MulVL` nodes with `_mult_lower_double_word` being an entirely different kind of nodes which do a different thing (a.k.a throw away the upper bits and only multiply the lower bits), in this case it is a machine-dependent IR node hiding behind the opcode of `MulVL` and changing the inputs of it is not worrying because the node does not care about that anyway, its semantics is predetermined already.
- Or you can see `_mult_lower_double_word` being an annotation that adds information to `MulVL`, which means it is still a `MulVL` but annotated with information saying that all upper bits of the operands are 0. I think this is Jatin's point of view right now. The issue here would be to keep the annotation sane when the node inputs may be changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421441405

From pchilanomate at openjdk.org  Wed Nov  6 17:40:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>

On Sat, 26 Oct 2024 02:15:29 GMT, Dean Long <dlong at openjdk.org> wrote:

> > On failure to acquire a monitor inside `ObjectMonitor::enter` a virtual thread will call freeze to copy all Java frames to the heap. We will add the virtual thread to the ObjectMonitor's queue and return back to Java. Instead of continue execution in Java though, the virtual thread will jump to a preempt stub which will clear the frames copied from the physical stack, and will return to `Continuation.run()` to proceed with the unmount logic.
> 
> During this time, the Java frames are not changing, so it seems like it doesn't matter if the freeze/copy happens immediately or after we unwind the native frames and enter the preempt stub. In fact, it seems like it could be more efficient to delay the freeze/copy, given the fact that the preemption can be canceled.
>
The problem is that freezing the frames can fail. By then we would have already added the ObjectWaiter as representing a virtual thread. Regarding efficiency (and ignoring the previous issue) both approaches would be equal anyways, since regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.

>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>
Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough.

> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 191:
> 
>> 189:   // must restore the rfp value saved on enter though.
>> 190:   if (use_pop) {
>> 191:     ldp(rfp, lr, Address(post(sp, 2 * wordSize)));
> 
> leave() also calls authenticate_return_address(), which I assume we still want to call here.
> How about adding an optional parameter to leave() that will skip the problematic `mov(sp, rfp)`?

Right. I added it here for now to follow the same style in all platforms.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 133:
> 
>> 131: 
>> 132: inline void FreezeBase::prepare_freeze_interpreted_top_frame(const frame& f) {
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
> 
> Suggestion:
> 
>   assert(f.interpreter_frame_last_sp() == nullptr, "should be null for top frame");

Changed, here and in the other platforms.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:
> 
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
>> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
>> 135:   *lspp = f.unextended_sp() - f.fp();
> 
> Suggestion:
> 
>   f.interpreter_frame_set_last_sp(f.unextended_sp());

Changed, here and in the other platforms.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
> 
>> 157: 
>> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
>> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).
> 
> Suggestion:
> 
>   // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).
> 
> Isn't that 2 words, not 3?

The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347
I don't know why we do that for 64 bits.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 338:
> 
>> 336:   // Make sure that extended_sp is kept relativized.
>> 337:   DEBUG_ONLY(Method* m = hf.interpreter_frame_method();)
>> 338:   DEBUG_ONLY(int extra_space = m->is_object_wait0() ? m->size_of_parameters() : 0;) // see comment in relativize_interpreted_frame_metadata()
> 
> Isn't m->size_of_parameters() always correct?  Why is wait0 a special case?

There are two cases where the interpreter native wrapper frame is freezed: synchronized native method, and `Object.wait()`. The extra push of the parameters to the stack is done after we synchronize on the method, so it only applies to `Object.wait()`.

> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:
> 
>> 75:     // Interpreter frames
>> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
>> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only
> 
> This conflicts with sender_sp_offset.  Doesn't that cause a problem?

No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.

> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1351:
> 
>> 1349:   // set result handler
>> 1350:   __ mov(result_handler, r0);
>> 1351:   __ str(r0, Address(rfp, frame::interpreter_frame_result_handler_offset * wordSize));
> 
> I'm guessing this is here because preemption doesn't save/restore registers, even callee-saved registers, so we need to save this somewhere.  I think this deserves a comment.

Added comment.

> src/hotspot/cpu/aarch64/templateInterpreterGenerator_aarch64.cpp line 1509:
> 
>> 1507:     Label no_oop;
>> 1508:     __ adr(t, ExternalAddress(AbstractInterpreter::result_handler(T_OBJECT)));
>> 1509:     __ ldr(result_handler, Address(rfp, frame::interpreter_frame_result_handler_offset*wordSize));
> 
> We only need this when preempted, right?  So could this be moved into the block above, where we call restore_after_resume()?

Moved.

> src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 643:
> 
>> 641: uint Runtime1::runtime_blob_current_thread_offset(frame f) {
>> 642: #ifdef _LP64
>> 643:   return r15_off / 2;
> 
> I think using r15_offset_in_bytes() would be less confusing.

I copied the same comments the other platforms have to make it more clear.

> src/hotspot/cpu/x86/continuationFreezeThaw_x86.inline.hpp line 146:
> 
>> 144:   // Make sure that locals is already relativized.
>> 145:   DEBUG_ONLY(Method* m = f.interpreter_frame_method();)
>> 146:   DEBUG_ONLY(int max_locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + 2;)
> 
> What is the + 2 for?  Is the check for is_native because of wait0?  Please add a comment what this line is doing.

It's for the 2 extra words for native methods (temp oop/result handler). Added comment.

> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:
> 
>> 357:   push_cont_fastpath();
>> 358: 
>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
> 
> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.

Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it:  https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658

> src/hotspot/cpu/x86/interp_masm_x86.cpp line 361:
> 
>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 360:   lea(rscratch1, resume_pc);
>> 361:   push(rscratch1);
> 
> Suggestion:
> 
>   push(rscratch1);  // call_VM_helper requires last_Java_pc for anchor to be at the top of the stack

Added it as a note with the comment above.

> src/hotspot/share/c1/c1_Runtime1.hpp line 138:
> 
>> 136:   static void initialize_pd();
>> 137: 
>> 138:   static uint runtime_blob_current_thread_offset(frame f);
> 
> I think this returns an offset in wordSize units, but it's not documented.  In some places we always return an offset in bytes and let the caller convert.

Added comment.

> src/hotspot/share/code/nmethod.cpp line 712:
> 
>> 710:   JavaThread* thread = reg_map->thread();
>> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp())
>> 712:       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {
> 
> I'm guessing this is because JVMTI can cause a safepoint?  This might need a comment.

I added a comment already in `vthread_monitor_waited_event()` in ObjectMonitor.cpp. I think it's better placed there.

> src/hotspot/share/code/nmethod.cpp line 1302:
> 
>> 1300:     _compiler_type           = type;
>> 1301:     _orig_pc_offset          = 0;
>> 1302:     _num_stack_arg_slots     = 0;
> 
> Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.

We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.

> src/hotspot/share/oops/method.cpp line 870:
> 
>> 868: }
>> 869: 
>> 870: bool Method::is_object_wait0() const {
> 
> It might be worth mentioning that is not a general-purpose API, so we don't have to worry about false positives here.

Right, I added a check for the klass too.

> src/hotspot/share/oops/stackChunkOop.inline.hpp line 255:
> 
>> 253:                          RegisterMap::WalkContinuation::include);
>> 254:     full_map.set_include_argument_oops(false);
>> 255:     closure->do_frame(f, map);
> 
> This could use a comment.  I guess we weren't looking at the stub frame before, only the caller.  Why is this using `map` instead of `full_map`?

The full map gets only populated once we get the sender. We only need it when processing the caller which needs to know where each register was spilled since it might contain an oop.

> src/hotspot/share/prims/jvmtiEnv.cpp line 1363:
> 
>> 1361:   }
>> 1362: 
>> 1363:   if (LockingMode == LM_LEGACY && java_thread == nullptr) {
> 
> Do we need to check for `java_thread == nullptr` for other locking modes?

No, both LM_LIGHTWEIGHT and LM_MONITOR have support for virtual threads. LM_LEGACY doesn't, so if the virtual thread is unmounted we know there is no monitor information to collect.

> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1602:
> 
>> 1600:           // If the thread was found on the ObjectWaiter list, then
>> 1601:           // it has not been notified.
>> 1602:           Handle th(current_thread, w->threadObj());
> 
> Why use get_vthread_or_thread_oop() above but threadObj()?  It probably needs a comment.

We already filtered virtual threads above so no point in calling get_vthread_or_thread_oop() again. They will actually return the same result though.

> src/hotspot/share/runtime/continuation.hpp line 50:
> 
>> 48: class JavaThread;
>> 49: 
>> 50: // should match Continuation.toPreemptStatus() in Continuation.java
> 
> I can't find Continuation.toPreemptStatus() and the enum in Continuation.java doesn't match.

Should be just PreemptStatus. Fixed.

> src/hotspot/share/runtime/continuation.hpp line 50:
> 
>> 48: class JavaThread;
>> 49: 
>> 50: // should match Continuation.PreemptStatus() in Continuation.java
> 
> As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.

`PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.

> src/hotspot/share/runtime/continuationEntry.cpp line 51:
> 
>> 49:   _return_pc = nm->code_begin() + _return_pc_offset;
>> 50:   _thaw_call_pc = nm->code_begin() + _thaw_call_pc_offset;
>> 51:   _cleanup_pc = nm->code_begin() + _cleanup_offset;
> 
> I don't see why we need these relative offsets.  Instead of doing
> 
> _thaw_call_pc_offset = __ pc() - start;
> 
> why not do
> 
> _thaw_call_pc = __ pc();
> 
> The only reason for the offsets would be if what gen_continuation_enter() generated was going to be relocated, but I don't think it is.

But these are generated in a temporary buffer. Until we call nmethod::new_native_nmethod() we won't know the final addresses.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 316:
> 
>> 314:     pc = ContinuationHelper::return_address_at(
>> 315:            sp - frame::sender_sp_ret_address_offset());
>> 316:   }
> 
> You could do this with an overload instead:
> 
> static void set_anchor(JavaThread* thread, intptr_t* sp, address pc) {
>   assert(pc != nullptr, "");
>   [...]
> }
> static void set_anchor(JavaThread* thread, intptr_t* sp) {
>   address pc = ContinuationHelper::return_address_at(
>     sp - frame::sender_sp_ret_address_offset());
>   set_anchor(thread, sp, pc);
> }
> 
> but the compiler probably optmizes the above check just fine.

Added an overload method.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 696:
> 
>> 694:   // in a fresh chunk, we freeze *with* the bottom-most frame's stack arguments.
>> 695:   // They'll then be stored twice: in the chunk and in the parent chunk's top frame
>> 696:   const int chunk_start_sp = cont_size() + frame::metadata_words + _monitors_in_lockstack;
> 
> `cont_size() + frame::metadata_words + _monitors_in_lockstack` is used more than once.  Would it make sense to add a helper function named something like `total_cont_size()`?

Maybe, but I only see it twice, not sure we gain much. Also we save having to jump back and forth to see what total_cont_size() would actually account for.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1063:
> 
>> 1061:   unwind_frames();
>> 1062: 
>> 1063:   chunk->set_max_thawing_size(chunk->max_thawing_size() + _freeze_size - _monitors_in_lockstack - frame::metadata_words);
> 
> It seems a little weird to subtract these here only to add them back in other places (see my comment above suggesting total_cont_size).  I wonder if there is a way to simply these adjustments.  Having to replicate _monitors_in_lockstack +- frame::metadata_words in lots of places seems error-prone.

The reason why this is added and later subtracted is because when allocating the stackChunk we need to account for all space needed, but when specifying how much space the vthread needs in the stack to allocate the frames we don't need to count _monitors_in_lockstack. I'd rather not group it with frame::metadata_words because these are logically different things. In fact, if we never subtract frame::metadata_words when setting max_thawing_size we should not need to account for it in thaw_size() (this is probably something we should clean up in the future). But for _monitors_in_lockstack we always need to subtract it to max_thawing_size.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1842:
> 
>> 1840:   size += frame::metadata_words; // For the top pc+fp in push_return_frame or top = stack_sp - frame::metadata_words in thaw_fast
>> 1841:   size += 2*frame::align_wiggle; // in case of alignments at the top and bottom
>> 1842:   size += frame::metadata_words; // for preemption case (see possibly_adjust_frame)
> 
> So this means it's OK to over-estimate the size here?

Yes, this will be the space allocated in the stack by the vthread when thawing.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2045:
> 
>> 2043:     // If we don't thaw the top compiled frame too, after restoring the saved
>> 2044:     // registers back in Java, we would hit the return barrier to thaw one more
>> 2045:     // frame effectively overwritting the restored registers during that call.
> 
> Suggestion:
> 
>     // frame effectively overwriting the restored registers during that call.

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2062:
> 
>> 2060:   }
>> 2061: 
>> 2062:   f.next(SmallRegisterMap::instance, true /* stop */);
> 
> Suggestion:
> 
>   f.next(SmallRegisterMap::instance(), true /* stop */);
> 
> This looks like a typo, so I wonder how it compiled.  I guess template magic is hiding it.

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2650:
> 
>> 2648:     _cont.tail()->do_barriers<stackChunkOopDesc::BarrierType::Store>(_stream, &map);
>> 2649:   } else {
>> 2650:     _stream.next(SmallRegisterMap::instance);
> 
> Suggestion:
> 
>     _stream.next(SmallRegisterMap::instance());

Fixed.

> src/hotspot/share/runtime/continuationJavaClasses.inline.hpp line 189:
> 
>> 187: 
>> 188: inline uint8_t jdk_internal_vm_StackChunk::lockStackSize(oop chunk) {
>> 189:   return Atomic::load(chunk->field_addr<uint8_t>(_lockStackSize_offset));
> 
> If these accesses need to be atomic, could you add a comment explaining why?

It is read concurrently by GC threads. Added comment.

> src/hotspot/share/runtime/deoptimization.cpp line 125:
> 
>> 123: 
>> 124: void DeoptimizationScope::mark(nmethod* nm, bool inc_recompile_counts) {
>> 125:   if (!nm->can_be_deoptimized()) {
> 
> Is this a performance optimization?

No, this might be a leftover. When working on the change for Object.wait I was looking at the deopt code and thought this check was missing. It seems most callers already filter this case except WB_DeoptimizeMethod.

> src/hotspot/share/runtime/objectMonitor.cpp line 1612:
> 
>> 1610: 
>> 1611: static void vthread_monitor_waited_event(JavaThread *current, ObjectWaiter* node, ContinuationWrapper& cont, EventJavaMonitorWait* event, jboolean timed_out) {
>> 1612:   // Since we might safepoint set the anchor so that the stack can we walked.
> 
> I was assuming the anchor would have been restored to what it was at preemption time.  What is the state of the anchor at resume time, and is it documented anywhere?
> I'm a little fuzzy on what frames are on the stack at this point, so I'm not sure if entry_sp and entry_pc are the best choice or only choice here.

The virtual thread is inside the thaw call here which is a leaf VM method, so there is no anchor. It is still in the mount transition before thawing frames. The top frame is Continuation.enterSpecial so that's what we set the anchor to.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 44:
> 
>> 42: inline int64_t ObjectMonitor::owner_from(JavaThread* thread) {
>> 43:   int64_t tid = thread->lock_id();
>> 44:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");
> 
> Should the "3" be a named constant with a comment?

Yes, changed to use ThreadIdentifier::initial().

> src/hotspot/share/runtime/vframe.inline.hpp line 130:
> 
>> 128:       // Waited event after target vthread was preempted. Since all continuation frames
>> 129:       // are freezed we get the top frame from the stackChunk instead.
>> 130:       _frame = Continuation::last_frame(java_lang_VirtualThread::continuation(_thread->vthread()), &_reg_map);
> 
> What happens if we don't do this?  That might help explain why we are doing this.

We would walk the carrier thread frames instead of the vthread ones.

> src/hotspot/share/services/threadService.cpp line 467:
> 
>> 465:         if (waitingToLockMonitor->has_owner()) {
>> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
>> 467:         }
> 
> Please explain why it is safe to remvoe the above code.

Yes, I should have added a comment here. The previous code assumed that if the monitor had an owner but it was not findable it meant the previous currentThread will be blocked permanently and so we recorded this as a deadlock. With these changes, the owner could be not findable because it is an unmounted vthread. There is currently no fast way to determine if that's the case so we never record this as a deadlock. Now, unless there is a bug in the VM, or a thread exits without releasing monitors acquired through JNI, unfindable owner should imply an unmounted vthread. I added a comment.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442387426
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819473410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819465574
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819592799
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819466532
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819472086
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819481705
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821393856
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591515
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593810
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821592920
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591143
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821593351
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823505700
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821591930
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821594779
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821595264
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695166
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821695964
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821697629
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698318
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821698705
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823509538
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821699155
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828187178
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823486049
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823487296
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823488795
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823511520
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823502075
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823503636
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824792648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793200
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824791832
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824793737
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825208611
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825210260

From dlong at openjdk.org  Wed Nov  6 17:40:00 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
Message-ID: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com>

On Mon, 28 Oct 2024 18:58:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.

Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption?  It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards?  We aren't doing the monitor check atomically, so the monitor could get released right after we check it.  So I'm guessing we choose to check after freeze because freeze has non-trivial overhead.

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 159:
>> 
>>> 157: 
>>> 158:   // The interpreter native wrapper code adds space in the stack equal to size_of_parameters()
>>> 159:   // after the fixed part of the frame. For wait0 this is equal to 3 words (this + long parameter).
>> 
>> Suggestion:
>> 
>>   // after the fixed part of the frame. For wait0 this is equal to 2 words (this + long parameter).
>> 
>> Isn't that 2 words, not 3?
>
> The timeout parameter is a long which we count as 2 words: https://github.com/openjdk/jdk/blob/0e3fc93dfb14378a848571a6b83282c0c73e690f/src/hotspot/share/runtime/signature.hpp#L347
> I don't know why we do that for 64 bits.

OK, I think there are historical or technical reasons why it's hard to change, because of the way the JVM spec is written.

>> src/hotspot/cpu/aarch64/frame_aarch64.hpp line 77:
>> 
>>> 75:     // Interpreter frames
>>> 76:     interpreter_frame_result_handler_offset          =  3, // for native calls only
>>> 77:     interpreter_frame_oop_temp_offset                =  2, // for native calls only
>> 
>> This conflicts with sender_sp_offset.  Doesn't that cause a problem?
>
> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.

`sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed.  Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"?

>> src/hotspot/cpu/x86/interp_masm_x86.cpp line 359:
>> 
>>> 357:   push_cont_fastpath();
>>> 358: 
>>> 359:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 
>> From the comment, it sounds like we want to set last_pc to resume_pc, but I don't see that happening.  The push/pop of rscratch1 doesn't seem to be doing anything.
>
> Method `MacroAssembler::call_VM_helper()` expects the current value at the top of the stack to be the last_java_pc. There is comment on that method explaining it:  https://github.com/openjdk/jdk/blob/60364ef0010bde2933c22bf581ff8b3700c4afd6/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1658

OK, I was looking for where it stores it in the anchor, but it doesn't, at least not until make_walkable() is called.

>> src/hotspot/share/code/nmethod.cpp line 1302:
>> 
>>> 1300:     _compiler_type           = type;
>>> 1301:     _orig_pc_offset          = 0;
>>> 1302:     _num_stack_arg_slots     = 0;
>> 
>> Was the old value wrong, unneeded, or is this set somewhere else?  If this field is not used, then we might want to set it to an illegal value in debug builds.
>
> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.

Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change?  I think this change should be reverted.  If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used.  However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right.

>> src/hotspot/share/runtime/continuation.hpp line 50:
>> 
>>> 48: class JavaThread;
>>> 49: 
>>> 50: // should match Continuation.PreemptStatus() in Continuation.java
>> 
>> As far as I can tell, these enum values still don't match the Java values.  If they need to match, then maybe there should be asserts that check that.
>
> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.

Yes, that would be better for now.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2442880740
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819705281
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821524020
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821705135
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823572138
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823584967

From jbhateja at openjdk.org  Wed Nov  6 17:39:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:38 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.baae1153-9407-49ac-b993-99d29c0c2f97@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.94bb0177-364b-4013-a673-654f28be0135@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.baae1153-9407-49ac-b993-99d29c0c2f97@github.com>
Message-ID: <TLmt4TKSzAFKntKnCqogV3l6Ulw3edvTy4MdpIY45J4=.85d3be35-6759-4002-9b89-1cf9e13ee954@github.com>

On Fri, 18 Oct 2024 05:16:04 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> I see this is as a twostep optimization, in the first step we do analysis and annotate additional information on existing IR, which is later used by instruction selector. I plan to subsume first stage with enhanced dataflow analysis going forward.
>> 
>> The issue is that a node is not immutable. This puts a burden on every place to keep the annotation sane when doing transformations, which is easily missed when there are a lot of kinds of `Node`s out there. That's why I think it is most suitable to be done only right before matching. `Node::Ideal` is invoked in a really generous manner so I would prefer not to add analysis to it that can be done more efficiently somewhere else. Additionally, if you have a separate IR node for this operation, you can do some more beneficial transformations such as `MulVL (AndV x max_juint) (AndV y max_juint)` into `MulVLowIToL x y`.
>> 
>> My suggestions are based on this PR as a standalone, so they may not be optimal when looking at a wider perspective, in case you think this approach would fit more nicely into a larger landscape of your planned enhancements please let us know. Thanks for your patience.
>
>> The issue is that a node is not immutable.
> 
> I don't see any issues with mutability here. `MulVLNode::_mult_lower_double_word` is constant, so you have to allocate new node if you want to change its value. (And that's exactly what `MulVLNode::Ideal()` does.) But I agree with you that  a dedicated ideal node type (e.g., `MulVI2L`) is much cleaner than `MulVLNode::_mult_lower_double_word`. Still, I'd prefer to see the logic confined in matcher-related code instead.

Hi @iwanowww , @merykitty , I am in process of addressing all your concerns.

I still feel idealization is the right place to execute this pattern detection, we just need to re-wire the effective inputs bypassing doubleword clearing logic to newly annotated MulVL node and allow clearing IR to sweepout during successive passes, moving it to final graph reshaping just before instruction selection will prevent dead IR cleanups.

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421448784

From vlivanov at openjdk.org  Wed Nov  6 17:39:38 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:38 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.56a0093d-676b-428c-90c5-32e51f69839d@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.94bb0177-364b-4013-a673-654f28be0135@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.baae1153-9407-49ac-b993-99d29c0c2f97@github.com>
 <SVdoVQi9Q1l8LumcqDLuPu6SDAwNtKnfqn5CQwXqfqs=.56a0093d-676b-428c-90c5-32e51f69839d@github.com>
Message-ID: <Ofu_nlH8iKfZiL5JtUW9exKSrpN0WGch40B7BCOCVU8=.c8e01155-1bdc-4d9a-9609-011d5088b908@github.com>

On Fri, 18 Oct 2024 05:35:27 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>>> The issue is that a node is not immutable.
>> 
>> I don't see any issues with mutability here. `MulVLNode::_mult_lower_double_word` is constant, so you have to allocate new node if you want to change its value. (And that's exactly what `MulVLNode::Ideal()` does.) But I agree with you that  a dedicated ideal node type (e.g., `MulVI2L`) is much cleaner than `MulVLNode::_mult_lower_double_word`. Still, I'd prefer to see the logic confined in matcher-related code instead.
>
> @iwanowww IMO there are 2 ways to view this:
> 
> - You can see a `MulVL` nodes with `_mult_lower_double_word` being an entirely different kind of nodes which do a different thing (a.k.a throw away the upper bits and only multiply the lower bits), in this case it is a machine-dependent IR node hiding behind the opcode of `MulVL` and changing the inputs of it is not worrying because the node does not care about that anyway, its semantics is predetermined already.
> - Or you can see `_mult_lower_double_word` being an annotation that adds information to `MulVL`, which means it is still a `MulVL` but annotated with information saying that all upper bits of the operands are 0. I think this is Jatin's point of view right now. The issue here would be to keep the annotation sane when the node inputs may be changed.

@merykitty I was under an erroneous impression that `MulVL::Ideal()` folds operands of particular shapes into `MulVL::_mult_lower_double_word == true`. Now I see it's not the case. Indeed, what `MulVL::Ideal()`  does is it caches the info about operand shapes in `MulVL::_mult_lower_double_word` which introduces unnecessary redundancy. I doubt it is possible for IR to diverge so much (through a sequence of equivalent transformations) that the bit gets out of sync (unless there's a bug in compiler or a paradoxical situation in effectively dead code occurs).

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421504978

From michaelm at openjdk.org  Wed Nov  6 17:40:00 2024
From: michaelm at openjdk.org (Michael McMahon)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <Q1jPK8TnNv45P679HTgjg5q6q7BtdKvBymZQv4GCAug=.f7b54ea3-c284-4745-b170-d1a4cb9e1758@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

I have reviewed the changes to the NIO selector/poller implementations and they look fine.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2444268747

From qamai at openjdk.org  Wed Nov  6 17:39:39 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:39 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <TLmt4TKSzAFKntKnCqogV3l6Ulw3edvTy4MdpIY45J4=.85d3be35-6759-4002-9b89-1cf9e13ee954@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <IRIUH1-sPcyIOtq6qXtYEwI4tonW25j2wyF6B-oSFfM=.b914a78d-91cf-423d-bd41-cad3469a30f5@github.com>
 <WNqn6OK-hY2C2_JuAv3wJZA6ozfNU6t3kv4rzg8gyEw=.a73c0a64-bbe1-4e9a-876a-14edfd969041@github.com>
 <bMRDppKISSHyOqnE-KAvQDcwYe604plwKEbT3Dcwe1o=.94bb0177-364b-4013-a673-654f28be0135@github.com>
 <mTQeIBW9q3Q26swunFRKeAbIQYJGlWPKt54WyINMUqc=.baae1153-9407-49ac-b993-99d29c0c2f97@github.com>
 <TLmt4TKSzAFKntKnCqogV3l6Ulw3edvTy4MdpIY45J4=.85d3be35-6759-4002-9b89-1cf9e13ee954@github.com>
Message-ID: <8p95gYaAnNAIfqVBosZgvMMCVhHn2M0fQx7FLLgCn9U=.852c7aef-327c-4c2f-a591-0efde9ccc2e6@github.com>

On Fri, 18 Oct 2024 05:42:21 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>>> The issue is that a node is not immutable.
>> 
>> I don't see any issues with mutability here. `MulVLNode::_mult_lower_double_word` is constant, so you have to allocate new node if you want to change its value. (And that's exactly what `MulVLNode::Ideal()` does.) But I agree with you that  a dedicated ideal node type (e.g., `MulVI2L`) is much cleaner than `MulVLNode::_mult_lower_double_word`. Still, I'd prefer to see the logic confined in matcher-related code instead.
>
> Hi @iwanowww , @merykitty , I am in process of addressing all your concerns.
> 
> I still feel idealization is the right place to execute this pattern detection, we just need to re-wire the effective inputs bypassing doubleword clearing logic to newly annotated MulVL node and allow clearing IR to sweepout during successive passes, moving it to final graph reshaping just before instruction selection will prevent dead IR cleanups.

@jatin-bhateja I think you can do it at the same place as `Compile::optimize_logic_cones`, we do perform IGVN there. Unless you think this information is needed early in the compiling process, currently I see it is used during matching only, which makes it unnecessary to repeatedly checking it in `Node::Ideal`

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2421519087

From pchilanomate at openjdk.org  Wed Nov  6 17:40:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
 <6dVwVwIL7UaAvf1KMrBnlgAqr0zn-qScNuB86a8PdFo=.b2d24f69-7fef-403c-97c0-2d1301d1995e@github.com>
Message-ID: <S0IfxODyOvrNooBjR0lhlgrGg1zHFmID_7LfL0W8uFo=.9da718f1-4d16-4333-a44f-81701e492657@github.com>

On Mon, 28 Oct 2024 23:46:09 GMT, Dean Long <dlong at openjdk.org> wrote:

> > regardless of when you freeze, while doing the freezing the monitor could have been released already. So trying to acquire the monitor after freezing can always succeed, which means we don't want to unmount but continue execution, i.e cancel the preemption.
> 
> Is this purely a performance optimization, or is there a correctness issue if we don't notice the monitor was released and cancel the preemption? It seems like the monitor can be released at any time, so what makes freeze special that we need to check afterwards? We aren't doing the monitor check atomically, so the monitor could get released right after we check it. So I'm guessing we choose to check after freeze because freeze has non-trivial overhead.
>
After adding the ObjectWaiter to the _cxq we always have to retry acquiring the monitor; this is the same for platform threads. So freezing before that, implies we have to retry. As for whether we need to cancel the preemption if we acquire the monitor, not necessarily. We could still unmount with a state of YIELDING, so the virtual thread will be scheduled to run again. So that part is an optimization to avoid the unmount.

>> No, it just happens to be stored at the sender_sp marker. We were already making room for two words but only using one.
>
> `sender_sp_offset` is listed under "All frames", but I guess that's wrong and should be changed.  Can we fix the comments to match x86, which lists this offset under "non-interpreter frames"?

I think aarch64 is the correct one. For interpreter frames we also have a sender_sp() that we get through that offset value: https://github.com/openjdk/jdk/blob/7404ddf24a162cff445cd0a26aec446461988bc8/src/hotspot/cpu/x86/frame_x86.cpp#L458
I think the confusion is because we also have interpreter_frame_sender_sp_offset where we store the unextended sp.

>> We read this value from the freeze/thaw code in several places. Since the only compiled native frame we allow to freeze is Object.wait0 the old value would be zero too. But I think the correct thing is to just set it to zero?always since a value > 0 is only meaningful for Java methods.
>
> Isn't it possible that we might allow more compiled native frames in the future, and then we would have to undo this change?  I think this change should be reverted.  If continuations code wants to assert that this is 0, then that should be in continuations code, the nmethod code doesn't need to know how this field is used.  However, it looks like continuations code is the only client of this field, so I can see how it would be tempting to just set it to 0 here, but it doesn't feel right.

Any compiled native frame would still require a value of zero. This field should be read as the size of the argument area in the caller frame that this method(callee) might access during execution. That's why we set it to zero for OSR nmethods too. The thaw code uses this value to see if we need to thaw a compiled frame with stack arguments that reside in the caller frame. The freeze code also uses it to check for overlap and avoid copying these arguments twice. Currently we have a case for "nmethods" when reading this value, which includes both Java and native. I'd rather not add branches to separate these cases, specially given that we already have this field available in the nmethod class.

>> `PreemptStatus` is meant to be used with `tryPreempt()` which is not implemented yet, i.e. there is no method yet that maps between these values and the PreemptStatus enum. The closest is `Continuation.pinnedReason` which we do use. So if you want I can remove the reference to PreemptStatus and use pinnedReason instead.
>
> Yes, that would be better for now.

Changed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2445106760
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823495787
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824785565
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824788898

From jkarthikeyan at openjdk.org  Wed Nov  6 17:39:39 2024
From: jkarthikeyan at openjdk.org (Jasmine Karthikeyan)
Date: Wed, 6 Nov 2024 17:39:39 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>
Message-ID: <w-7Yxd_RZKUTluxPjob1OJn0sQFFeSYEH_sVGVAKlrU=.d40a6c52-29af-48d8-b28e-acc8f1d64b89@github.com>

On Sat, 19 Oct 2024 09:25:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> IMO until C2 type system starts to track bitwise constant information ([JDK-8001436](https://bugs.openjdk.org/browse/JDK-8001436) et al), there are not enough benefits to rely on IGVN here. So far, all the discussed patterns are simple enough for matcher to handle them without too much tweaking.
>
> Hi @iwanowww , 
> I have implemented additional pattern you suggested.
> In addition re-wiring pattern inputs to MulVL IR to avoid emitting upper doubleword clearing logic in applicable scenarios. 
> 
> Hi @jaskarth , @merykitty ,
> As discussed, waiting on PhaseLowering skeleton to move some part of this patch to x86 specific lowering pass.

Hi @jatin-bhateja, I've opened a PR for the new pass here: #21599. I've added just the skeleton code, like you suggested. Let me know what you think!

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2425542577

From alanb at openjdk.org  Wed Nov  6 17:40:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>

On Thu, 31 Oct 2024 03:52:31 GMT, Dean Long <dlong at openjdk.org> wrote:

> For some reason github thinks VirtualThreadPinnedEvent.java was renamed to libSynchronizedNative.c and libTracePinnedThreads.c was renamed to LockingMode.java. Is there a way to fix that?

I don't know which view this is but just to say that VirtualThreadPinnedEvent.java and libTracePinnedThreads.c are removed. libSynchronizedNative.c is part of a new test (as it happens, it was previously reviewed as pull/18600 but we had to hold it back as it needed a fix from the loom repo that is part of the JEP 491 implementation). You find is easier to just fetch and checkout the branch to look at the changes locally. Personally I have this easier for large change and makes it easier to see renames and/or removals.

> src/java.base/linux/classes/sun/nio/ch/EPollSelectorImpl.java line 108:
> 
>> 106:         processDeregisterQueue();
>> 107: 
>> 108:         if (Thread.currentThread().isVirtual()) {
> 
> It looks like we have two implementations, depending on if the current thread is virtual or not.  The two implementations differ in the way they signal interrupted.  Can we unify the two somehow?

When executed on a platform thread is will block in epoll_wait or kqueue so it has to handle EINTR. It doesn't block in sys call when executed in a virtual thread. So very different implementations.

> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:
> 
>> 55:     static {
>> 56:         try {
>> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);
> 
> Why is this needed?  A comment would help.

That's probably a good idea.  It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority.

> test/hotspot/gtest/nmt/test_vmatree.cpp line 34:
> 
>> 32: 
>> 33: using Tree = VMATree;
>> 34: using TNode = Tree::TreapNode;
> 
> Why is this needed?

We had to rename the alias to avoid a conflict with the Node in compile.hpp. Just lucky not to run into this in main-line. It comes and goes, depends on changes to header files that are transitively included by the test. I think Johan had planned to change this in main line but it may have got forgotten.

> test/hotspot/jtreg/compiler/codecache/stress/OverloadCompileQueueTest.java line 42:
> 
>> 40:  *                   -XX:CompileCommand=exclude,java.lang.Thread::beforeSleep
>> 41:  *                   -XX:CompileCommand=exclude,java.lang.Thread::afterSleep
>> 42:  *                   -XX:CompileCommand=exclude,java.util.concurrent.TimeUnit::toNanos
> 
> I'm guessing these changes have something to do with JDK-8279653?

It should have been added when Thread.sleep was changed but we got lucky.

> test/hotspot/jtreg/serviceability/jvmti/events/MonitorContendedEnter/mcontenter01/libmcontenter01.cpp line 73:
> 
>> 71: /* ========================================================================== */
>> 72: 
>> 73: static int prepare(JNIEnv* jni) {
> 
> Is this a bug fix?

Testing ran into a couple of bugs in JVMTI tests. One of was tests that was stashing the JNIEnv into a static.

> test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30:
> 
>> 28:  *         by reflection API
>> 29:  * @library /test/lib/
>> 30:  * @requires vm.compMode != "Xcomp"
> 
> If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix.

JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again.  Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2449153774
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825115214
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825127591
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825121520
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825112326
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825110254
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817692430

From vlivanov at openjdk.org  Wed Nov  6 17:39:40 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:40 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.72ed3669-99d5-416a-81a9-65ba3919e9c7@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>
 <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.72ed3669-99d5-416a-81a9-65ba3919e9c7@github.com>
Message-ID: <RC3H3robwr_iIrQDqZAUf991FVVA_HuU9WXNF4Vy5gQ=.3120192d-df3f-45f0-b209-2cc99a409526@github.com>

On Thu, 24 Oct 2024 23:47:29 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> So, IMO the best way to move this particular enhancement forward is: ...

@jatin-bhateja here's a sketch (not tested): https://github.com/openjdk/jdk/compare/master...iwanowww:jdk:pr/21244

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2455955390

From pchilanomate at openjdk.org  Wed Nov  6 17:40:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.7d4f5337-5e3a-484f-b177-060039893bd9@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

I brought a small fix to the heap dump code from the loom repo for an issue found recently. It includes a reproducer test.

I brought some JFR changes from the loom repo that improve the reported reason when pinning.
@mgronlun @egahlin Could any of you review these JFR changes? Thanks.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2455431391
PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2456054504

From jbhateja at openjdk.org  Wed Nov  6 17:39:41 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 6 Nov 2024 17:39:41 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <RC3H3robwr_iIrQDqZAUf991FVVA_HuU9WXNF4Vy5gQ=.3120192d-df3f-45f0-b209-2cc99a409526@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <bSsKJgm8xrjS2E71bXxnYSrX3QHCaYg0RnVG85xr4Qw=.bad9bf94-6491-486b-b4fe-500197de7d68@github.com>
 <QefneoxqFUHmVJ38XlZ2uuMdvXujUHChihDwk0VMDUg=.72ed3669-99d5-416a-81a9-65ba3919e9c7@github.com>
 <RC3H3robwr_iIrQDqZAUf991FVVA_HuU9WXNF4Vy5gQ=.3120192d-df3f-45f0-b209-2cc99a409526@github.com>
Message-ID: <0fLBeJHlkgf0PnTP6gnbYeZ2P7yEceS1MW5oSf3q43s=.25320887-be06-46b1-919c-f3d25d46c039@github.com>

On Tue, 5 Nov 2024 00:07:51 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Thanks, @jatin-bhateja. I took a look at the latest version and still think that IGVN is not the best place for it. 
>> 
>> First of all, flags on MulVL feel too adhoc and irregular. The original IR structure is still there (except the cases when inputs are rewired), so can be easily recomputed on demand.
>> 
>> I noticed that the patterns can be generalized: what matters is whether upper half is filled with zeros/sign bits or not, so small enough masks (and large enough shifts) are amenable to the same optimization. But, in such case, input rewiring becomes applicable only to particular constant inputs.
>> 
>> (BTW signed right shifts can be optimized in a similar way, since they populate upper half with the sign-bit.)
>> 
>> So, IMO the best way to move this particular enhancement forward is:
>> * perform the transformation during matching;
>> * match a single MulVL node and shape the checks on argument shape as predicates on AD instructions 
>>    * setting lower instruction costs should tell the matcher to prefer new specific instructions over generic ones;
>> * avoid input rewiring for now (VPMULDQ/VPMULUDQ give enough performance improvement on its own).
>
>> So, IMO the best way to move this particular enhancement forward is: ...
> 
> @jatin-bhateja here's a sketch (not tested): https://github.com/openjdk/jdk/compare/master...iwanowww:jdk:pr/21244

Hi @iwanowww ,

Thanks for refactoring! your suggestions are included. 

Points in favor of the current approach:-
- Patch strength reduces 15 cycles full quadword multiplier to 5 cycles double word multiplier with quadword saturation.
- IR remains target independent, we are not directly forwarding the pattern inputs to the multiplier, such rewiring is only possible when we mask out the upper double word of inputs, for other cases like right shifting (logical) inputs by 32 or upcasting integral to long lanes we still need to emit the input preparation/formatting instruction sequence. 
- Patch shows performance improvement on both E and P core Xeons.

Following are the performance number for include micro benchmarks.

![image](https://github.com/user-attachments/assets/6a19181a-7f55-4cd8-9dfb-23dd4c786428)

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

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2459806910

From pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.7d4f5337-5e3a-484f-b177-060039893bd9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <lJh5TCrlKnM3Oe2Qr_1k0CukCSzKLHMLSFYfaSTInZA=.7d4f5337-5e3a-484f-b177-060039893bd9@github.com>
Message-ID: <8bSr_dBqhXkGBdKhm3qO4j1XJHBtu_RkeIH8ldtDAVA=.bd6692e9-93aa-46cf-b9de-75b06d83dd73@github.com>

On Tue, 5 Nov 2024 01:47:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> I brought some JFR changes from the loom repo that improve the reported reason when pinning.
> @mgronlun @egahlin Could any of you review these JFR changes? Thanks.

> Hi @pchilano,
> 
> I see couple of failures on s390x, can you apply this patch:
> 
Thanks @offamitkumar. Fixed.

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

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2457338726

From pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <Jzob6au97eCl9A5GbrobwBVLGIeCCWss22N6zCTGyfk=.f3ab8e5b-aa95-4936-921a-ed5ff56c8419@github.com>
Message-ID: <IIT6ZK5VHBwBQs0KkppCGOwgf55SIZk7-HKtZvFfIRQ=.518f21f8-2ddf-4e7c-bec9-1c5862e44fe7@github.com>

On Mon, 28 Oct 2024 17:31:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 188:
>> 
>>> 186:   // Avoid using a leave instruction when this frame may
>>> 187:   // have been frozen, since the current value of rfp
>>> 188:   // restored from the stub would be invalid. We still
>> 
>> It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI.  If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>> Do we actually need FP set by the enter() prologue for stubs?  If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs.  We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.
>
>>It sounds like freeze/thaw isn't preserving FP, even though it is a callee-saved register according to the ABI. If the stubs tried to modify FP (or any other callee-saved register) and use that value after the native call, wouldn't that be a problem?
>>
> Yes, that would be a problem. We can't use callee saved registers in the stub after the call. I guess we could add some debug code that trashes all those registers right when we come back from the call. Or maybe just adding a comment there is enough.

> Do we actually need FP set by the enter() prologue for stubs? If we can walk compiled frames based on SP and frame size, it seems like we should be able to do the same for stubs. We could consider making stub prologue/epilogue look the same as compiled frames, then this FP issue goes away.
>
I think we need it for the pending exception case. I see we use rfp to get the exception pc.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819474263

From qamai at openjdk.org  Wed Nov  6 17:39:41 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:41 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
Message-ID: <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.fbc25c6c-af57-4d04-8393-9182d5ecc853@github.com>

On Fri, 18 Oct 2024 05:35:28 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> src/hotspot/share/opto/vectornode.cpp line 2122:
> 
>> 2120:     // MulL (URShift SRC1 , 32) (URShift SRC2, 32)
>> 2121:     // MulL (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>> 2122:     // MulL ( And  SRC1,  0xFFFFFFFF) (URShift SRC2 , 32)
> 
> I don't understand how it works... According to the documentation, `VPMULDQ`/`VPMULUDQ` consume vectors of double words and produce a vector of quadwords. But it looks like `SRC1`/`SRC2` are always vectors of longs (quadwords). And `vmuludq_reg` in `x86.ad` just takes the immedate operands and pass them into `vpmuludq` which doesn't look right...

`vpmuludq` does a long multiplication but throws away the upper bits of the operands, effectively does a `(x & max_juint) * (y & max_juint)`

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805887594

From qamai at openjdk.org  Wed Nov  6 17:39:42 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Wed, 6 Nov 2024 17:39:42 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.fbc25c6c-af57-4d04-8393-9182d5ecc853@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.fbc25c6c-af57-4d04-8393-9182d5ecc853@github.com>
Message-ID: <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.6854e3f1-3b3b-4d21-841d-7963909f2bed@github.com>

On Fri, 18 Oct 2024 05:37:16 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2122:
>> 
>>> 2120:     // MulL (URShift SRC1 , 32) (URShift SRC2, 32)
>>> 2121:     // MulL (URShift SRC1 , 32)  ( And  SRC2,  0xFFFFFFFF)
>>> 2122:     // MulL ( And  SRC1,  0xFFFFFFFF) (URShift SRC2 , 32)
>> 
>> I don't understand how it works... According to the documentation, `VPMULDQ`/`VPMULUDQ` consume vectors of double words and produce a vector of quadwords. But it looks like `SRC1`/`SRC2` are always vectors of longs (quadwords). And `vmuludq_reg` in `x86.ad` just takes the immedate operands and pass them into `vpmuludq` which doesn't look right...
>
> `vpmuludq` does a long multiplication but throws away the upper bits of the operands, effectively does a `(x & max_juint) * (y & max_juint)`

You can see its pseudocode here https://www.felixcloutier.com/x86/pmuludq

    VPMULUDQ (VEX.256 Encoded Version)[ ?](https://www.felixcloutier.com/x86/pmuludq#vpmuludq--vex-256-encoded-version-)
    DEST[63:0] := SRC1[31:0] * SRC2[31:0]
    DEST[127:64] := SRC1[95:64] * SRC2[95:64]
    DEST[191:128] := SRC1[159:128] * SRC2[159:128]
    DEST[255:192] := SRC1[223:192] * SRC2[223:192]
    DEST[MAXVL-1:256] := 0

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805888984

From pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
Message-ID: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>

On Mon, 21 Oct 2024 06:38:28 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/c1_Runtime1_aarch64.cpp line 231:
> 
>> 229: 
>> 230: StubFrame::~StubFrame() {
>> 231:   __ epilogue(_use_pop_on_epilogue);
> 
> Can we not hook the `_use_pop_on_epilogue` into `return_state_t`, simplify the constructors and keep the old should_not_reach_here guard for stubs which should not return?
> e.g.
> ```C++
> enum return_state_t {
>   does_not_return, requires_return, requires_pop_epilogue_return
> };
> 
> StubFrame::~StubFrame() {
>   if (_return_state == does_not_return) {
>     __ should_not_reach_here();
>   } else {
>     __ epilogue(_return_state == requires_pop_epilogue_return);
>   }
> }

Yes, that's much better. I changed it in both aarch64 and riscv.

> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 115:
> 
>> 113:   // The object's monitor m is unlocked iff m->owner == nullptr,
>> 114:   // otherwise m->owner may contain a thread id, a stack address for LM_LEGACY,
>> 115:   // or the ANONYMOUS_OWNER constant for LM_LIGHTWEIGHT.
> 
> Comment seems out of place in `LockingMode != LM_LIGHTWEIGHT` code.

I removed this comment about what other values might be stored in _owner since we don't need to handle those cases here.

> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:
> 
>> 378:     lea(t2_owner_addr, owner_address);
>> 379: 
>> 380:     // CAS owner (null => current thread id).
> 
> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 
> 
> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)

Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:
> 
>> 298:   CodeBlob* cb = top.cb();
>> 299: 
>> 300:   if (cb->frame_size() == 2) {
> 
> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.

We could also check the caller of the runtime frame, something like:

#ifdef ASSERT
  RegisterMap map(JavaThread::current(),
                  RegisterMap::UpdateMap::skip,
                  RegisterMap::ProcessFrames::skip,
                  RegisterMap::WalkContinuation::skip);
  frame caller = top.sender(&map);
  assert(caller.is_compiled_frame(), "");
  assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
#endif

Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame.

> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 313:
> 
>> 311: 
>> 312:     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
>> 313:                                               " fp: " INTPTR_FORMAT, p2i(sp + frame::metadata_words), p2i(sp), sp[-2]);
> 
> Is there a reason for the mix of `2` and `frame::metadata_words`?
> 
> Maybe this could be
> ```C++
>     intptr_t* const unadjusted_sp = sp;
>     sp -= frame::metadata_words;
>     sp[-2] = unadjusted_sp[-2];
>     sp[-1] = unadjusted_sp[-1];
> 
>     log_develop_trace(continuations, preempt)("adjusted sp for c2 runtime stub, initial sp: " INTPTR_FORMAT " final sp: " INTPTR_FORMAT
>                                               " fp: " INTPTR_FORMAT, p2i(unadjusted_sp), p2i(sp), sp[-2]);

I removed the use of frame::metadata_words from the log statement instead to make it consistent, since we would still implicitly be assuming metadata_words it's 2 words when we do the copying. We could use a memcpy and refer to metadata_words, but I think it is clear this way since we are explicitly talking about the 2 extra words missing from the runtime frame as the comment explains.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 1275:
> 
>> 1273: void SharedRuntime::continuation_enter_cleanup(MacroAssembler* masm) {
>> 1274:   ::continuation_enter_cleanup(masm);
>> 1275: }
> 
> Now that `continuation_enter_cleanup` is a static member function, just merge the static free function with this static member function.

Since we have 3 free static functions to handle the continuation entry(create, fill, cleanup) I would prefer to keep the cleanup one for consistency. We could also change them all to be members of SharedRuntime. But except for the exception I added for continuation_enter_cleanup(), all these are called by gen_continuation_enter/gen_continuation_yield() which are also static free functions.

> src/hotspot/cpu/x86/assembler_x86.cpp line 2866:
> 
>> 2864:     emit_int32(0);
>> 2865:   }
>> 2866: }
> 
> Is it possible to make this more general and explicit instead of a sequence of bytes?
> 
> Something along the lines of:
> ```C++
>   const address tar = L.is_bound() ? target(L) : pc();
>   const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);
> 
>   InstructionMark im(this);
>   emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
>   if (!L.is_bound()) {
>     // Patch @0x8D opcode
>     L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
>   }
>   // Register and [rip+disp] operand
>   emit_modrm(0b00, raw_encode(dst), 0b101);
>   // Adjust displacement by sizeof lea instruction
>   int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
>   assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
>   emit_int32(disp);
> 
> 
> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.

I'll test it out but looks fine.

> src/hotspot/share/oops/stackChunkOop.cpp line 445:
> 
>> 443: 
>> 444: void stackChunkOopDesc::transfer_lockstack(oop* dst) {
>> 445:   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
> 
> Given how careful we are in `Thaw` to not call `requires_barriers()` twice and use `_barriers` instead it would probably be nicer to pass in `_barriers` as a bool. 
> 
> There is only one other place we do the extra call and it is in `fix_thawed_frame`, but that only happens after we are committed to the slow path, so it might be nice for completeness, but should be negligible for performance. Here however we might still be in our new "medium" path where we could still do a fast thaw.

Good, passed as argument now.

> src/hotspot/share/oops/stackChunkOop.cpp line 460:
> 
>> 458:     } else {
>> 459:       oop value = *reinterpret_cast<oop*>(at);
>> 460:       HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
> 
> Using HeapAccess when `!requires_gc_barriers` is wrong. This would crash with ZGC when/if we fix the flags race and changed `relativize_chunk_concurrently` to only be conditioned `requires_barriers() / _barriers` (and allowing the retry_fast_path "medium" path). 
> So either use `*reinterpret_cast<oop*>(at) = nullptr;` or do what my initial suggestion with `clear_lockstack` did, just omit the clearing. Before we requires_barriers(), we are allowed to reuse the stackChuncks, so trying to clean them up seems fruitless.

Ok, I just omitted clearing the oop.

> src/hotspot/share/oops/stackChunkOop.cpp line 471:
> 
>> 469:     }
>> 470:   }
>> 471: }
> 
> Can we turn these three very similar loops into one? In my opinion, it is easier to parse.
> 
> ```C++
> void stackChunkOopDesc::copy_lockstack(oop* dst) {
>   const int cnt = lockstack_size();
>   const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
>   const bool requires_uncompress = requires_gc_barriers && has_bitmap() && UseCompressedOops;
>   const auto get_obj = [&](intptr_t* at) -> oop {
>     if (requires_gc_barriers) {
>       if (requires_uncompress) {
>         return HeapAccess<>::oop_load(reinterpret_cast<narrowOop*>(at));
>       }
>       return HeapAccess<>::oop_load(reinterpret_cast<oop*>(at));
>     }
>     return *reinterpret_cast<oop*>(at);
>   };
> 
>   intptr_t* lockstack_start = start_address();
>   for (int i = 0; i < cnt; i++) {
>     oop mon_owner = get_obj(&lockstack_start[i]);
>     assert(oopDesc::is_oop(mon_owner), "not an oop");
>     dst[i] = mon_owner;
>   }
> }

Done. I combined it with the oop clearing suggestion.

> src/hotspot/share/prims/jvmtiExport.cpp line 1681:
> 
>> 1679:   EVT_TRIG_TRACE(EXT_EVENT_VIRTUAL_THREAD_UNMOUNT, ("[%p] Trg Virtual Thread Unmount event triggered", vthread));
>> 1680: 
>> 1681:   // On preemption JVMTI state rebinding has already happened so get it always direclty from the oop.
> 
> Suggestion:
> 
>   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
> 
>> 2232:     retry_fast_path = true;
>> 2233:   } else {
>> 2234:     relativize_chunk_concurrently(chunk);
> 
> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 
> 
> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.

Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t?

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:
> 
>> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
>> 2246: 
>> 2247:     chunk->set_lockstack_size(0);
> 
> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.
> 
> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.
> 
> 
> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
> index d3d63533eed..f737bd2db71 100644
> --- a/src/hotspot/share/oops/stackChunkOop.cpp
> +++ b/src/hotspot/share/oops/stackChunkOop.cpp
> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
>    }
>  }
>  
> +void stackChunkOopDesc::clear_lockstack() {
> +  const int cnt = lockstack_size();
> +  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
> +  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
> +  const auto clear_obj = [&](intptr_t* at) {
> +    if (requires_uncompress) {
> +      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
> +    } else {
> +      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
> +    }
> +  };
> +
> +  if (requires_gc_barriers) {
> +    intptr_t* lockstack_start = start_address();
> +    for (int i = 0; i < cnt; i++) {
> +      clear_obj(&lockstack_start[i]);
> +    }
> +  }
> +  set_lockstack_size(0);
> +  set_has_lockstack(false);
> +}
> +
>  void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
>    if (*((juint*)this) == badHeapWordVal) {
>      st->print_cr("BAD WORD");
> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
> index 28e0576801e..928e94dd695 100644
> --- a/src/hotspot/share/oops/stackChunkOop.hpp
> +++ b/src/hotspot/share/oops/stackChunkOop.hpp
> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
>    void fix_thawed_frame(const frame& f, const RegisterMapT* map);
>  
>    void copy_lockstack(oop* start);
> +  void clear_lockstack();
>  
>    template <typename OopT, class StackChunkLockSta...

Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2538:
> 
>> 2536:   Method* m = hf.interpreter_frame_method();
>> 2537:   // For native frames we need to count parameters, possible alignment, plus the 2 extra words (temp oop/result handler).
>> 2538:   const int locals = !m->is_native() ? m->max_locals() : m->size_of_parameters() + frame::align_wiggle + 2;
> 
> Is it possible to have these extra native frame slots size be a named constant / enum value on `frame`? I think it is used in a couple of places.

I reverted this change and added an assert instead, since for native methods we always thaw the caller too, i.e. it will not be the bottom frame. I added a comment in the other two references for the extra native slots in continuationFreezeThaw_x86.inline.hpp.

> src/hotspot/share/runtime/frame.cpp line 535:
> 
>> 533:   assert(get_register_address_in_stub(f, SharedRuntime::thread_register()) == (address)thread_addr, "wrong thread address");
>> 534:   return thread_addr;
>> 535: #endif
> 
> With this ifdef, it seems like this belongs in the platform dependent part of the frame class.

I moved it to the platform dependent files.

> src/hotspot/share/runtime/objectMonitor.hpp line 184:
> 
>> 182:   // - We test for anonymous owner by testing for the lowest bit, therefore
>> 183:   //   DEFLATER_MARKER must *not* have that bit set.
>> 184:   static const int64_t DEFLATER_MARKER = 2;
> 
> The comments here should be updated / removed. They are talking about the lower bits of the owner being unset which is no longer true. (And talks about doing bit tests, which I do not think is done anywhere even without this patch).

Removed the comments.

> src/hotspot/share/runtime/objectMonitor.hpp line 186:
> 
>> 184:   static const int64_t DEFLATER_MARKER = 2;
>> 185: 
>> 186:   int64_t volatile _owner;  // Either tid of owner, ANONYMOUS_OWNER_MARKER or DEFLATER_MARKER.
> 
> Suggestion:
> 
>   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.

Fixed.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 50:
> 
>> 48: inline int64_t ObjectMonitor::owner_from(oop vthread) {
>> 49:   int64_t tid = java_lang_Thread::thread_id(vthread);
>> 50:   assert(tid >= 3 && tid < ThreadIdentifier::current(), "must be reasonable");
> 
> Suggestion:
> 
>   assert(tid >= ThreadIdentifier::initial() && tid < ThreadIdentifier::current(), "must be reasonable");

Fixed.

> src/hotspot/share/runtime/synchronizer.cpp line 1467:
> 
>> 1465:       markWord dmw = inf->header();
>> 1466:       assert(dmw.is_neutral(), "invariant: header=" INTPTR_FORMAT, dmw.value());
>> 1467:       if (inf->is_owner_anonymous() && inflating_thread != nullptr) {
> 
> Are these `LM_LEGACY` + `ANONYMOUS_OWNER` changes still required now that `LM_LEGACY` does no freeze?

Yes, it's just a consequence of using tid as the owner, not really related to freezing. So when a thread inflates a monitor that is already owned we cannot store the BasicLock* in the _owner field anymore, since it can clash with some tid, so we mark it as anonymously owned instead. The owner will fix it here when trying to get the monitor, as we do with LM_LIGHTWEIGHT.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809745804
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746249
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809746397
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809753868
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809747046
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749481
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749657
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826149674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826148888
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813222417
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809749805
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244844
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811244206
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823317839
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750552
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809750685
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830229529
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809754940

From vlivanov at openjdk.org  Wed Nov  6 17:39:42 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:42 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.6854e3f1-3b3b-4d21-841d-7963909f2bed@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.fbc25c6c-af57-4d04-8393-9182d5ecc853@github.com>
 <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.6854e3f1-3b3b-4d21-841d-7963909f2bed@github.com>
Message-ID: <YBfK7uCVlgzfZ-K8l-aMbl8Ddu5lMroutXdEEHcyik8=.fd11881c-1388-4531-8758-73ced496d706@github.com>

On Fri, 18 Oct 2024 05:39:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> `vpmuludq` does a long multiplication but throws away the upper bits of the operands, effectively does a `(x & max_juint) * (y & max_juint)`
>
> You can see its pseudocode here https://www.felixcloutier.com/x86/pmuludq
> 
>     VPMULUDQ (VEX.256 Encoded Version)[ ?](https://www.felixcloutier.com/x86/pmuludq#vpmuludq--vex-256-encoded-version-)
>     DEST[63:0] := SRC1[31:0] * SRC2[31:0]
>     DEST[127:64] := SRC1[95:64] * SRC2[95:64]
>     DEST[191:128] := SRC1[159:128] * SRC2[159:128]
>     DEST[255:192] := SRC1[223:192] * SRC2[223:192]
>     DEST[MAXVL-1:256] := 0

Got it. Now it makes perfect sense. Thanks for the clarifications!

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805894106

From aph at openjdk.org  Wed Nov  6 17:40:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>

On Tue, 22 Oct 2024 15:37:23 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
> 
>> 58: 
>> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
>> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);
> 
> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810985771

From vlivanov at openjdk.org  Wed Nov  6 17:39:43 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Wed, 6 Nov 2024 17:39:43 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <YBfK7uCVlgzfZ-K8l-aMbl8Ddu5lMroutXdEEHcyik8=.fd11881c-1388-4531-8758-73ced496d706@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <kAjyTPm6Lh4vo1GtFcCew99glYj1DqmI7FbU9ZO-i98=.4c640c26-ed37-4498-a90c-6757491a265f@github.com>
 <O4Tm-ksXEmfNK_Gk_9LE1qWH3wm4TyOFciVa_VSkEq8=.fbc25c6c-af57-4d04-8393-9182d5ecc853@github.com>
 <pTaJgdWlRELOLYKakooudS-5TkW3xmDJrOI5wx3FUT4=.6854e3f1-3b3b-4d21-841d-7963909f2bed@github.com>
 <YBfK7uCVlgzfZ-K8l-aMbl8Ddu5lMroutXdEEHcyik8=.fd11881c-1388-4531-8758-73ced496d706@github.com>
Message-ID: <xobYQ9YwUCE7wwErWEmsnZufYV83RGomYlsaVpyQwbA=.ddb0f05f-b134-458b-a45b-76fdeb2a3e1a@github.com>

On Fri, 18 Oct 2024 05:46:25 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> You can see its pseudocode here https://www.felixcloutier.com/x86/pmuludq
>> 
>>     VPMULUDQ (VEX.256 Encoded Version)[ ?](https://www.felixcloutier.com/x86/pmuludq#vpmuludq--vex-256-encoded-version-)
>>     DEST[63:0] := SRC1[31:0] * SRC2[31:0]
>>     DEST[127:64] := SRC1[95:64] * SRC2[95:64]
>>     DEST[191:128] := SRC1[159:128] * SRC2[159:128]
>>     DEST[255:192] := SRC1[223:192] * SRC2[223:192]
>>     DEST[MAXVL-1:256] := 0
>
> Got it. Now it makes perfect sense. Thanks for the clarifications!

Actually, it makes detecting the pattern during matching even simpler than I initially thought. Since there's no need to match any non-trivial ideal IR tree, AD instruction can just match a single `MulVL`, but detect operand shapes using a predicate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1805903273

From aph at openjdk.org  Wed Nov  6 17:40:01 2024
From: aph at openjdk.org (Andrew Haley)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>
Message-ID: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.c37f3f8f-7dd1-4d0c-80ed-64b86b8d1021@github.com>

On Tue, 22 Oct 2024 15:48:43 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 60:
>> 
>>> 58: 
>>> 59:   assert(LockingMode != LM_LIGHTWEIGHT, "lightweight locking should use fast_lock_lightweight");
>>> 60:   assert_different_registers(oop, box, tmp, disp_hdr, rscratch2);
>> 
>> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake.
>> Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.
>
> Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.

> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.

Hmm, forget that. It's rather tricky code, that's true, but I think we're OK.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810998545

From pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.c37f3f8f-7dd1-4d0c-80ed-64b86b8d1021@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <K7fFQqrnV5pSYzPNJYf2OlE1qFiEURm4wp3UfYFhVzs=.fef1ac5d-74d6-4c0c-a835-17451871abb5@github.com>
 <tXdezPkAUMPlkZX3gqNJJSYIcSrj9FKW0b6TduG6tx4=.c37f3f8f-7dd1-4d0c-80ed-64b86b8d1021@github.com>
Message-ID: <gGm48Cxs1mgNeICqJxSkVYxDdT4gGogR9QP6rIcrDVQ=.96243863-0f53-42db-a7c5-0b94beb602a0@github.com>

On Tue, 22 Oct 2024 15:56:21 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> Note also that `inc_held_monitor_count` clobbers `rscratch2`.  That might be worth a comment at the call site.
>> I guess `inc_held_monitor_count` is so hot that we can't push and pop scratch registers, in which case it'd clobber nothing.
>
>> Historically, silently using `rscratch1` and `rscratch2` in these macros has sometimes turned out to be a mistake. Please consider making `rscratch2` an additional argument to `fast_lock`, so that it's explicit in the caller. It won't make any difference to the generated code, but it might help readbility.
> 
> Hmm, forget that. It's rather tricky code, that's true, but I think we're OK.

I see we are already using rscratch1 in these locking macros so I could change it to use that instead. But looking at all other macros in this file we are already using rscratch1 and rscratch2 too, so I think we would be fine either way.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813513144

From coleenp at openjdk.org  Wed Nov  6 17:40:01 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <vc7yb0rPrCsvTFxlSjVuCowEFqyXNl89l6Ls2eVYS4g=.dbadfee9-cd55-4fbd-9762-6ef640ca7cd6@github.com>

On Tue, 22 Oct 2024 02:09:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/c2_MacroAssembler_aarch64.cpp line 380:
>> 
>>> 378:     lea(t2_owner_addr, owner_address);
>>> 379: 
>>> 380:     // CAS owner (null => current thread id).
>> 
>> I think we should be more careful when and where we talk about thread id and lock id respectively. Given that `switchToCarrierThread` switches the thread, but not the lock id. We should probably define and talk about the lock id when it comes to locking, as saying thread id may be incorrect. 
>> 
>> Then there is also the different thread ids, the OS level one, and the java level one. (But not sure how to reconcile this without causing confusion)
>
> Fixed the comments to refer to _lock_id. Even without the switchToCarrierThread case I think that's the correct thing to do.

yes, we preferred lock_id here which is the same as the Java version of thread id, but not the same as the os thread-id.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811583503

From pchilanomate at openjdk.org  Wed Nov  6 17:40:01 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
Message-ID: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>

On Wed, 23 Oct 2024 22:59:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 135:
> 
>> 133:   assert(*f.addr_at(frame::interpreter_frame_last_sp_offset) == 0, "should be null for top frame");
>> 134:   intptr_t* lspp = f.addr_at(frame::interpreter_frame_last_sp_offset);
>> 135:   *lspp = f.unextended_sp() - f.fp();
> 
> Can you write a comment what this is doing briefly and why?

Added comment.

> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:
> 
>> 1548: #endif /* ASSERT */
>> 1549: 
>> 1550:   push_cont_fastpath();
> 
> One of the callers of this gives a clue what it does.
> 
>   __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about
> 
> Why do you do this here?  Oh please more comments...

_cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.

> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5354:
> 
>> 5352:   str(rscratch2, dst);
>> 5353:   Label ok;
>> 5354:   tbz(rscratch2, 63, ok);
> 
> 63?  Does this really need to have underflow checking?  That would alleviate the register use concerns if it didn't.  And it's only for legacy locking which should be stable until it's removed.

I can remove the check. I don't think it hurts either though. Also we can actually just use rscratch1 in the ASSERT case.

> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:
> 
>> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
>> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
>> 2032:     __ push_cont_fastpath();
> 
> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?

Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.

> src/hotspot/cpu/riscv/macroAssembler_riscv.cpp line 231:
> 
>> 229: 
>> 230: void MacroAssembler::inc_held_monitor_count(Register tmp) {
>> 231:   Address dst = Address(xthread, JavaThread::held_monitor_count_offset());
> 
> Address dst(xthread, JavaThread::held_monitor_count_offset());

Done.

> src/hotspot/share/interpreter/oopMapCache.cpp line 268:
> 
>> 266:   }
>> 267: 
>> 268:   int num_oops() { return _num_oops; }
> 
> I can't find what uses this from OopMapCacheEntry.

It's needed for verification in VerifyStackChunkFrameClosure. It's called in OopMapCacheEntry::fill_for_native(), and we get there from here: https://github.com/openjdk/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/x86/stackChunkFrameStream_x86.inline.hpp#L114

> src/hotspot/share/runtime/continuation.cpp line 89:
> 
>> 87:       // we would incorrectly throw it during the unmount logic in the carrier.
>> 88:       if (_target->has_async_exception_condition()) {
>> 89:         _failed = false;
> 
> This says "Don't" but then failed is false which doesn't make sense.  Should it be true?

Yes, good catch.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
> 
>> 1273: 
>> 1274:   if (caller.is_interpreted_frame()) {
>> 1275:     _total_align_size += frame::align_wiggle;
> 
> Please put a comment here about frame align-wiggle.

I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1278:
> 
>> 1276:   }
>> 1277: 
>> 1278:   patch(f, hf, caller, false /*is_bottom_frame*/);
> 
> I also forgot what patch does.  Can you add a comment here too?

I added a comment where it is defined since it is used in several places.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550:
> 
>> 1548:   assert(!cont.is_empty(), "");
>> 1549:   // This is done for the sake of the enterSpecial frame
>> 1550:   StackWatermarkSet::after_unwind(thread);
> 
> Is there a new place for this StackWatermark code?

I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2235:
> 
>> 2233:       assert(!mon_acquired || mon->has_owner(_thread), "invariant");
>> 2234:       if (!mon_acquired) {
>> 2235:         // Failed to aquire monitor. Return to enterSpecial to unmount again.
> 
> typo: acquire

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2492:
> 
>> 2490: void ThawBase::throw_interrupted_exception(JavaThread* current, frame& top) {
>> 2491:   ContinuationWrapper::SafepointOp so(current, _cont);
>> 2492:   // Since we might safepoint set the anchor so that the stack can we walked.
> 
> typo: can be walked

Fixed.

> src/hotspot/share/runtime/javaThread.hpp line 334:
> 
>> 332:   bool                  _pending_jvmti_unmount_event;    // When preempting we post unmount event at unmount end rather than start
>> 333:   bool                  _on_monitor_waited_event;        // Avoid callee arg processing for enterSpecial when posting waited event
>> 334:   ObjectMonitor*        _contended_entered_monitor;      // Monitor por pending monitor_contended_entered callback
> 
> typo: Monitor **for** pending_contended_entered callback

Fixed.

> src/hotspot/share/runtime/objectMonitor.cpp line 876:
> 
>> 874:   // and in doing so avoid some transitions ...
>> 875: 
>> 876:   // For virtual threads that are pinned do a timed-park instead, to
> 
> I had trouble parsing this first sentence.  I think it needs a comma after pinned and remove the comma after instead.

Fixed.

> src/hotspot/share/runtime/objectMonitor.cpp line 2305:
> 
>> 2303: }
>> 2304: 
>> 2305: void ObjectMonitor::Initialize2() {
> 
> Can you put a comment why there's a second initialize function?  Presumably after some state is set.

Added comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 43:
> 
>> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
>> 43: // See next_waiter(), first_waiter(), etc.
> 
> Also a nice cleanup.  Did you reconcile the JVMTI code?

We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage.

> src/hotspot/share/runtime/objectMonitor.hpp line 71:
> 
>> 69:   bool is_wait()           { return _is_wait; }
>> 70:   bool notified()          { return _notified; }
>> 71:   bool at_reenter()        { return _at_reenter; }
> 
> should these be const member functions?

Yes, changed to const.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816658344
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660065
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813516395
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660542
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813519648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819462987
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816660817
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661388
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816661733
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662247
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583906
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583954
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823583822
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816662554
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816663065
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463651
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819463958

From dlong at openjdk.org  Wed Nov  6 17:40:01 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:01 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <jiLbxr6TkMLG8JgH0CHhoJpkggmJZjyxoWVBLU8Frgk=.a7235433-1d61-4ffb-b275-6f934679a94c@github.com>

On Tue, 22 Oct 2024 02:18:19 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 300:
>> 
>>> 298:   CodeBlob* cb = top.cb();
>>> 299: 
>>> 300:   if (cb->frame_size() == 2) {
>> 
>> Is this a filter to identify c2 runtime stubs? Is there some other property we can check or assert here? This assumes that no other runtime frame will have this size.
>
> We could also check the caller of the runtime frame, something like:
> 
> #ifdef ASSERT
>   RegisterMap map(JavaThread::current(),
>                   RegisterMap::UpdateMap::skip,
>                   RegisterMap::ProcessFrames::skip,
>                   RegisterMap::WalkContinuation::skip);
>   frame caller = top.sender(&map);
>   assert(caller.is_compiled_frame(), "");
>   assert(cb->frame_size() > 2 || caller.cb()->as_nmethod()->is_compiled_by_c2(), "");
> #endif
> 
> Ideally we would want to check if cb->frame_size() is different than the actual?size of the physical frame.

I agree, checking for frame_size() == 2 seems fragile.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817458483

From dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>

On Sat, 26 Oct 2024 00:27:25 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:
> 
>> 308:     sp -= 2;
>> 309:     sp[-2] = sp[0];
>> 310:     sp[-1] = sp[1];
> 
> This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?

Could the problem be solved with a resume adapter instead, like the interpreter uses?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817556946

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
Message-ID: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>

On Sat, 26 Oct 2024 01:58:30 GMT, Dean Long <dlong at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp line 310:
>> 
>>> 308:     sp -= 2;
>>> 309:     sp[-2] = sp[0];
>>> 310:     sp[-1] = sp[1];
>> 
>> This also seems fragile.  This seems to depend on an intimate knowledge of what the stub will do when returning.  We don't need this when doing a regular return from the native call, so why do we need it here?  I'm guessing freeze/thaw hasn't restored the state quite the same way that the stub expects.  Why is this needed for C2 and not C1?
>
> Could the problem be solved with a resume adapter instead, like the interpreter uses?

The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819593485

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
Message-ID: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>

On Mon, 28 Oct 2024 18:56:25 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>
> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.

> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>
It will just move the task of adjusting the size of the frame somewhere else.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819594475

From dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
Message-ID: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>

On Mon, 28 Oct 2024 18:56:58 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> The issue with the c2 runtime stub on aarch64 (and riscv) is that cb->frame_size() doesn't match the size of the physical frame, it's short by 2 words. I explained the reason for that in the comment above. So for a regular return we don't care about last_Java_sp, rsp will point to the same place as before the call when we return. But when resuming for the preemption case, the rsp will be two words short, since when we freezed the runtime stub we freeze 2 words less (and we have to do that to be able to correctly get the sender when we walk it).
>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable. I guess this was a micro optimization.
>
>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>>
> It will just move the task of adjusting the size of the frame somewhere else.

> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.

If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819896849

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
Message-ID: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>

On Mon, 28 Oct 2024 23:38:43 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> Could the problem be solved with a resume adapter instead, like the interpreter uses?
>>>
>> It will just move the task of adjusting the size of the frame somewhere else.
>
>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.
> 
> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.

The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like:


   0xffffdfdba584:	sub	sp, sp, #0x10
   0xffffdfdba588:	stp	x29, x30, [sp]
   0xffffdfdba58c:	ldrb	w8, [x28, #1192]
   0xffffdfdba590:	cbz	x8, 0xffffdfdba5a8
   0xffffdfdba594:	mov	x8, #0x4ba0                	
   0xffffdfdba598:	movk	x8, #0xf6a8, lsl #16
   0xffffdfdba59c:	movk	x8, #0xffff, lsl #32
   0xffffdfdba5a0:	mov	x0, x28
   0xffffdfdba5a4:	blr	x8
   0xffffdfdba5a8:	mov	x9, sp
   0xffffdfdba5ac:	str	x9, [x28, #1000]       <------- store last_Java_sp
   0xffffdfdba5b0:	mov	x0, x1
   0xffffdfdba5b4:	mov	x1, x2
   0xffffdfdba5b8:	mov	x2, x28
   0xffffdfdba5bc:	adr	x9, 0xffffdfdba5d4
   0xffffdfdba5c0:	mov	x8, #0xe6a4                	
   0xffffdfdba5c4:	movk	x8, #0xf717, lsl #16
   0xffffdfdba5c8:	movk	x8, #0xffff, lsl #32
   0xffffdfdba5cc:	stp	xzr, x9, [sp, #-16]!   <------- Push two extra words
   0xffffdfdba5d0:	blr	x8
   0xffffdfdba5d4:	nop
   0xffffdfdba5d8:	movk	xzr, #0x0
   0xffffdfdba5dc:	movk	xzr, #0x0
   0xffffdfdba5e0:	add	sp, sp, #0x10      <------- Remove two extra words
   0xffffdfdba5e4:	str	xzr, [x28, #1000]
   0xffffdfdba5e8:	str	xzr, [x28, #1008]
   0xffffdfdba5ec:	ldr	x10, [x28, #8]
   0xffffdfdba5f0:	cbnz	x10, 0xffffdfdba600
   0xffffdfdba5f4:	ldp	x29, x30, [sp]
   0xffffdfdba5f8:	add	sp, sp, #0x10
   0xffffdfdba5fc:	ret
   0xffffdfdba600:	ldp	x29, x30, [sp]
   0xffffdfdba604:	add	sp, sp, #0x10
   0xffffdfdba608:	adrp	x8, 0xffffdfc30000
   0xffffdfdba60c:	add	x8, x8, #0x80
   0xffffdfdba610:	br	x8

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821389434

From dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
Message-ID: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>

On Tue, 29 Oct 2024 19:01:03 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> One way to get rid of this would be to have c2 just set last_Java_pc too along with last_Java_sp, so we don't need to push lr to be able to do last_Java_sp[-1] to make the frame walkable.
>> 
>> If that would solve the problem, then that must mean we save/freeze last_Java_pc as part of the virtual thread's state.  So why can't we just call make_walkable() before we freeze, to fix things up as if C2 had stored last_Java_pc to the anchor?  Then freeze could assert that the thread is already walkable.  I'm surprised it doesn't already.
>
> The issue is not when we make the frame walkable but how. The way it currently works is by pushing the last_Java_pc to the stack in the runtime stub before making the call to the VM (plus an alignment word). So to make the frame walkable we do last_Java_sp[-1] in the VM. But this approach creates a mismatch between the recorded cb->frame_size() (which starts from last_Java_sp) vs the physical size of the frame which starts with rsp right before the call. This is what the c2 runtime stub code for aarch64 looks like:
> 
> 
>    0xffffdfdba584:	sub	sp, sp, #0x10
>    0xffffdfdba588:	stp	x29, x30, [sp]
>    0xffffdfdba58c:	ldrb	w8, [x28, #1192]
>    0xffffdfdba590:	cbz	x8, 0xffffdfdba5a8
>    0xffffdfdba594:	mov	x8, #0x4ba0                	
>    0xffffdfdba598:	movk	x8, #0xf6a8, lsl #16
>    0xffffdfdba59c:	movk	x8, #0xffff, lsl #32
>    0xffffdfdba5a0:	mov	x0, x28
>    0xffffdfdba5a4:	blr	x8
>    0xffffdfdba5a8:	mov	x9, sp
>    0xffffdfdba5ac:	str	x9, [x28, #1000]       <------- store last_Java_sp
>    0xffffdfdba5b0:	mov	x0, x1
>    0xffffdfdba5b4:	mov	x1, x2
>    0xffffdfdba5b8:	mov	x2, x28
>    0xffffdfdba5bc:	adr	x9, 0xffffdfdba5d4
>    0xffffdfdba5c0:	mov	x8, #0xe6a4                	
>    0xffffdfdba5c4:	movk	x8, #0xf717, lsl #16
>    0xffffdfdba5c8:	movk	x8, #0xffff, lsl #32
>    0xffffdfdba5cc:	stp	xzr, x9, [sp, #-16]!   <------- Push two extra words
>    0xffffdfdba5d0:	blr	x8
>    0xffffdfdba5d4:	nop
>    0xffffdfdba5d8:	movk	xzr, #0x0
>    0xffffdfdba5dc:	movk	xzr, #0x0
>    0xffffdfdba5e0:	add	sp, sp, #0x10      <------- Remove two extra words
>    0xffffdfdba5e4:	str	xzr, [x28, #1000]
>    0xffffdfdba5e8:	str	xzr, [x28, #1008]
>    0xffffdfdba5ec:	ldr	x10, [x28, #8]
>    0xffffdfdba5f0:	cbnz	x10, 0xffffdfdba600
>    0xffffdfdba5f4:	ldp	x29, x30, [sp]
>    0xffffdfdba5f8:	add	sp, sp, #0x10
>    0xffffdfdba5fc:	ret
>    0xffffdfdba600:	ldp	x29, x30, [sp]
>    0xffffdfdba604:	add	sp, sp, #0x10
>    0xffffdfdba608:	adrp	x8, 0xffffdfc30000
>    0xffffdfdba60c:	add	x8, x8, #0x80
>    0xffffdfdba610:	br	x8

OK, so you're saying it's the stack adjustment that's the problem.  It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary.  Isn't that a bug that should be fixed?  I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest.  Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling.

It's still unclear to me exactly how we resume after preemption.  It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted.  If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment.  In your example, last_Java_pc would be set to 0xffffdfdba5e4.  I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823701666

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
Message-ID: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>

On Thu, 31 Oct 2024 02:33:30 GMT, Dean Long <dlong at openjdk.org> wrote:

> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed?
>
It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824782389

From dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
Message-ID: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>

On Thu, 31 Oct 2024 16:27:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> OK, so you're saying it's the stack adjustment that's the problem.  It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary.  Isn't that a bug that should be fixed?  I also think we should fix the aarch64 c2 stub to just store last_Java_pc like you suggest.  Adjusting the stack like this has in the past caused other problems, in particular making it hard to obtain safe stack traces during asynchronous profiling.
>> 
>> It's still unclear to me exactly how we resume after preemption.  It looks like we resume at last_Java_pc with rsp set based on last_Java_sp, which is why it needs to be adjusted.  If that's the case, an alternative simplification for aarch64 is to set a different last_Java_pc that is preemption-friendly that skips the stack adjustment.  In your example, last_Java_pc would be set to 0xffffdfdba5e4.  I think it is a reasonable requirement that preemption can return to last_Java_pc/last_Java_sp without adjustments.
>
>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed?
>>
> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method.

It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825498409

From dlong at openjdk.org  Wed Nov  6 17:40:02 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
Message-ID: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>

On Fri, 1 Nov 2024 07:14:35 GMT, Dean Long <dlong at openjdk.org> wrote:

>>> OK, so you're saying it's the stack adjustment that's the problem. It sounds like there is code that is using rsp instead of last_Java_sp to compute the frame boundary. Isn't that a bug that should be fixed?
>>>
>> It's not a bug, it's just that the code from the runtime stub only cares about the actual rsp, not last_Java_sp. We are returning to the pc right after the call so we need to adjust rsp to what the runtime stub expects. Both alternatives will work, either changing the runtime stub to set last pc and not push those two extra words, or your suggestion of just setting the last pc to the instruction after the adjustment. Either way it requires to change the c2 code though which I'm not familiar with. But if you can provide a patch I'm happy to apply it and we can remove this `possibly_adjust_frame()` method.
>
> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.

Here's my suggested C2 change:

diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
index d9c77a2f529..1e99db191ae 100644
--- a/src/hotspot/cpu/aarch64/aarch64.ad
+++ b/src/hotspot/cpu/aarch64/aarch64.ad
@@ -3692,14 +3692,13 @@ encode %{
       __ post_call_nop();
     } else {
       Label retaddr;
+      // Make the anchor frame walkable
       __ adr(rscratch2, retaddr);
+      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
       __ lea(rscratch1, RuntimeAddress(entry));
-      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
-      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
       __ blr(rscratch1);
       __ bind(retaddr);
       __ post_call_nop();
-      __ add(sp, sp, 2 * wordSize);
     }
     if (Compile::current()->max_vector_size() > 0) {
       __ reinitialize_ptrue();

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826252551

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zERh0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zER
 h0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
Message-ID: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>

On Fri, 1 Nov 2024 20:08:51 GMT, Dean Long <dlong at openjdk.org> wrote:

>> It turns out if we try to set last pc to the instruction after the adjustment, then we need an oopmap there, and that would require more C2 changes.  Then I thought about restoring SP from FP or last_Java_fp, but I don't think we can rely on either of those being valid after resume from preemption, so I'll try the other alternative.
>
> Here's my suggested C2 change:
> 
> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
> index d9c77a2f529..1e99db191ae 100644
> --- a/src/hotspot/cpu/aarch64/aarch64.ad
> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
> @@ -3692,14 +3692,13 @@ encode %{
>        __ post_call_nop();
>      } else {
>        Label retaddr;
> +      // Make the anchor frame walkable
>        __ adr(rscratch2, retaddr);
> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>        __ lea(rscratch1, RuntimeAddress(entry));
> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>        __ blr(rscratch1);
>        __ bind(retaddr);
>        __ post_call_nop();
> -      __ add(sp, sp, 2 * wordSize);
>      }
>      if (Compile::current()->max_vector_size() > 0) {
>        __ reinitialize_ptrue();

Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
@RealFYang I made the equivalent change for riscv, could you verify it's okay?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828186069

From fyang at openjdk.org  Wed Nov  6 17:40:02 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zER
 h0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>
Message-ID: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.2ee1a7b5-b3f9-4093-b8ca-07684cca63a7@github.com>

On Mon, 4 Nov 2024 18:18:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Here's my suggested C2 change:
>> 
>> diff --git a/src/hotspot/cpu/aarch64/aarch64.ad b/src/hotspot/cpu/aarch64/aarch64.ad
>> index d9c77a2f529..1e99db191ae 100644
>> --- a/src/hotspot/cpu/aarch64/aarch64.ad
>> +++ b/src/hotspot/cpu/aarch64/aarch64.ad
>> @@ -3692,14 +3692,13 @@ encode %{
>>        __ post_call_nop();
>>      } else {
>>        Label retaddr;
>> +      // Make the anchor frame walkable
>>        __ adr(rscratch2, retaddr);
>> +      __ str(rscratch2, Address(rthread, JavaThread::last_Java_pc_offset()));
>>        __ lea(rscratch1, RuntimeAddress(entry));
>> -      // Leave a breadcrumb for JavaFrameAnchor::capture_last_Java_pc()
>> -      __ stp(zr, rscratch2, Address(__ pre(sp, -2 * wordSize)));
>>        __ blr(rscratch1);
>>        __ bind(retaddr);
>>        __ post_call_nop();
>> -      __ add(sp, sp, 2 * wordSize);
>>      }
>>      if (Compile::current()->max_vector_size() > 0) {
>>        __ reinitialize_ptrue();
>
> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
> @RealFYang I made the equivalent change for riscv, could you verify it's okay?

@pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
`hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.

BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
Do you mind adding following small addon change to fix it? Thanks.

diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
index 84a292242c3..ac28f4b3514 100644
--- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
+++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
@@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
   if (LockingMode != LM_LEGACY) {
     // Check preemption for Object.wait()
     Label not_preempted;
-    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ beqz(t0, not_preempted);
+    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
+    __ beqz(t1, not_preempted);
     __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
-    __ jr(t0);
+    __ jr(t1);
     __ bind(native_return);
     __ restore_after_resume(true /* is_native */);
     // reload result_handler

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828797495

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.2ee1a7b5-b3f9-4093-b8ca-07684cca63a7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <ylqM1a31N3SrhK3axmNDu8-b0fpOxBnUhWJoS0Ve0zc=.b31ca587-1b4f-4529-b9b6-f7273bfd5a08@github.com>
 <GQpuEi1PLat-3ogK5oRjIrj-XKwhiZhII6Ip4n5igWQ=.473e41cb-6513-49e7-b8f4-8ac703ed4e46@github.com>
 <q4TAaZPBlpTIww9P47pSIj5yMIEjE-TrZoOdxd7YbAU=.d086fe3c-37d6-49de-891b-47ee90d84a5d@github.com>
 <ueevRlSzepXTkEXx9GY6o1sWVX0hjWXKRW8p9O6T0jI=.40cf9549-f3ad-48cd-b2ae-aa9591fe26a5@github.com>
 <Y74DD8ipaPNHO8G-DSEYklYNrm4YH7QY_HnfweRjLyI=.0af4b2d5-bbcb-4579-8649-a70a2e6d0831@github.com>
 <g7SMZwCc7bye8_SDOn8TU2vYXoFH1Z-sUKFmFxNdVvg=.b40bd478-85d9-4cbc-b5f7-6b125d2e3a00@github.com>
 <JB9vVGSWjf0kGAEB3UR_CKXmBoL2CAcGkDYfpzdVVZI=.3852dfd0-8bb7-4bb5-8589-e7a1abb4b8c9@github.com>
 <QkBIa0qtsaZOuHZVGY6tbz3fwpHB5ELNrtySG-ah6IA=.d3667617-13ab-4eb7-9574-01cd5641becb@github.com>
 <UqiGyEyul0X9Q2uehpGF60Qvtu9v9ar6zER
 h0wBqdKs=.a1fd15ef-e4b0-4fb4-aab2-3ccfa06de701@github.com>
 <rx0Fa9yc7iKKMqBjFrg9v-X6sMri-vp7n4MNxt9XCUY=.118c89ce-219a-438c-b90b-8f53965b2dd4@github.com>
 <pmFCTMvP9NkqW2LC5CKRULQ8cSKTeMTgSdpCAX-kYUk=.2ee1a7b5-b3f9-4093-b8ca-07684cca63a7@github.com>
Message-ID: <Z0J2vBm4Z7jT_aibhLEjVlN3tMtVt4kPuxrXg28hRmY=.c14859e0-5fad-4cd9-805c-6a92b4b0a1ac@github.com>

On Tue, 5 Nov 2024 06:30:55 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Great, thanks Dean. I removed `possibly_adjust_frame()` and the related code.
>> @RealFYang I made the equivalent change for riscv, could you verify it's okay?
>
> @pchilano : Hi, Great to see `possibly_adjust_frame()` go away. Nice cleanup!
> `hotspot_loom jdk_loom` still test good with both release and fastdebug builds on linux-riscv64 platform.
> 
> BTW: I noticed one more return miss prediction case which I think was previously missed in https://github.com/openjdk/jdk/pull/21565/commits/32840de91953a5e50c85217f2a51fc5a901682a2
> Do you mind adding following small addon change to fix it? Thanks.
> 
> diff --git a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> index 84a292242c3..ac28f4b3514 100644
> --- a/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> +++ b/src/hotspot/cpu/riscv/templateInterpreterGenerator_riscv.cpp
> @@ -1263,10 +1263,10 @@ address TemplateInterpreterGenerator::generate_native_entry(bool synchronized) {
>    if (LockingMode != LM_LEGACY) {
>      // Check preemption for Object.wait()
>      Label not_preempted;
> -    __ ld(t0, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ beqz(t0, not_preempted);
> +    __ ld(t1, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> +    __ beqz(t1, not_preempted);
>      __ sd(zr, Address(xthread, JavaThread::preempt_alternate_return_offset()));
> -    __ jr(t0);
> +    __ jr(t1);
>      __ bind(native_return);
>      __ restore_after_resume(true /* is_native */);
>      // reload result_handler

Thanks for checking. Added changes to `TemplateInterpreterGenerator::generate_native_entry`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829457335

From dholmes at openjdk.org  Wed Nov  6 17:40:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
Message-ID: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@github.com>

On Fri, 25 Oct 2024 13:11:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1550:
>> 
>>> 1548: #endif /* ASSERT */
>>> 1549: 
>>> 1550:   push_cont_fastpath();
>> 
>> One of the callers of this gives a clue what it does.
>> 
>>   __ push_cont_fastpath(); // Set JavaThread::_cont_fastpath to the sp of the oldest interpreted frame we know about
>> 
>> Why do you do this here?  Oh please more comments...
>
> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.

It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245043

From pchilanomate at openjdk.org  Wed Nov  6 17:40:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:02 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@github.com>
Message-ID: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com>

On Mon, 28 Oct 2024 00:53:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> _cont_fastpath is what we check in freeze_internal to decide if we can take the fast path. Since we are calling from the interpreter we have to take the slow path. Added a comment.
>
> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???

Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819831895

From rrich at openjdk.org  Wed Nov  6 17:40:03 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>

On Sat, 26 Oct 2024 01:40:41 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:
> 
>> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>> 1554:   adr(rscratch1, resume_pc);
>> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));
> 
> Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.

Its indeed difficult to see how the value is propagaged. I think it goes like this:

- read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
- copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
- Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
- Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771

> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
> 
>> 1565: 
>> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
>> 1567:   bind(resume_pc);
> 
> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?

The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack.

At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack.

> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
> 
>> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
>> 3795:   __ testbool(rscratch1);
>> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);
> 
> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?

The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702223
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817702986
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817703994

From dlong at openjdk.org  Wed Nov  6 17:40:03 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
Message-ID: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com>

On Sat, 26 Oct 2024 06:51:08 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1555:
>> 
>>> 1553:   // Make VM call. In case of preemption set last_pc to the one we want to resume to.
>>> 1554:   adr(rscratch1, resume_pc);
>>> 1555:   str(rscratch1, Address(rthread, JavaThread::last_Java_pc_offset()));
>> 
>> Is it really needed to set an alternative last_Java_pc()?  I couldn't find where it's used in a way that would require a different value.
>
> Its indeed difficult to see how the value is propagaged. I think it goes like this:
> 
> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771

Thanks, that's what I was missing.

>> src/hotspot/cpu/aarch64/interp_masm_aarch64.cpp line 1567:
>> 
>>> 1565: 
>>> 1566:   // In case of preemption, this is where we will resume once we finally acquire the monitor.
>>> 1567:   bind(resume_pc);
>> 
>> If the idea is that we return directly to `resume_pc`, because of `last_Java_pc`(), then why do we poll `preempt_alternate_return_offset` above?
>
> The address at `preempt_alternate_return_offset` is how to continue immediately after the call was preempted. It's where the vthread frames are popped off the carrier stack.
> 
> At `resume_pc` execution continues when the vthread becomes runnable again. Before its frames were thawed and copied to its carriers stack.

OK, that makes sense now.

>> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3796:
>> 
>>> 3794:   __ movbool(rscratch1, Address(r15_thread, JavaThread::preemption_cancelled_offset()));
>>> 3795:   __ testbool(rscratch1);
>>> 3796:   __ jcc(Assembler::notZero, preemption_cancelled);
>> 
>> If preemption was canceled, then I wouldn't expect patch_return_pc_with_preempt_stub() to get called.  Does this mean preemption can get canceled (asynchronously be a different thread?) even afgter patch_return_pc_with_preempt_stub() is called?
>
> The comment at the `preemption_cancelled` label explains that a second attempt to acquire the monitor succeeded after freezing. The vthread has to continue execution. For that its frames (removed just above) need to be thawed again.

If preemption was cancelled, we skip over the cleanup.  The native frames haven't been unwound yet.  So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)?  It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled.  Some some finalize actions would be delated, like a two-stage commit.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819586705
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819605366
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819657858

From pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.b9fe7298-4f05-46c8-bd9e-c4f0d5c57315@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>
 <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.b9fe7298-4f05-46c8-bd9e-c4f0d5c57315@github.com>
Message-ID: <793XB62tkVT9w5ix7Ie1Hhxse4WnmnA7baNi__fs0Dw=.b1b308d9-8e8e-4d1d-8cd3-935c637679ab@github.com>

On Wed, 23 Oct 2024 05:56:48 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Also, is it better to have this without assignment.  Which is a nit.
>> Address dst(rthread, JavaThread::held_monitor_count_offset());
>
> The `=` in a variable definition is always construction, never assignment. 
> 
> That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information.

Added comment and fixed dst definition.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813514402

From coleenp at openjdk.org  Wed Nov  6 17:40:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>

On Tue, 22 Oct 2024 15:49:32 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
> 
>> 5339: 
>> 5340: void MacroAssembler::inc_held_monitor_count() {
>> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
> 
> Suggestion:
> 
> // Clobbers: rscratch1 and rscratch2
> void MacroAssembler::inc_held_monitor_count() {
>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Also, is it better to have this without assignment.  Which is a nit.
Address dst(rthread, JavaThread::held_monitor_count_offset());

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811584584

From pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
Message-ID: <FmKOCSsujrPLhOUfXlnZeAeUrWiLQLMmseBgvHuWrsA=.88ba6d7c-d61e-4bcb-894e-a66e2327b73b@github.com>

On Tue, 22 Oct 2024 15:50:15 GMT, Andrew Haley <aph at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5357:
> 
>> 5355: 
>> 5356: void MacroAssembler::dec_held_monitor_count() {
>> 5357:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
> 
> Suggestion:
> 
> // Clobbers: rscratch1 and rscratch2
> void MacroAssembler::dec_held_monitor_count() {
>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());

Added.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813515113

From coleenp at openjdk.org  Wed Nov  6 17:40:03 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
 <Vq2qpgztRszUz8JhG3BDpBruEO9oqGQDl0YWCqW4UwA=.40c632f7-fd86-4c50-9055-0e1ab5a4e9d0@github.com>
 <02jUq4u02-eLrK-60b82BZKUo-M9WmExcZqQrZpRlog=.c929b191-f5d3-4f07-9ba6-5c60602e0441@github.com>
Message-ID: <Iauve4e-TfFi91-Hv_DrqLHSnKCNs5bspnsFy8b737w=.ae0f0912-7bc2-4d1a-a734-090861186113@github.com>

On Mon, 28 Oct 2024 22:04:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> It seems somewhat of an oxymoron that to force a slow path we push a fastpath. ???
>
> Yes, I find the name confusing too. But since this is pre-existent and to avoid the noise in the PR I would rather not change it here.

Yes the comment did seem to contradict the name of the function.  But it's something we can re-examine at some later time.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819858784

From aboldtch at openjdk.org  Wed Nov  6 17:40:03 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <ZB7jhViZsUldR_fW8AhTaF-eCXqHOp5Z9YPgewhaI_A=.281c54e0-9a53-464a-9a76-6face9156a57@github.com>
 <Z6zKUESZC5RQ0FlP6UTbu-0nyMY3o2VT69Tf9M267TU=.ab08a421-a285-4935-89a6-847fcf2ece11@github.com>
Message-ID: <lFxavhPsUc6o5EnZzKVybXHLNLhuYxsxGjHVDohFTAU=.b9fe7298-4f05-46c8-bd9e-c4f0d5c57315@github.com>

On Wed, 23 Oct 2024 00:08:54 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/macroAssembler_aarch64.cpp line 5341:
>> 
>>> 5339: 
>>> 5340: void MacroAssembler::inc_held_monitor_count() {
>>> 5341:   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
>> 
>> Suggestion:
>> 
>> // Clobbers: rscratch1 and rscratch2
>> void MacroAssembler::inc_held_monitor_count() {
>>   Address dst = Address(rthread, JavaThread::held_monitor_count_offset());
>
> Also, is it better to have this without assignment.  Which is a nit.
> Address dst(rthread, JavaThread::held_monitor_count_offset());

The `=` in a variable definition is always construction, never assignment. 

That said, I also prefer `Address dst(rthread, JavaThread::held_monitor_count_offset());` Less redundant information.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811925424

From pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
 <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com>
Message-ID: <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.9dfc52ae-a612-4627-86fa-aea562ba92cd@github.com>

On Mon, 28 Oct 2024 18:51:31 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Its indeed difficult to see how the value is propagaged. I think it goes like this:
>> 
>> - read from the frame anchor and set as pc of `_last_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L517
>> - copied to the result of `new_heap_frame`: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L99
>> - Written to the frame here: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/cpu/aarch64/continuationFreezeThaw_aarch64.inline.hpp#L177
>> - Here it's done when freezing fast: https://github.com/pchilano/jdk/blob/66d5385f8a1c84e73cdbf385239089a7a9932a9e/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L771
>
> Thanks, that's what I was missing.

Right, whatever address is in last_Java_pc is the one we are going to freeze for that frame, i.e. that's the address we are going to return to when resuming. For the freeze slow path this was already how it worked before this PR. For the fast path I added a case to correct the last pc that we freeze on preemption, as Richard pointed out in the last link, since otherwise we would freeze a different one. The idea is that if we already freeze the right pc, then on thaw we don't have to do anything. Note that when there are interpreter frames on the stack we always take the slow path.

> If preemption was cancelled, we skip over the cleanup.
>
We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819595482
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819770854

From pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
Message-ID: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>

On Wed, 30 Oct 2024 12:48:02 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/macroAssembler_aarch64.hpp line 945:
> 
>> 943: 
>> 944:   void inc_held_monitor_count();
>> 945:   void dec_held_monitor_count();
> 
> I prefer to pass the `tmp` register as it's done in PPC. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. 
> 
> Suggestion:
> 
>   void inc_held_monitor_count(Register tmp);
>   void dec_held_monitor_count(Register tmp);

Changed.

> src/hotspot/cpu/ppc/macroAssembler_ppc.cpp line 740:
> 
>> 738: void MacroAssembler::clobber_nonvolatile_registers() {
>> 739:   BLOCK_COMMENT("clobber nonvolatile registers {");
>> 740:   Register regs[] = {
> 
> Maybe I've worked in the embedded world for too, but it's always faster and safer to store arrays with values that never change in read only memory.
> Suggestion:
> 
>   static const Register regs[] = {

Added.

> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
> 
>> 271:         ? frame_sp + fsize - frame::sender_sp_offset
>> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
>> 273:         : *(intptr_t**)(hf.sp() - 2);
> 
> Suggestion:
> 
>         : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);

Changed.

> src/hotspot/cpu/riscv/macroAssembler_riscv.hpp line 793:
> 
>> 791: 
>> 792:   void inc_held_monitor_count(Register tmp = t0);
>> 793:   void dec_held_monitor_count(Register tmp = t0);
> 
> I prefer if we don't use any default argument. Manual register allocation is hard as it is, hiding what registers are clobbered makes it even harder. Also it would make it more in line with how it's done in PPC.
> Suggestion:
> 
>   void inc_held_monitor_count(Register tmp);
>   void dec_held_monitor_count(Register tmp);

Changed.

> src/hotspot/share/runtime/continuation.cpp line 125:
> 
>> 123: };
>> 124: 
>> 125: static bool is_safe_vthread_to_preempt_for_jvmti(JavaThread* target, oop vthread) {
> 
> I think the code reads better if you change to `is_safe_to_preempt_vthread_for_jvmti`.
> Suggestion:
> 
> static bool is_safe_to_preempt_vthread_for_jvmti(JavaThread* target, oop vthread) {

I renamed it to is_vthread_safe_to_preempt_for_jvmti.

> src/hotspot/share/runtime/continuation.cpp line 135:
> 
>> 133: #endif // INCLUDE_JVMTI
>> 134: 
>> 135: static bool is_safe_vthread_to_preempt(JavaThread* target, oop vthread) {
> 
> I think the code reads better if you change to `is_safe_to_preempt_vthread`.
> Suggestion:
> 
> static bool is_safe_to_preempt_vthread(JavaThread* target, oop vthread) {

I renamed it to is_vthread_safe_to_preempt, which I think it reads even better.

> src/hotspot/share/runtime/continuation.hpp line 66:
> 
>> 64: 
>> 65:   enum preempt_kind {
>> 66:     freeze_on_monitorenter = 1,
> 
> Is there a reason why the first enumerator doesn't start at zero?

There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:
> 
>> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
>> 888:   } else {
>> 889:     return freeze_pinned_native;
> 
> Can you add a comment about why you only end up here for `freeze_pinned_native`, cause that is not clear to me.

We just found a frame that can't be freezed, most likely the call_stub or upcall_stub which indicate there are further natives frames up the stack. I added a comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1193:
> 
>> 1191:   }
>> 1192: 
>> 1193:   assert(node->TState == ObjectWaiter::TS_ENTER || node->TState == ObjectWaiter::TS_CXQ, "");
> 
> In `ObjectMonitor::resume_operation()` the exact same line is a  `guarantee`- not an `assert`-line, is there any reason why?

The `guarantee` tries to mimic the one here: https://github.com/openjdk/jdk/blob/ae82cc1ba101f6c566278f79a2e94bd1d1dd9efe/src/hotspot/share/runtime/objectMonitor.cpp#L1613
The assert at the epilogue is probably redundant. Also in `UnlinkAfterAcquire`, the else branch already asserts `ObjectWaiter::TS_CXQ`. I removed it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101744
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825108078
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825100526
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825101246
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825107036
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825102359
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825103008
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825104666
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825106368

From fbredberg at openjdk.org  Wed Nov  6 17:40:03 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
Message-ID: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.abe1aa76-ee6c-493b-b93d-31ec7b0ea5d0@github.com>

On Fri, 25 Oct 2024 13:11:38 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/sharedRuntime_aarch64.cpp line 2032:
>> 
>>> 2030:     // Force freeze slow path in case we try to preempt. We will pin the
>>> 2031:     // vthread to the carrier (see FreezeBase::recurse_freeze_native_frame()).
>>> 2032:     __ push_cont_fastpath();
>> 
>> We need to do this because we might freeze, so JavaThread::_cont_fastpath should be set in case we do?
>
> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.

It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820487130

From pchilanomate at openjdk.org  Wed Nov  6 17:40:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.abe1aa76-ee6c-493b-b93d-31ec7b0ea5d0@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
 <H1ivnQi43GS6q3NGOlb4G7O5XFIqcTsSqeba4SrKBBs=.abe1aa76-ee6c-493b-b93d-31ec7b0ea5d0@github.com>
Message-ID: <6y2W6yaKBLRBbNe-yP_lenR4PMPbWb1Pa9wS3VpFGcI=.0465a56a-7cf4-4455-82c6-4097a3f8e456@github.com>

On Tue, 29 Oct 2024 10:06:01 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> Right. We want to take the slow path to find the compiled native wrapper frame and fail to freeze. Otherwise the fast path won't find it since we don't walk the stack.
>
> It would be nice if Coleen's question and your answer could be turned into a source comment. It really describes what's going more clearly than the current comment.

I updated the comment.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821386261

From coleenp at openjdk.org  Wed Nov  6 17:40:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>

On Sat, 26 Oct 2024 01:51:12 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
> 
>> 117:   return  mask.num_oops()
>> 118:         + 1 // for the mirror oop
>> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot
> 
> Where is this temp oop slot set and used?

It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:
> 
>> 1409:     // zero out fields (but not the stack)
>> 1410:     const size_t hs = oopDesc::header_size();
>> 1411:     oopDesc::set_klass_gap(mem, 0);
> 
> Why, bug fix or cleanup?

This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819394224
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823227312

From pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
Message-ID: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>

On Mon, 28 Oct 2024 20:10:16 GMT, Dean Long <dlong at openjdk.org> wrote:

>> It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.
>
> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?

When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819757374

From dlong at openjdk.org  Wed Nov  6 17:40:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
Message-ID: <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>

On Mon, 28 Oct 2024 16:39:14 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/cpu/aarch64/stackChunkFrameStream_aarch64.inline.hpp line 119:
>> 
>>> 117:   return  mask.num_oops()
>>> 118:         + 1 // for the mirror oop
>>> 119:         + (f.interpreter_frame_method()->is_native() ? 1 : 0) // temp oop slot
>> 
>> Where is this temp oop slot set and used?
>
> It's the offset of the mirror passed to static native calls.  It pre-existed saving the mirror in all frames to keep the Method alive, and is duplicated.  I think this could be cleaned up someday, which would remove this special case.

I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819687576

From coleenp at openjdk.org  Wed Nov  6 17:40:04 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
Message-ID: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>

On Mon, 28 Oct 2024 21:01:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I tried to track down how interpreter_frame_num_oops() is used, and as far as I can tell, it is only used to compare against the bitmap in debug/verify code.  So if this slot was added here, shouldn't there be a corresponding change for the bitmap?
>
> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.

What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819869538

From dlong at openjdk.org  Wed Nov  6 17:40:04 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
Message-ID: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@github.com>

On Mon, 28 Oct 2024 22:52:40 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> When creating the bitmap, processing oops in an interpreter frame is done with `frame::oops_interpreted_do()` which already counts this extra oop for native methods.
>
> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.

So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819887000

From pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@github.com>
Message-ID: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.ed8a2f3a-0ef3-48d5-bdd9-b784cb53021f@github.com>

On Mon, 28 Oct 2024 23:21:14 GMT, Dean Long <dlong at openjdk.org> wrote:

>> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change?  in MaskFillerForNative::set_one.
>
> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.

> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one.
>
The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Object reference. But for synchronized native methods there could be more.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819908946

From pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.ed8a2f3a-0ef3-48d5-bdd9-b784cb53021f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <L5VYVW8sPc4JHDF2HIyq4RycuOeJQ3R3vZEL6EoFoGs=.b38f8fdb-16e8-4f53-bd37-2da2383c3d86@github.com>
 <ltxLtL24mnbMPNCNe6OwK3RAz74CQzgLb7L46B3mth8=.9568550c-7e39-4bfe-99d8-af6f3bc1be8c@github.com>
 <yqgbgCbNRHR6nuETFsxBfMrwj6KT7TNgfERqjWNTTOo=.a484cc9a-1757-40ed-920f-37aaaa9f9756@github.com>
 <IaK8Ic6on08lhNOqp__lxXRPBN2U1cr9BfSZ5Hltew0=.c2852037-7e43-41f2-bc43-ca4e1518d957@github.com>
 <qC-dVxF6ScnJg1QYxHca2ZS252dRdHDv349cq8KMkSg=.ed8a2f3a-0ef3-48d5-bdd9-b784cb53021f@github.com>
Message-ID: <KN4s68yO3KTnPYb3y0eMexToy1B3J9bOQPwDhbuDpk0=.16887faa-af27-4462-b9ae-2d4f1ee1c5f2@github.com>

On Mon, 28 Oct 2024 23:59:55 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before.  Something in this PR exposed the need for this change.
>
>> What are we counting now with MaskFillerForNativeFrame that we weren't counting before this change? in MaskFillerForNative::set_one.
>>
> The number of oops in the parameter's for this native method. For Object.wait() we have only one, the j.l.Object reference. But for synchronized native methods there could be more.

> So it sounds like the adjustment at line 119 is a bug fix, but what I don't understand is why we weren't seeing problems before. Something in this PR exposed the need for this change.
>
Because before this PR we never freezed interpreter frames belonging to native methods.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819909304

From fyang at openjdk.org  Wed Nov  6 17:40:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
Message-ID: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>

On Thu, 31 Oct 2024 20:02:31 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/riscv/continuationFreezeThaw_riscv.inline.hpp line 273:
>> 
>>> 271:         ? frame_sp + fsize - frame::sender_sp_offset
>>> 272:         // we need to re-read fp because it may be an oop and we might have fixed the frame.
>>> 273:         : *(intptr_t**)(hf.sp() - 2);
>> 
>> Suggestion:
>> 
>>         : *(intptr_t**)(hf.sp() - frame::sender_sp_offset);
>
> Changed.

Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 

(PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826453713

From fbredberg at openjdk.org  Wed Nov  6 17:40:04 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
Message-ID: <PEExBTpPubCYRqoBU8sHuhGn7KxgJhWaRkGXiAJ22zA=.a95a2a94-e81a-4570-83a0-dd3cd9639313@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827720269

From duke at openjdk.org  Wed Nov  6 17:45:30 2024
From: duke at openjdk.org (jengebr)
Date: Wed, 6 Nov 2024 17:45:30 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg [v2]
In-Reply-To: <CwDFv6ndMA23N5btyJhOoi0-CYjNJiSQudUZelFaG54=.d9b99093-d52e-42c8-8e3d-a21b15551266@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
 <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
 <4ZT226VcGPQltW-uje_qA0bdntPigpCmwIUeNpckcfo=.194b18ca-0c8e-4299-85bd-b60708a91227@github.com>
 <fIHbESK8uBQ5rip0SXs8ELTdXyDYSV6QVgDVqCBQGHI=.1e04cfd4-3773-4388-b685-63ab1912c489@github.com>
 <CwDFv6ndMA23N5btyJhOoi0-CYjNJiSQudUZelFaG54=.d9b99093-d52e-42c8-8e3d-a21b15551266@github.com>
Message-ID: <kqMkzcCNiJ9-FOItzARd61aTeVuMVOt4zLNTxfS1TxI=.590f2f09-55df-43eb-a462-5c6cb31630a2@github.com>

On Wed, 6 Nov 2024 17:35:36 GMT, Chen Liang <liach at openjdk.org> wrote:

> Note that Arrays.equals is subject to profile pollution at runtime, so the benchmark results might not be applicable in practice.

Good point, thank you.  Should I stick with `Arrays.equals()` on the basis that it's more intuitive, and the perf data is uncertain?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1831468108

From pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
Message-ID: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>

On Sat, 2 Nov 2024 02:41:44 GMT, Fei Yang <fyang at openjdk.org> wrote:

>> Changed.
>
> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
> 
> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)

Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828190876

From pchilanomate at openjdk.org  Wed Nov  6 17:40:04 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
Message-ID: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>

On Mon, 4 Nov 2024 18:22:42 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Note that `frame::sender_sp_offset` is 0 instead of 2 on linux-riscv64, which is different from aarch64 or x86-64. So I think we should revert this change: https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd. @pchilano : Could you please help do that? 
>> 
>> (PS: `hotspot_loom & jdk_loom` still test good with latest version after locally reverting https://github.com/openjdk/jdk/pull/21565/commits/12213a70c1cf0639555f0f302237fd012549c4dd)
>
> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>
I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828191725

From fyang at openjdk.org  Wed Nov  6 17:40:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
Message-ID: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>

On Mon, 4 Nov 2024 18:23:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
>
>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>
> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.

> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.

Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 

> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?

I agree with @pchilano in that we are fine with these places.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828563437

From pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <LXvYQLMhjGyozdv2SaLbBGAv7rujDnS1jd9JyvUTHBw=.27fe7cc4-a530-4c46-98f3-a45a09f1abc2@github.com>

On Tue, 22 Oct 2024 02:14:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/assembler_x86.cpp line 2866:
>> 
>>> 2864:     emit_int32(0);
>>> 2865:   }
>>> 2866: }
>> 
>> Is it possible to make this more general and explicit instead of a sequence of bytes?
>> 
>> Something along the lines of:
>> ```C++
>>   const address tar = L.is_bound() ? target(L) : pc();
>>   const Address adr = Address(checked_cast<int32_t>(tar - pc()), tar, relocInfo::none);
>> 
>>   InstructionMark im(this);
>>   emit_prefix_and_int8(get_prefixq(adr, dst), (unsigned char)0x8D);
>>   if (!L.is_bound()) {
>>     // Patch @0x8D opcode
>>     L.add_patch_at(code(), CodeBuffer::locator(offset() - 1, sect()));
>>   }
>>   // Register and [rip+disp] operand
>>   emit_modrm(0b00, raw_encode(dst), 0b101);
>>   // Adjust displacement by sizeof lea instruction
>>   int32_t disp = adr.disp() - checked_cast<int32_t>(pc() - inst_mark() + sizeof(int32_t));
>>   assert(is_simm32(disp), "must be 32bit offset [rip+offset]");
>>   emit_int32(disp);
>> 
>> 
>> and then in `pd_patch_instruction` simply match `op == 0x8D /* lea */`.
>
> I'll test it out but looks fine.

Done. I simplified the code a bit to make it more readable. It also follows the current style of keeping the cases separate.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811237106

From fyang at openjdk.org  Wed Nov  6 17:40:04 2024
From: fyang at openjdk.org (Fei Yang)
Date: Wed, 6 Nov 2024 17:40:04 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>
Message-ID: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.166a7986-6b40-4399-8940-3620db26c34b@github.com>

On Tue, 5 Nov 2024 00:18:17 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> Also, does this mean that the changes from 2 to frame::sender_sp_offset in all of the lines (267, 271 and 273) should be reverted?
>>>
>> I think the previous lines are okay because we are constructing the fp, whereas in here we want to read the old fp stored in this frame.
>
>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
> 
> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
> 
>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
> 
> I agree with @pchilano in that we are fine with these places.

> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?

Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828566395

From pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.166a7986-6b40-4399-8940-3620db26c34b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <Ulv4J-54ynRjXzqFyrWb86oXHv0VXJybs-InQOnYOnE=.5ab05eaf-15cd-48d7-80d1-ecfdd9f1ff3c@github.com>
 <uRwwrautLfFAgkQg9pyeF8BhCsjpxkeOinZrfkPYCe4=.1458f4e4-c01c-4cc5-894b-998fe1fa8e87@github.com>
 <FBp8FLIsyg7TZHICFGWkDVRwrnI-IrawT57L9xi8a5k=.0292241a-afce-4b80-b548-0cdf42ea4c1a@github.com>
 <7mG_qvORrpMOZ4_Ye25PZyVLmHdtPq2tcalyJTTxwOA=.0b848799-b140-4d77-89aa-20ab815c68df@github.com>
 <Y09RnsOeYoTZmdptGcGg44lqySZXwbMUDnWrpsyY5KY=.166a7986-6b40-4399-8940-3620db26c34b@github.com>
Message-ID: <B6yKYX170EzYJUUBWPDAOJmNDGNVRsSXi4OBHWmh4TU=.727aef83-4bdb-4bc2-8139-c1f7909ba583@github.com>

On Tue, 5 Nov 2024 00:23:37 GMT, Fei Yang <fyang at openjdk.org> wrote:

>>> As the same code on aarch64 and x86-64 uses `frame::sender_sp_offset` I suggested to change the literal 2 into `frame::sender_sp_offset` in order to increase the readability, but I forgot that `frame::sender_sp_offset` is 0 on riscv64. However I do think it's a problem that several places throughout the code base uses a literal 2 when it should really be `frame::sender_sp_offset`. This type of code is very fiddly and I think we should do what we can to increase the readability, so maybe we need another `frame::XYZ` constant that is 2 for this case.
>> 
>> Yeah, I was also considering this issue when we were porting loom. I guess maybe `frame::metadata_words` which equals 2. Since this is not the only place, I would suggest we do a separate cleanup PR. 
>> 
>>> Also, does this mean that the changes from 2 to `frame::sender_sp_offset` in all of the lines (267, 271 and 273) should be reverted?
>> 
>> I agree with @pchilano in that we are fine with these places.
>
>> Sorry, I also thought it matched the aarch64 one without checking. @RealFYang should I change it for `hf.sp() + frame::link_offset` or just leave it as it was?
> 
> Or maybe `hf.sp() - frame::metadata_words`. But since we have several other occurrences, I would suggest we leave it as it was and go with a separate PR for the cleanup.

Reverted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615499

From pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
Message-ID: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>

On Mon, 28 Oct 2024 01:13:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
> 
>> 2380:   __ bind(after_transition);
>> 2381: 
>> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
> 
> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?

Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.

> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>
Yes.

> src/hotspot/share/classfile/javaClasses.cpp line 2086:
> 
>> 2084:   jboolean vthread_on_list = Atomic::load(addr);
>> 2085:   if (!vthread_on_list) {
>> 2086:     vthread_on_list = Atomic::cmpxchg(addr, (jboolean)JNI_FALSE, (jboolean)JNI_TRUE);
> 
> It is not clear who the racing participants are here. How can the same thread be being placed on the list from two different actions?

The same example mentioned above, with a different timing, could result in two threads trying to add the same virtual thread to the list at the same time.

> src/hotspot/share/code/nmethod.cpp line 711:
> 
>> 709:   // handle the case of an anchor explicitly set in continuation code that doesn't have a callee
>> 710:   JavaThread* thread = reg_map->thread();
>> 711:   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {
> 
> Suggestion:
> 
>   if ((thread->has_last_Java_frame() && fr.sp() == thread->last_Java_sp()) 
>       JVMTI_ONLY(|| (method()->is_continuation_enter_intrinsic() && thread->on_monitor_waited_event()))) {

Fixed.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 889:
> 
>> 887:     return f.is_native_frame() ? recurse_freeze_native_frame(f, caller) : recurse_freeze_stub_frame(f, caller);
>> 888:   } else {
>> 889:     // frame can't be freezed. Most likely the call_stub or upcall_stub
> 
> Suggestion:
> 
>     // Frame can't be frozen. Most likely the call_stub or upcall_stub

Fixed.

> src/hotspot/share/runtime/javaThread.hpp line 165:
> 
>> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporal value.
> 
> Suggestion:
> 
>   // attached thread cases where this field can have a temporary value.
> 
> Presumably this is for when the attaching thread is executing the Thread constructor?

Exactly.

> src/hotspot/share/runtime/javaThread.hpp line 166:
> 
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporary value. Also,
>> 166:   // calls to VirtualThread.switchToCarrierThread will temporary change _vthread
> 
> s/temporary change/temporarily change/

Fixed.

> src/hotspot/share/runtime/objectMonitor.cpp line 132:
> 
>> 130: 
>> 131: // -----------------------------------------------------------------------------
>> 132: // Theory of operations -- Monitors lists, thread residency, etc:
> 
> This comment block needs updating now owner is not a JavaThread*, and to account for vthread usage

Updated comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1140:
> 
>> 1138: }
>> 1139: 
>> 1140: bool ObjectMonitor::resume_operation(JavaThread* current, ObjectWaiter* node, ContinuationWrapper& cont) {
> 
> Explanatory comment would be good - thanks.

Added comment.

> src/hotspot/share/runtime/objectMonitor.cpp line 1532:
> 
>> 1530:   } else if (java_lang_VirtualThread::set_onWaitingList(vthread, vthread_cxq_head())) {
>> 1531:     // Virtual thread case.
>> 1532:     Trigger->unpark();
> 
> So ignoring for the moment that I can't see how `set_onWaitingList` could return false here, the check is just an optimisation to reduce the number of unparks issued i.e. only unpark if the list has changed?

Right.

> src/hotspot/share/runtime/objectMonitor.cpp line 1673:
> 
>> 1671: 
>> 1672:   ContinuationEntry* ce = current->last_continuation();
>> 1673:   if (interruptible && ce != nullptr && ce->is_virtual_thread()) {
> 
> So IIUC this use of `interruptible` would be explained as follows:
> 
> // Some calls to wait() occur in contexts that still have to pin a vthread to its carrier.
> // All such contexts perform non-interruptible waits, so by checking `interruptible` we know 
> // this is a regular Object.wait call.

Yes, although the non-interruptible call is coming from ObjectLocker, which already has the NoPreemptMark, so I removed this check.

> src/hotspot/share/runtime/objectMonitor.cpp line 1706:
> 
>> 1704:     // on _WaitSetLock so it's not profitable to reduce the length of the
>> 1705:     // critical section.
>> 1706: 
> 
> Please restore the blank line, else it looks like the comment block pertains to the `wait_reenter_begin`, but it doesn't.

Restored.

> src/hotspot/share/runtime/objectMonitor.cpp line 2028:
> 
>> 2026:   // First time we run after being preempted on Object.wait().
>> 2027:   // Check if we were interrupted or the wait timed-out, and in
>> 2028:   // that case remove ourselves from the _WaitSet queue.
> 
> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.

This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.

> src/hotspot/share/runtime/objectMonitor.cpp line 2054:
> 
>> 2052:   // Mark that we are at reenter so that we don't call this method again.
>> 2053:   node->_at_reenter = true;
>> 2054:   assert(!has_owner(current), "invariant");
> 
> The position of this assert seems odd as it seems to be something that should hold at entry to this method.

Ok, I moved it to the beginning of resume_operation.

> src/hotspot/share/runtime/objectMonitor.hpp line 47:
> 
>> 45: // ParkEvent instead.  Beware, however, that the JVMTI code
>> 46: // knows about ObjectWaiters, so we'll have to reconcile that code.
>> 47: // See next_waiter(), first_waiter(), etc.
> 
> This to-do is likely no longer relevant with the current changes.

Removed.

> src/hotspot/share/runtime/objectMonitor.hpp line 207:
> 
>> 205: 
>> 206:   static void Initialize();
>> 207:   static void Initialize2();
> 
> Please add comment why this needs to be deferred - and till after what?

Added comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 288:
> 
>> 286:   // Returns true if this OM has an owner, false otherwise.
>> 287:   bool      has_owner() const;
>> 288:   int64_t   owner() const;  // Returns null if DEFLATER_MARKER is observed.
> 
> null is not an int64_t value.

Changed to NO_OWNER.

> src/hotspot/share/runtime/objectMonitor.hpp line 292:
> 
>> 290: 
>> 291:   static int64_t owner_for(JavaThread* thread);
>> 292:   static int64_t owner_for_oop(oop vthread);
> 
> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?

I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id.

> src/hotspot/share/runtime/objectMonitor.hpp line 299:
> 
>> 297:   // Simply set _owner field to new_value; current value must match old_value.
>> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 299:   // Same as above but uses tid of current as new value.
> 
> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?

It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id.

> src/hotspot/share/runtime/objectMonitor.hpp line 302:
> 
>> 300:   // Simply set _owner field to new_value; current value must match old_value.
>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
> 
> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.

I added a comment. How about s/old_value/old_tid and s/new_value/new_tid?

> src/hotspot/share/runtime/objectMonitor.hpp line 302:
> 
>> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
>> 302:   void      set_owner_from_BasicLock(JavaThread* current);
> 
> Shouldn't tid there be the basicLock?

So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.

> src/hotspot/share/runtime/objectMonitor.hpp line 303:
> 
>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 303:   // Simply set _owner field to current; current value must match basic_lock_p.
> 
> Comment is no longer accurate

Fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 309:
> 
>> 307:   // _owner field. Returns the prior value of the _owner field.
>> 308:   int64_t   try_set_owner_from_raw(int64_t old_value, int64_t new_value);
>> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
> 
> Similar to set_owner* need better comments describing API.

Added similar comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 311:
> 
>> 309:   int64_t   try_set_owner_from(int64_t old_value, JavaThread* current);
>> 310: 
>> 311:   bool      is_succesor(JavaThread* thread);
> 
> I think `has_successor` is more appropriate here as it is not the monitor that is the successor.

Right, changed.

> src/hotspot/share/runtime/objectMonitor.hpp line 312:
> 
>> 310:   void      set_successor(JavaThread* thread);
>> 311:   void      set_successor(oop vthread);
>> 312:   void      clear_successor();
> 
> Needs descriptive comments, or at least a preceding comment explaining what a "successor" is.

Added comment.

> src/hotspot/share/runtime/objectMonitor.hpp line 315:
> 
>> 313:   void      set_succesor(oop vthread);
>> 314:   void      clear_succesor();
>> 315:   bool      has_succesor();
> 
> Sorry but `successor` has two `s` before `or`.

Fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 317:
> 
>> 315:   bool      has_succesor();
>> 316: 
>> 317:   bool is_owner(JavaThread* thread) const { return owner() == owner_for(thread); }
> 
> Again `has_owner` seems more appropriate

Yes, changed.

> src/hotspot/share/runtime/objectMonitor.hpp line 323:
> 
>> 321:   }
>> 322: 
>> 323:   bool is_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }
> 
> Again I struggle with the pre-existing `is_owner` formulation here. The target of the expression is a monitor and we are asking if the monitor has an anonymous owner.

I changed it to `has_owner_anonymous`.

> src/hotspot/share/runtime/objectMonitor.hpp line 333:
> 
>> 331:   bool is_stack_locker(JavaThread* current);
>> 332:   BasicLock* stack_locker() const;
>> 333:   void set_stack_locker(BasicLock* locker);
> 
> Again `is` versus `has`, plus some general comments describing the API.

Fixed and added comments.

> src/hotspot/share/runtime/objectMonitor.hpp line 334:
> 
>> 332: 
>> 333:   // Returns true if BasicLock* stored in _stack_locker
>> 334:   // points to current's stack, false othwerwise.
> 
> Suggestion:
> 
>   // points to current's stack, false otherwise.

Fixed.

> src/hotspot/share/runtime/objectMonitor.hpp line 349:
> 
>> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
>> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
>> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }
> 
> This no longer looks correct if the waiter is a vthread. ??

It is, we still increment _waiters for the vthread case.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 110:
> 
>> 108: }
>> 109: 
>> 110: // Returns null if DEFLATER_MARKER is observed.
> 
> Comment needs updating

Updated.

> src/hotspot/share/runtime/objectMonitor.inline.hpp line 130:
> 
>> 128: // Returns true if owner field == DEFLATER_MARKER and false otherwise.
>> 129: // This accessor is called when we really need to know if the owner
>> 130: // field == DEFLATER_MARKER and any non-null value won't do the trick.
> 
> Comment needs updating

Updated. Removed the second sentence, seemed redundant.

> src/hotspot/share/runtime/synchronizer.cpp line 670:
> 
>> 668:   // Top native frames in the stack will not be seen if we attempt
>> 669:   // preemption, since we start walking from the last Java anchor.
>> 670:   NoPreemptMark npm(current);
> 
> Don't we still pin for JNI monitor usage?

Only when facing contention on this call. But once we have the monitor we don't.

> src/hotspot/share/runtime/synchronizer.hpp line 172:
> 
>> 170: 
>> 171:   // Iterate ObjectMonitors where the owner is thread; this does NOT include
>> 172:   // ObjectMonitors where owner is set to a stack lock address in thread.
> 
> Comment needs updating

Updated.

> src/hotspot/share/runtime/threadIdentifier.cpp line 30:
> 
>> 28: 
>> 29: // starting at 3, excluding reserved values defined in ObjectMonitor.hpp
>> 30: static const int64_t INITIAL_TID = 3;
> 
> Can we express this in terms of those reserved values, or are they inaccessible?

Yes, we could define a new public constant `static const int64_t FIRST_AVAILABLE_TID = 3` (or some similar name) and use it here:


diff --git a/src/hotspot/share/runtime/threadIdentifier.cpp b/src/hotspot/share/runtime/threadIdentifier.cpp
index 60d6a990779..710c3141768 100644
--- a/src/hotspot/share/runtime/threadIdentifier.cpp
+++ b/src/hotspot/share/runtime/threadIdentifier.cpp
@@ -24,15 +24,15 @@

 #include "precompiled.hpp"
 #include "runtime/atomic.hpp"
+#include "runtime/objectMonitor.hpp"
 #include "runtime/threadIdentifier.hpp"

-// starting at 3, excluding reserved values defined in ObjectMonitor.hpp
-static const int64_t INITIAL_TID = 3;
-static volatile int64_t next_thread_id = INITIAL_TID;
+// excluding reserved values defined in ObjectMonitor.hpp
+static volatile int64_t next_thread_id = ObjectMonitor::FIRST_AVAILABLE_TID;

 #ifdef ASSERT
 int64_t ThreadIdentifier::initial() {
-  return INITIAL_TID;
+  return ObjectMonitor::FIRST_AVAILABLE_TID;
 }
 #endif

Or maybe define it as MAX_RESERVED_TID instead, and here we would add one to it.

> src/hotspot/share/services/threadService.cpp line 467:
> 
>> 465:         if (waitingToLockMonitor->has_owner()) {
>> 466:           currentThread = Threads::owning_thread_from_monitor(t_list, waitingToLockMonitor);
>> 467:           // If currentThread is nullptr we would like to know if the owner
> 
> Suggestion:
> 
>           // If currentThread is null we would like to know if the owner

Fixed.

> src/hotspot/share/services/threadService.cpp line 474:
> 
>> 472:           // vthread we never record this as a deadlock. Note: unless there
>> 473:           // is a bug in the VM, or a thread exits without releasing monitors
>> 474:           // acquired through JNI, nullptr should imply unmounted vthread owner.
> 
> Suggestion:
> 
>           // acquired through JNI, null should imply an unmounted vthread owner.

Fixed.

> src/java.base/share/classes/java/lang/Object.java line 383:
> 
>> 381:             try {
>> 382:                 wait0(timeoutMillis);
>> 383:             } catch (InterruptedException e) {
> 
> I had expected to see a call to a new `wait0` method that returned a value indicating whether the wait was completed or else we had to park. Instead we had to put special logic in the native-call-wrapper code in the VM to detect returning from wait0 and changing the return address. I'm still unclear where that modified return address actually takes us.

We jump to `StubRoutines::cont_preempt_stub()`. We need to remove all the frames that were just copied to the heap from the physical stack, and then return to the calling method which will be `Continuation.run`.

> src/java.base/share/classes/java/lang/Thread.java line 654:
> 
>> 652:      * {@link Thread#PRIMORDIAL_TID}&nbsp;+1 as this class cannot be used during
>> 653:      * early startup to generate the identifier for the primordial thread. The
>> 654:      * counter is off-heap and shared with the VM to allow it assign thread
> 
> Suggestion:
> 
>      * counter is off-heap and shared with the VM to allow it to assign thread

Fixed.

> src/java.base/share/classes/java/lang/Thread.java line 731:
> 
>> 729: 
>> 730:         if (attached && VM.initLevel() < 1) {
>> 731:             this.tid = 3;  // primordial thread
> 
> The comment before the `ThreadIdentifiers` class needs updating to account for this change.

Fixed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 109:
> 
>> 107:      *
>> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
> 
> Should this say something similar to the parked case, about the "yield" being successful?

Since the unmount is triggered from the VM we never call yieldContinuation(), unlike with the PARKING case. In other words, there are no two cases to handle. If freezing the continuation fails, the virtual thread will already block in the monitor code pinned to the carrier, so a state of BLOCKING means freezing the continuation succeeded.

> src/java.base/share/classes/java/lang/VirtualThread.java line 110:
> 
>> 108:      *   RUNNING -> BLOCKING       // blocking on monitor enter
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
> 
> Does this mean it now owns the monitor, or just it is able to re-contest for monitor entry?

It means it is scheduled to run again and re-contest for the monitor.

> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
> 
>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
>> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter
> 
> Presumably this one means it acquired the monitor?

Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.

> src/java.base/share/classes/java/lang/VirtualThread.java line 631:
> 
>> 629:         // Object.wait
>> 630:         if (s == WAITING || s == TIMED_WAITING) {
>> 631:             byte nonce;
> 
> Suggestion:
> 
>             byte seqNo;

Changed to seqNo.

> src/java.base/share/classes/java/lang/VirtualThread.java line 948:
> 
>> 946:      * This method does nothing if the thread has been woken by notify or interrupt.
>> 947:      */
>> 948:     private void waitTimeoutExpired(byte nounce) {
> 
> I assume you meant `nonce` here, but please change to `seqNo`.

Changed.

> src/java.base/share/classes/java/lang/VirtualThread.java line 952:
> 
>> 950:         for (;;) {
>> 951:             boolean unblocked = false;
>> 952:             synchronized (timedWaitLock()) {
> 
> Where is the overall design of the timed-wait protocol and it use of synchronization described?

When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.

> src/java.base/share/classes/java/lang/VirtualThread.java line 1397:
> 
>> 1395: 
>> 1396:     /**
>> 1397:      * Returns a lock object to coordinating timed-wait setup and timeout handling.
> 
> Suggestion:
> 
>      * Returns a lock object for coordinating timed-wait setup and timeout handling.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819744051
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817192967
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195264
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195487
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826154797
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1805830255
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700441
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828195851
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196602
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817197017
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817388840
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817199027
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200025
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200202
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596618
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200507
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811596855
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600012
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813525449
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811600739
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187730
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601098
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601168
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601545
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195731
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601472
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601619
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811601871
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811602000
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814187856
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817195899
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196260
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817196374
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200860
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817200711
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237094
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155159
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826155815
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701043
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815693906
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813237507
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239314
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813239799
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240352
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815699934
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700133
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817190381
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815700312

From dlong at openjdk.org  Wed Nov  6 17:40:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@github.com>

On Mon, 28 Oct 2024 20:49:45 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/cpu/x86/sharedRuntime_x86_64.cpp line 2382:
>> 
>>> 2380:   __ bind(after_transition);
>>> 2381: 
>>> 2382:   if (LockingMode != LM_LEGACY && method->is_object_wait0()) {
>> 
>> It bothers me that we have to add a check for a specific native method in this code (notwithstanding there are already some checks in relation to hashCode). As a follow up I wonder if we can deal with wait-preemption by rewriting the Java code, instead of special casing the wait0 native code?
>
> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.

It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.

I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819880228

From dholmes at openjdk.org  Wed Nov  6 17:40:05 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@github.com>
Message-ID: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.8ffd30af-7f13-4cd6-a9d8-ca7cf73e7a98@github.com>

On Mon, 28 Oct 2024 23:09:58 GMT, Dean Long <dlong at openjdk.org> wrote:

>> Not sure. We would have to return from wait0 and immediately clear the physical stack from the frames just copied without safepoint polls in the middle. Otherwise if someone walks the thread's stack it will find the frames appearing twice: in the physical stack and in the heap.
>
> It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.
> 
> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.

Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820337946

From pchilanomate at openjdk.org  Wed Nov  6 17:40:05 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.8ffd30af-7f13-4cd6-a9d8-ca7cf73e7a98@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <DRadhWgNyqXSSsvhCsfpdSCcKNLnkOkef4Sq3bBrNPo=.182f8b05-34bf-4736-9ab2-b2f9c8ed5c96@github.com>
 <xhfOO6RbWmW_VCu9yRVaU2XJtVYbV7h6k768zCP4CYc=.8ffd30af-7f13-4cd6-a9d8-ca7cf73e7a98@github.com>
Message-ID: <E5BoDn6nBa-B8W6bUd-RciLLaEMNTcF4YVT2JlpCXGg=.cc56de01-4821-4250-9b86-f4e2f969e2be@github.com>

On Tue, 29 Oct 2024 08:29:55 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> It's conceivable that in the future we might have more native methods we want to preempt.  Instead of enumerating them all, we could set a flag on the method.
>> 
>> I was assuming that David was suggesting we have the Java caller do a yield() or something, instead of having the native code call freeze.
>
> Yes. Instead of calling wait0 for a virtual thread we would call another method `needToBlockForWait` that enqueues the VT in the wait-set, releases the monitor and returns true so that caller can then "yield". It would return false if there was no longer a need to block.

It's not that straightforward because the freeze can fail. By then we would have already started the wait call as a virtual thread though, not a platform thread. Maybe we could try to freeze before the wait0 call. We always have the option to use a flag in the method as Dean suggests instead of checking for a specific one. Since now there is only `Object.wait()` I think it's better to explicitly check for it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1821391532

From dlong at openjdk.org  Wed Nov  6 17:40:05 2024
From: dlong at openjdk.org (Dean Long)
Date: Wed, 6 Nov 2024 17:40:05 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.9dfc52ae-a612-4627-86fa-aea562ba92cd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <FY0shC6CwpI0OJ1OvWCZZx-EGjXw2EtjV8NNm-U9-Vg=.9b37344d-c594-436c-8e78-dd2b5282e950@github.com>
 <0sBoylO-R8bzljeR2flD5IyY3qS1AoaMarnP1mzoxMk=.fb41dbbd-8e96-4b54-920b-3f3759579de8@github.com>
 <KL6CandpJh_a9CtWFGey-pgY8W9xuVTPaDaFUIrSgjk=.9dfc52ae-a612-4627-86fa-aea562ba92cd@github.com>
Message-ID: <kIzpbt39CsWh1gBz35CCjVl8f7vkM_2dZp84RE0OC_U=.4ceea7be-bcbf-4ba9-872e-c0cb71b47468@github.com>

On Mon, 28 Oct 2024 21:13:33 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If preemption was cancelled, we skip over the cleanup.  The native frames haven't been unwound yet.  So when we call thaw, does it cleanup the native frames first, or does it copy the frames back on top of the existing frames (overwrite)?  It seems like we could avoid redundant copying if we could somehow throw out the freeze data and use the native frames still on the stack, which would probably involve not patching in this stub until we know that the preemption wasn't canceled.  Some some finalize actions would be delated, like a two-stage commit.
>
>> If preemption was cancelled, we skip over the cleanup.
>>
> We only skip the cleanup for the enterSpecial frame since we are going to call thaw again, all other frames are removed: https://github.com/openjdk/jdk/pull/21565/files#diff-b938ab8a7bd9f57eb02271e2dd24a305bca30f06e9f8b028e18a139c4908ec92R3791

OK got it.  I guess it's too early to know if it's worth it to further optimize this case, which is hopefully rare.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819865539

From pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>

On Fri, 25 Oct 2024 18:39:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2082:
>> 
>>> 2080: }
>>> 2081: 
>>> 2082: bool java_lang_VirtualThread::set_onWaitingList(oop vthread, OopHandle& list_head) {
>> 
>> Some comments here about the operation would be useful. The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>> 
>> I'm struggling to understand how a thread can already be on this list?
>
>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>>
> Yes.

> Some comments here about the operation would be useful.
>
Added a comment.

>> src/hotspot/share/runtime/javaThread.hpp line 165:
>> 
>>> 163:   // ID used as owner for inflated monitors. Same as the j.l.Thread.tid of the
>>> 164:   // current _vthread object, except during creation of the primordial and JNI
>>> 165:   // attached thread cases where this field can have a temporal value.
>> 
>> Suggestion:
>> 
>>   // attached thread cases where this field can have a temporary value.
>> 
>> Presumably this is for when the attaching thread is executing the Thread constructor?
>
> Exactly.

Comment adjusted.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817193493
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809072960

From rrich at openjdk.org  Wed Nov  6 17:40:06 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602:

> 600: 
> 601:   address generate_cont_preempt_stub();
> 602:   address generate_cont_resume_monitor_operation();

The declaration of `generate_cont_resume_monitor_operation` seems to be unused.

src/hotspot/share/runtime/javaThread.hpp line 166:

> 164:   // current _vthread object, except during creation of the primordial and JNI
> 165:   // attached thread cases where this field can have a temporary value.
> 166:   int64_t _lock_id;

Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.

src/hotspot/share/runtime/objectMonitor.hpp line 202:

> 200: 
> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
> 202:   BasicLock* volatile _stack_locker;

IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?

src/hotspot/share/runtime/synchronizer.cpp line 1559:

> 1557:         // and set the stack locker field in the monitor.
> 1558:         m->set_stack_locker(mark.locker());
> 1559:         m->set_anonymous_owner();  // second

Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818523530
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377293
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819029029
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818521820

From pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
Message-ID: <Wz421HivVaSYw32P_FziXYHdelelv3igEJaecq1D0qM=.acbfeb84-fb97-42c1-8221-3f29d3c3a2ab@github.com>

On Mon, 28 Oct 2024 07:55:02 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.hpp line 602:
> 
>> 600: 
>> 601:   address generate_cont_preempt_stub();
>> 602:   address generate_cont_resume_monitor_operation();
> 
> The declaration of `generate_cont_resume_monitor_operation` seems to be unused.

Removed.

> src/hotspot/share/runtime/synchronizer.cpp line 1559:
> 
>> 1557:         // and set the stack locker field in the monitor.
>> 1558:         m->set_stack_locker(mark.locker());
>> 1559:         m->set_anonymous_owner();  // second
> 
> Is it important that this is done after the stack locker is set? I think I saw another comment that indicated that order is important but I cannot find it now.

No, I removed that comment. Both will be visible once we publish the monitor with `object->release_set_mark(markWord::encode(m))`. There was a "first" comment in method ObjectMonitor::set_owner_from_BasicLock() which I removed in [1]. Clearing _stack_locker now happens here in the `mark.has_monitor()` case. The order there doesn't matter either. If some other thread sees that the owner is anonymous and tries to check if he is the owner the comparison will always fail, regardless of reading the BasicLock* value or a nullptr value.

[1] https://github.com/pchilano/jdk/commit/13353fdd6ad3c509b82b1fb0b9a3d05284b592b7#diff-4707eeadeff2ce30c09c4ce8c5a987abf58ac06f7bf78e7717cffa9c36cc392fL195

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746524
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746309

From dholmes at openjdk.org  Wed Nov  6 17:40:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
Message-ID: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@github.com>

On Mon, 28 Oct 2024 00:43:47 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> I'm struggling to understand how a thread can already be on this list?
>>>
>> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.
>
> Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.

That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818245776

From pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
Message-ID: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>

On Fri, 25 Oct 2024 18:39:54 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> The "waiting list" here is just a list of virtual threads that need unparking by the Unblocker thread - right?
>>>
>> Yes.
>
>> Some comments here about the operation would be useful.
>>
> Added a comment.

> I'm struggling to understand how a thread can already be on this list?
>
With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817194346

From dholmes at openjdk.org  Wed Nov  6 17:40:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
Message-ID: <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>

On Fri, 25 Oct 2024 18:40:51 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> Some comments here about the operation would be useful.
>>>
>> Added a comment.
>
>> I'm struggling to understand how a thread can already be on this list?
>>
> With the removal of the _Responsible thread, it's less likely but it could still happen. One case is when the virtual thread acquires the monitor after adding itself to?`_cxq`?in?`ObjectMonitor::VThreadMonitorEnter`. The owner could have released the monitor in?`ExitEpilog`?and already added the virtual thread to the waiting list. The virtual thread will continue running and may face contention on a different monitor. When the owner of this latter monitor picks the virtual thread as the successor it might still find it on the waiting list (unblocker thread did not run yet). The same case can happen in?`ObjectMonitor::resume_operation`?when acquiring the monitor after clearing successor.

Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818242015

From pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@github.com>
Message-ID: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.a419d50c-cb1a-4c86-b909-134a78122d2d@github.com>

On Mon, 28 Oct 2024 00:55:34 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Hmmmm ...  I guess we either slow down the monitor code by having the thread search for and remove itself, or we allow for this and handle it correctly ... okay.
>
> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.

Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail:

|                ThreadA                |                   ThreadB             |           ThreadC             |
| --------------------------------------| --------------------------------------| ---------------------------------------------|
|                                       |                                       |VThreadMonitorEnter:fails to acquire monitorB |
|                                       |                                       |    VThreadMonitorEnter:adds to B's _cxq      |
|                                       | ExitEpilog:picks ThreadC as succesor  |                                              |
|                                       | ExitEpilog:releases monitorB          |                                              |
|                                       |                                       |   VThreadMonitorEnter:acquires monitorB      |
|                                       |                                       |   VThreadMonitorEnter:removes from B's _cxq  |
|                                       |                                       |     continues execution in Java              |
|                                       |                                       |VThreadMonitorEnter:fails to acquire monitorA |
|                                       |                                       |    VThreadMonitorEnter:adds to A's _cxq      |
|  ExitEpilog:picks ThreadC as succesor |                                       |                                              |
|  ExitEpilog:releases monitorA         |                                       |                                              |
|  ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList()  |                                              |

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819829472

From alanb at openjdk.org  Wed Nov  6 17:40:06 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
Message-ID: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>

On Mon, 4 Nov 2024 02:12:40 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/classfile/javaClasses.cpp line 2107:
> 
>> 2105: 
>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>> 2107:   return vthread->long_field(_timeout_offset);
> 
> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??

It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

> src/hotspot/share/prims/jvm.cpp line 4012:
> 
>> 4010:     }
>> 4011:     ThreadBlockInVM tbivm(THREAD);
>> 4012:     parkEvent->park();
> 
> What code does the unpark to wake this thread up? I can't quite see how this unparker thread operates as its logic seems dispersed.

It's very similar to the "Reference Handler" thread. That thread calls into the VM to get the pending-Reference list. Now we have "VirtualThread-unblocker" calling into the VM to get the list of virtual threads to unblock. ObjectMonitor::ExitEpilog will the unpark this thread when the virtual thread successor is on the list to unblock.

> src/java.base/share/classes/java/lang/Thread.java line 655:
> 
>> 653:      * early startup to generate the identifier for the primordial thread. The
>> 654:      * counter is off-heap and shared with the VM to allow it assign thread
>> 655:      * identifiers to non-Java threads.
> 
> Why do non-JavaThreads need an identifier of this kind?

JFR. We haven't changed anything there, just the initial tid.

> src/java.base/share/classes/java/lang/VirtualThread.java line 115:
> 
>> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
>> 114:      *   WAITING -> WAITED         // waiting on monitor
>> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner
> 
> Waiting to re-enter the monitor?

yes

> src/java.base/share/classes/java/lang/VirtualThread.java line 178:
> 
>> 176:     // timed-wait support
>> 177:     private long waitTimeout;
>> 178:     private byte timedWaitNonce;
> 
> Strange name - what does this mean?

Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.

> src/java.base/share/classes/java/lang/VirtualThread.java line 530:
> 
>> 528:                 && carrier == Thread.currentCarrierThread();
>> 529:         carrier.setCurrentThread(carrier);
>> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread
> 
> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??

A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).

More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827219720
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814450822
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814387940
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810579901
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810583267
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810598265

From dholmes at openjdk.org  Wed Nov  6 17:40:06 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.a419d50c-cb1a-4c86-b909-134a78122d2d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <iWt402XS0wiru-VF15dCh7I7ENgVN3t5s3bJ5tA2QXI=.08f46198-0fde-4359-a7b2-420dcb6c1f68@github.com>
 <X-G52MIRc0VOVDjWozplbLkDa2wHFw8MoAYcR02_Tts=.b32667af-fb79-45e9-8c0d-3b7b245b1363@github.com>
 <bh9nV3mbmKJiQ3w8XzClO-QwghNVJUQcH6DrshL76NA=.350ecba3-1cb1-42d2-8d9b-9a9227b84812@github.com>
 <iNFv6SaGHNLvSeEORJIVpmjkZDbWuZXSS_NQW6k6-dk=.99b3f7a1-1550-42da-8213-c88e59919299@github.com>
 <UpJ563I69j2EFcUpBRoxkftLBE6TO5CatO1uHPhYwlI=.a419d50c-cb1a-4c86-b909-134a78122d2d@github.com>
Message-ID: <-1gsoTUPRiypD1etOiePGvVI0vBmYKUy_ltb6C4ADNU=.7a75db37-1cb9-4256-969d-d532b6cdc8e5@github.com>

On Mon, 28 Oct 2024 22:02:02 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> That said such a scenario is not about concurrently pushing the same thread to the list from different threads. So I'm still somewhat confused about the concurrency control here. Specifically I can't see how the cmpxchg on line 2090 could fail.
>
> Let's say ThreadA owns monitorA and ThreadB owns monitorB, here is how the cmpxchg could fail:
> 
> |                ThreadA                |                   ThreadB             |           ThreadC             |
> | --------------------------------------| --------------------------------------| ---------------------------------------------|
> |                                       |                                       |VThreadMonitorEnter:fails to acquire monitorB |
> |                                       |                                       |    VThreadMonitorEnter:adds to B's _cxq      |
> |                                       | ExitEpilog:picks ThreadC as succesor  |                                              |
> |                                       | ExitEpilog:releases monitorB          |                                              |
> |                                       |                                       |   VThreadMonitorEnter:acquires monitorB      |
> |                                       |                                       |   VThreadMonitorEnter:removes from B's _cxq  |
> |                                       |                                       |     continues execution in Java              |
> |                                       |                                       |VThreadMonitorEnter:fails to acquire monitorA |
> |                                       |                                       |    VThreadMonitorEnter:adds to A's _cxq      |
> |  ExitEpilog:picks ThreadC as succesor |                                       |                                              |
> |  ExitEpilog:releases monitorA         |                                       |                                              |
> |  ExitEpilog:calls set_onWaitingList() | ExitEpilog:calls set_onWaitingList()  |                                              |

Thanks for that detailed explanation. It is a bit disconcerting that Thread C could leave a trace on monitors it acquired and released in the distant past. But that is an effect of waking the successor after releasing the monitor (which is generally a good thing for performance). We could potentially re-check the successor (which Thread C will clear) before doing the actual unpark (and set_onWaitingList) but that would just narrow the race window not close it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823394886

From pchilanomate at openjdk.org  Wed Nov  6 17:40:06 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:06 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
Message-ID: <-NVIl6YW1oji4m0sLlL34aIrsJ0zq1_0PlgT6eva-jY=.e2d498b3-8477-48a7-be81-b328c592289e@github.com>

On Mon, 4 Nov 2024 05:52:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/classfile/javaClasses.cpp line 2107:
>> 
>>> 2105: 
>>> 2106: jlong java_lang_VirtualThread::waitTimeout(oop vthread) {
>>> 2107:   return vthread->long_field(_timeout_offset);
>> 
>> Not sure what motivated the name change but it seems odd to have the method named differently to the field it accesses. ??
>
> It was initially parkTimeout and waitTimeout but it doesn't require two fields as you can't be waiting in Object.wait(timeout) and LockSupport.parkNanos at the same time. So the field was renamed, the accessors here should probably be renamed too.

Renamed accessors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828615772

From egahlin at openjdk.org  Wed Nov  6 17:40:07 2024
From: egahlin at openjdk.org (Erik Gahlin)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

src/hotspot/share/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:

https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html

(Note: The fact that the event is now written in the JVM doesn't determine the category.)

src/hotspot/share/jfr/metadata/metadata.xml line 160:

> 158: 
> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />

The label should be "Blocking Operation" with a capital "O".

Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828875263
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828878025

From pchilanomate at openjdk.org  Wed Nov  6 17:40:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.9552fc6e-f2b4-4d36-8637-3313fde3ea80@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
 <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.9552fc6e-f2b4-4d36-8637-3313fde3ea80@github.com>
Message-ID: <FST2J8IQ3-HRqwpZqe44YLVavuGNcakXyrIKmnieBU4=.2ab8bece-5b62-4c69-8d58-ca7d046f2651@github.com>

On Tue, 5 Nov 2024 08:19:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/jfr/metadata/metadata.xml line 160:
>> 
>>> 158: 
>>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
>> 
>> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
>> 
>> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
>> 
>> (Note: The fact that the event is now written in the JVM doesn't determine the category.)
>
> Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over.

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829462765

From alanb at openjdk.org  Wed Nov  6 17:40:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
Message-ID: <Fjrz2Fg-8FSpm4pEsmswR-JGXhFWQnf6-Dem2_L4PaE=.9552fc6e-f2b4-4d36-8637-3313fde3ea80@github.com>

On Tue, 5 Nov 2024 07:48:40 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> Previously, the event was in the "Java Application" category. I think that was a better fit because it meant it was visualized in the same lane in a thread graph. See here for more information about the category:
> 
> https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Category.html
> 
> (Note: The fact that the event is now written in the JVM doesn't determine the category.)

Thanks for spotting this, it wasn't intended to change the category. I think it's that Event element was copied from another event when adding it to metadata.xml and value from `@Category` wasn't carried over.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828915229

From pchilanomate at openjdk.org  Wed Nov  6 17:40:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <A1ZOz2LmChxaYvY-0jvrbn0Usti4uLWw4PI-2i15_jM=.68c27e60-54f8-43d4-92cb-9efa90bfbe29@github.com>
Message-ID: <O8JULSt20GzECs148szBdunnT7m3Gq1N3MraPGVogm4=.7dcb9fcd-5ee5-4018-bf91-2e095bafe80d@github.com>

On Tue, 5 Nov 2024 07:51:05 GMT, Erik Gahlin <egahlin at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/jfr/metadata/metadata.xml line 160:
> 
>> 158: 
>> 159:   <Event name="VirtualThreadPinned" category="Java Virtual Machine, Runtime" label="Virtual Thread Pinned" thread="true" stackTrace="true">
>> 160:     <Field type="string" name="blockingOperation" label="Blocking operation" />
> 
> The label should be "Blocking Operation" with a capital "O".
> 
> Labels use headline-style capitalization. See here for more information: https://docs.oracle.com/en/java/javase/21/docs/api/jdk.jfr/jdk/jfr/Label.html

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829463128

From yzheng at openjdk.org  Wed Nov  6 17:40:07 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.d1b1de1b-7106-470d-bf6b-d20cf6b1e8aa@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329:

> 327:   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
> 328:                                                                                                                                      \
> 329:   unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \

to make the type assert more precise:

diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
index 20b9609cdbf..f2b8a69c03f 100644
--- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
+++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
@@ -326,7 +326,7 @@
                                                                                                                                      \
   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
                                                                                                                                      \
-  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
+  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
   volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
   volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
   volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
index 86d7277f88b..0492f28e15b 100644
--- a/src/hotspot/share/runtime/vmStructs.cpp
+++ b/src/hotspot/share/runtime/vmStructs.cpp
@@ -786,8 +786,8 @@
                                                                                                                                      \
   volatile_nonstatic_field(ObjectMonitor,      _metadata,                                     uintptr_t)                             \
   unchecked_nonstatic_field(ObjectMonitor,     _object,                                       sizeof(void *)) /* NOTE: no type */    \
-  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
-  unchecked_nonstatic_field(ObjectMonitor,     _stack_locker,                                 BasicLock*)                            \
+  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
+  volatile_nonstatic_field(ObjectMonitor,      _stack_locker,                                 BasicLock*)                            \
   volatile_nonstatic_field(ObjectMonitor,      _next_om,                                      ObjectMonitor*)                        \
   volatile_nonstatic_field(BasicLock,          _metadata,                                     uintptr_t)                             \
   nonstatic_field(ObjectMonitor,               _contentions,                                  int)                                   \

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818818274

From pchilanomate at openjdk.org  Wed Nov  6 17:40:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.d1b1de1b-7106-470d-bf6b-d20cf6b1e8aa@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <LaAKgkfWYhats2V6nav0oBwy6g0ATmF_38A81_LtSYM=.d1b1de1b-7106-470d-bf6b-d20cf6b1e8aa@github.com>
Message-ID: <K5riEGYhTK3b9yrDmiB_hU9eUxZ5SstOxTPMSq0_VOw=.ab39fe6f-a308-4097-a3d8-cd99fe2b08e5@github.com>

On Mon, 28 Oct 2024 10:37:21 GMT, Yudi Zheng <yzheng at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/jvmci/vmStructs_jvmci.cpp line 329:
> 
>> 327:   nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
>> 328:                                                                                                                                      \
>> 329:   unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
> 
> to make the type assert more precise:
> 
> diff --git a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> index 20b9609cdbf..f2b8a69c03f 100644
> --- a/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> +++ b/src/hotspot/share/jvmci/vmStructs_jvmci.cpp
> @@ -326,7 +326,7 @@
>                                                                                                                                       \
>    nonstatic_field(ObjArrayKlass,               _element_klass,                                Klass*)                                \
>                                                                                                                                       \
> -  unchecked_nonstatic_field(ObjectMonitor,     _owner,                                        int64_t)                               \
> +  volatile_nonstatic_field(ObjectMonitor,      _owner,                                        int64_t)                               \
>    volatile_nonstatic_field(ObjectMonitor,      _recursions,                                   intptr_t)                              \
>    volatile_nonstatic_field(ObjectMonitor,      _cxq,                                          ObjectWaiter*)                         \
>    volatile_nonstatic_field(ObjectMonitor,      _EntryList,                                    ObjectWaiter*)                         \
> diff --git a/src/hotspot/share/runtime/vmStructs.cpp b/src/hotspot/share/runtime/vmStructs.cpp
> index 86d7277f88b..0492f28e15b 100644
> --- a/src/hotspot/share/runtime/vmStructs.cpp
> +++ b/src/hotspot/share/runtime/vmStructs.cpp
> @@ -786,8 +786,8 @@
>                                                                                                                                       \
>    volatile_nonstatic_field(ObjectMonitor,      _metadata,                                     uintptr_t)                             \
>    unchecked_nonstatic_field(ObjectMonitor,     _object,                                       sizeof(void *)) /*...

Fixed.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819746890

From pchilanomate at openjdk.org  Wed Nov  6 17:40:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
Message-ID: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>

On Tue, 29 Oct 2024 02:56:30 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082:
> 
>> 1080:     } else {
>> 1081:       assert(vthread != nullptr, "no vthread oop");
>> 1082:       oop oopCont = java_lang_VirtualThread::continuation(vthread);
> 
> Nit: The name `oopCont` does not match the HotSpot naming convention.
>        What about `cont_oop` or even better just `cont` as at the line 2550?

Renamed to cont.

> src/hotspot/share/prims/jvmtiExport.cpp line 1682:
> 
>> 1680: 
>> 1681:   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.
>> 1682:   JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread));
> 
> I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of  the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present.

Right, good find. I missed `get_jvmti_thread_state ` will also create the state if null. How about this fix: https://github.com/pchilano/jdk/commit/baf30d92f79cc084824b207a199672f5b7f9be88
I now also see that JvmtiVirtualThreadEventMark tries to save some state of the JvmtiThreadState for the current thread before the callback, which is not the JvmtiThreadState of the vthread for this case. Don't know if something needs to change there too.

> src/hotspot/share/runtime/continuation.cpp line 88:
> 
>> 86:       if (_target->has_async_exception_condition()) {
>> 87:         _failed = true;
>> 88:       }
> 
> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.

These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer.

> src/hotspot/share/runtime/continuation.cpp line 115:
> 
>> 113:       if (jvmti_present) {
>> 114:         _target->rebind_to_jvmti_thread_state_of(_target->threadObj());
>> 115:         if (JvmtiExport::should_post_vthread_mount()) {
> 
> This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`.
> Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point.

Fixed and added comment.

> src/hotspot/share/runtime/continuation.cpp line 134:
> 
>> 132:   return true;
>> 133: }
>> 134: #endif // INCLUDE_JVMTI
> 
> Could you, please, consider the simplification below?
> 
> 
> #if INCLUDE_JVMTI
> // return true if started vthread unmount
> bool jvmti_unmount_begin(JavaThread* target) {
>   assert(!target->is_in_any_VTMS_transition(), "must be");
> 
>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>   // be installed in start_VTMS_transition() so we need to check it here.
>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>     JvmtiThreadState* state = target->jvmti_thread_state();
>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>       return false;
>     }
>   }
>   // Don't preempt in case there is an async exception installed since
>   // we would incorrectly throw it during the unmount logic in the carrier.
>   if (target->has_async_exception_condition()) {
>     return false;
>   }
>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>   } else {
>     target->set_is_in_VTMS_transition(true);
>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>   }
>   return false;
> }
> 
> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>   if (target->is_in_VTMS_transition()) {
>     // We caught target at the end of a mount transition.
>     return false;
>   }
>   return true;
> }
> #endif // INCLUDE_JVMTI
> ...
> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>     return false;
>   }
>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
> }
> ...
> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>   verify_preempt_preconditions(target, continuation);
> 
>   if (LockingMode == LM_LEGACY) {
>     return freeze_unsupported;
>   }
>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>     return freeze_pinned_native;
>   }
>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>   log_trace(continuations, preempt)("try_preempt: %d", res);
>   return res;
> }
> 
> 
> The following won't be needed:
> 
> target->set_pending_jvmti_unmou...

Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

>  Is this posted after the VirtualThreadMount extension event posted?
>
It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823319745
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823322449
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823324965
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823323891
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830220838
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830225909

From sspitsyn at openjdk.org  Wed Nov  6 17:40:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

src/hotspot/share/prims/jvmtiEnvBase.cpp line 1082:

> 1080:     } else {
> 1081:       assert(vthread != nullptr, "no vthread oop");
> 1082:       oop oopCont = java_lang_VirtualThread::continuation(vthread);

Nit: The name `oopCont` does not match the HotSpot naming convention.
       What about `cont_oop` or even better just `cont` as at the line 2550?

src/hotspot/share/prims/jvmtiExport.cpp line 1682:

> 1680: 
> 1681:   // On preemption JVMTI state rebinding has already happened so get it always directly from the oop.
> 1682:   JvmtiThreadState *state = java_lang_Thread::jvmti_thread_state(JNIHandles::resolve(vthread));

I'm not sure this change is right. The `get_jvmti_thread_state()` has a role to lazily create a `JvmtiThreadState` if it was not created before. With this change the `JvmtiThreadState` creation can be missed if the `unmount` event is the first event encountered for this particular virtual thread. You probably remember that lazy creation of  the `JvmtiThreadState`'s is an important optimization to avoid big performance overhead when a JVMTI agent is present.

src/hotspot/share/prims/jvmtiExport.cpp line 2879:

> 2877:   JvmtiVTMSTransitionDisabler::start_VTMS_transition((jthread)vthread.raw_value(), /* is_mount */ true);
> 2878:   current->rebind_to_jvmti_thread_state_of(current->threadObj());
> 2879: }

This function looks a little bit unusual.
I need to think about the consequences but do not see anything bad so far.
I'll look at the `ObjectMonitor` and `continuation` side updates to get more details on this.

src/hotspot/share/runtime/continuation.cpp line 88:

> 86:       if (_target->has_async_exception_condition()) {
> 87:         _failed = true;
> 88:       }

Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.

src/hotspot/share/runtime/continuation.cpp line 115:

> 113:       if (jvmti_present) {
> 114:         _target->rebind_to_jvmti_thread_state_of(_target->threadObj());
> 115:         if (JvmtiExport::should_post_vthread_mount()) {

This has to be `JvmtiExport::should_post_vthread_unmount()` instead of `JvmtiExport::should_post_vthread_mount()`.
Also, it'd be nice to add a comment explaining why the event posting is postponed to the `unmount` end point.

src/hotspot/share/runtime/continuation.cpp line 134:

> 132:   return true;
> 133: }
> 134: #endif // INCLUDE_JVMTI

Could you, please, consider the simplification below?


#if INCLUDE_JVMTI
// return true if started vthread unmount
bool jvmti_unmount_begin(JavaThread* target) {
  assert(!target->is_in_any_VTMS_transition(), "must be");

  // Don't preempt if there is a pending popframe or earlyret operation. This can
  // be installed in start_VTMS_transition() so we need to check it here.
  if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
    JvmtiThreadState* state = target->jvmti_thread_state();
    if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
      return false;
    }
  }
  // Don't preempt in case there is an async exception installed since
  // we would incorrectly throw it during the unmount logic in the carrier.
  if (target->has_async_exception_condition()) {
    return false;
  }
  if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
    JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
  } else {
    target->set_is_in_VTMS_transition(true);
    // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
  }
  return false;
}

static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
  if (target->is_in_VTMS_transition()) {
    // We caught target at the end of a mount transition.
    return false;
  }
  return true;
}
#endif // INCLUDE_JVMTI
...
static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
  assert(java_lang_VirtualThread::is_instance(vthread), "");
  if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
    return false;
  }
  return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
}
...
int Continuation::try_preempt(JavaThread* target, oop continuation) {
  verify_preempt_preconditions(target, continuation);

  if (LockingMode == LM_LEGACY) {
    return freeze_unsupported;
  }
  if (!is_safe_vthread_to_preempt(target, target->vthread())) {
    return freeze_pinned_native;
  }
  JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
  int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
  log_trace(continuations, preempt)("try_preempt: %d", res);
  return res;
}


The following won't be needed:

target->set_pending_jvmti_unmount_event(true);

jvmtiThreadState.cpp:

+  if (thread->pending_jvmti_unmount_event()) {
+    assert(java_lang_VirtualThread::is_preempted(JNIHandles::resolve(vthread)), "should be marked preempted");
+    JvmtiExport::post_vthread_unmount(vthread);
+    thread->set_pending_jvmti_unmount_event(false);
+  }


As we discussed before there can be the `has_async_exception_condition()` flag set after a VTMS unmount transition has been started. But there is always such a race in VTMS transitions and the flag has to be processed as usual.

src/hotspot/share/runtime/objectMonitor.cpp line 1643:

> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);

We post a JVMTI `MonitorWaited` event here for a virtual thread.
A couple of questions on this:
- Q1: Is this posted after the `VirtualThreadMount` extension event posted?
         Unfortunately, it is not easy to make this conclusion.
- Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
          Does it post the `MonitorWaited` event for this virtual thread as well?
          If not, then it is not clear how posting for virtual thread is avoided.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820012783
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820052049
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1820062505
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822235309
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1822224512
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828376585
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1829199889

From pchilanomate at openjdk.org  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.45cc1977-ff7e-4f27-a30d-1c640049f336@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@github.com>
 <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.45cc1977-ff7e-4f27-a30d-1c640049f336@github.com>
Message-ID: <FJEpZFaGxULmsFhOGyiaLRoIWxL2o9bKBNbo4LWqlrs=.1d735b40-7e9a-41f7-ae49-dc4bf1a0549b@github.com>

On Mon, 4 Nov 2024 09:24:13 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore.
>
> This code in `StackChunkAllocator::initialize` mimics the clearing code in:
> 
> void MemAllocator::mem_clear(HeapWord* mem) const {
>   assert(mem != nullptr, "cannot initialize null object");
>   const size_t hs = oopDesc::header_size();
>   assert(_word_size >= hs, "unexpected object size");
>   oopDesc::set_klass_gap(mem, 0);
>   Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
> }
> 
> 
> but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:
> 
>   if (oopDesc::has_klass_gap()) {
>     oopDesc::set_klass_gap(mem, 0);
>   }
> 
> 
> So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

Thanks for confirming. I added the check here which I think should cover any merge order.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1828614946

From pchilanomate at openjdk.org  Wed Nov  6 17:40:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
Message-ID: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>

On Tue, 5 Nov 2024 23:50:29 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 134:
>> 
>>> 132:   return true;
>>> 133: }
>>> 134: #endif // INCLUDE_JVMTI
>> 
>> Could you, please, consider the simplification below?
>> 
>> 
>> #if INCLUDE_JVMTI
>> // return true if started vthread unmount
>> bool jvmti_unmount_begin(JavaThread* target) {
>>   assert(!target->is_in_any_VTMS_transition(), "must be");
>> 
>>   // Don't preempt if there is a pending popframe or earlyret operation. This can
>>   // be installed in start_VTMS_transition() so we need to check it here.
>>   if (JvmtiExport::can_pop_frame() || JvmtiExport::can_force_early_return()) {
>>     JvmtiThreadState* state = target->jvmti_thread_state();
>>     if (target->has_pending_popframe() || (state != nullptr && state->is_earlyret_pending())) {
>>       return false;
>>     }
>>   }
>>   // Don't preempt in case there is an async exception installed since
>>   // we would incorrectly throw it during the unmount logic in the carrier.
>>   if (target->has_async_exception_condition()) {
>>     return false;
>>   }
>>   if (JvmtiVTMSTransitionDisabler::VTMS_notify_jvmti_events()) {
>>     JvmtiVTMSTransitionDisabler::VTMS_vthread_unmount(target->vthread(), true);
>>   } else {
>>     target->set_is_in_VTMS_transition(true);
>>     // not need to call: java_lang_Thread::set_is_in_VTMS_transition(target->vthread(), true)
>>   }
>>   return false;
>> }
>> 
>> static bool is_vthread_safe_to_preempt_for_jvmti(JavaThread* target) {
>>   if (target->is_in_VTMS_transition()) {
>>     // We caught target at the end of a mount transition.
>>     return false;
>>   }
>>   return true;
>> }
>> #endif // INCLUDE_JVMTI
>> ...
>> static bool is_vthread_safe_to_preempt(JavaThread* target, oop vthread) {
>>   assert(java_lang_VirtualThread::is_instance(vthread), "");
>>   if (java_lang_VirtualThread::state(vthread) != java_lang_VirtualThread::RUNNING) {  // inside transition
>>     return false;
>>   }
>>   return JVMTI_ONLY(is_vthread_safe_to_preempt_for_jvmti(target)) NOT_JVMTI(true);
>> }
>> ...
>> int Continuation::try_preempt(JavaThread* target, oop continuation) {
>>   verify_preempt_preconditions(target, continuation);
>> 
>>   if (LockingMode == LM_LEGACY) {
>>     return freeze_unsupported;
>>   }
>>   if (!is_safe_vthread_to_preempt(target, target->vthread())) {
>>     return freeze_pinned_native;
>>   }
>>   JVMTI_ONLY(if (!jvmti_unmount_begin(target)) return freeze_pinned_native;)
>>   int res = CAST_TO_FN_PTR(FreezeContFnT, freeze_preempt_entry())(target, target->last_Java_sp());
>>   log_trace(con...
>
> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.

Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.

[1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

>> src/hotspot/share/runtime/objectMonitor.cpp line 1643:
>> 
>>> 1641:       // actual callee (see nmethod::preserve_callee_argument_oops()).
>>> 1642:       ThreadOnMonitorWaitedEvent tmwe(current);
>>> 1643:       JvmtiExport::vthread_post_monitor_waited(current, node->_monitor, timed_out);
>> 
>> We post a JVMTI `MonitorWaited` event here for a virtual thread.
>> A couple of questions on this:
>> - Q1: Is this posted after the `VirtualThreadMount` extension event posted?
>>          Unfortunately, it is not easy to make this conclusion.
>> - Q2: The `JvmtiExport::post_monitor_waited()` is called at the line 1801.
>>           Does it post the `MonitorWaited` event for this virtual thread as well?
>>           If not, then it is not clear how posting for virtual thread is avoided.
>
>>  Is this posted after the VirtualThreadMount extension event posted?
>>
> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620

> The JvmtiExport::post_monitor_waited() is called at the line 1801.
> Does it post the MonitorWaited event for this virtual thread as well?
>
That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830222411
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830227475

From coleenp at openjdk.org  Wed Nov  6 17:40:09 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <jso3-7X8XUchoCa0XoIxWSjbiFwv1KxVqeEo3maDlnk=.36601cdc-db88-40c2-accb-a8a63981e11c@github.com>
Message-ID: <1kRcFJhxhwGYGZxCslZJ_TUZ_SLx-io6w_zCFpIlfxw=.60f00ea4-6466-4a9d-b27d-0d657b0a6fb5@github.com>

On Fri, 25 Oct 2024 13:12:11 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1275:
>> 
>>> 1273: 
>>> 1274:   if (caller.is_interpreted_frame()) {
>>> 1275:     _total_align_size += frame::align_wiggle;
>> 
>> Please put a comment here about frame align-wiggle.
>
> I removed this case since it can never happen. The caller has to be compiled, and we assert that at the beginning. This was a leftover from the forceful preemption at a safepoint work. I removed the similar code in recurse_thaw_stub_frame. I added a comment for the compiled and native cases though.

ok that's helpful.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1550:
>> 
>>> 1548:   assert(!cont.is_empty(), "");
>>> 1549:   // This is done for the sake of the enterSpecial frame
>>> 1550:   StackWatermarkSet::after_unwind(thread);
>> 
>> Is there a new place for this StackWatermark code?
>
> I removed it. We have already processed the enterSpecial frame as part of flush_stack_processing(), in fact we processed up to the caller of `Continuation.run()`.

Okay, good!

>> src/hotspot/share/runtime/objectMonitor.hpp line 43:
>> 
>>> 41: // ParkEvent instead.  Beware, however, that the JVMTI code
>>> 42: // knows about ObjectWaiters, so we'll have to reconcile that code.
>>> 43: // See next_waiter(), first_waiter(), etc.
>> 
>> Also a nice cleanup.  Did you reconcile the JVMTI code?
>
> We didn't remove the ObjectWaiter. As for the presence of virtual threads in the list, we skip them in JVMTI get_object_monitor_usage. We already degraded virtual thread support for GetObjectMonitorUsage.

Ok, good that there isn't a jvmti special case here.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860241
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819860643
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819864520

From sspitsyn at openjdk.org  Wed Nov  6 17:40:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
Message-ID: <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>

On Tue, 5 Nov 2024 23:53:04 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Yes, I see your idea to get rid of the pending unmount event code. Before commenting on that, note that we still need to check if the freeze failed to undo the transition, which would call for this RAII object that we currently have. So in line with your suggestion we could call `VTMS_vthread_mount()` in `~JvmtiUnmountBeginMark()` which would also do the right thing too. Something like this: https://github.com/pchilano/jdk/commit/1729b98f554469fedbbce52333eccea9d1c81514
>> We can go this simplified route, but note that we would post unmount/mount events even if we never unmounted or remounted because freeze failed. It's true that that is how it currently works when unmounting from Java fails, so I guess it's not new behavior.
>> Maybe we could go with this simplified code now and work on it later. I think the unmount event should be always posted at the end of the transition, in `JvmtiVTMSTransitionDisabler::VTMS_unmount_end()`. I know that at that point we have already switched identity to the carrier, but does the specs say the event has to be posted in the context of the vthread? If we can do that then we could keep the simplified version and avoid this extra unmount/mount events.
>
> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.
> 
> [1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629

Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.

> but does the specs say the event has to be posted in the context of the vthread?

As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.

> For pop_frame/early_ret checks ...

The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.

> Maybe we could go with this simplified code now and work on it later...

Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
It would be nice to fix a couple of nits though:
 - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
 - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831367766

From pchilanomate at openjdk.org  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.ee840655-7678-4bd7-b236-3686448cfec3@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
 <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.ee840655-7678-4bd7-b236-3686448cfec3@github.com>
Message-ID: <5GigB3kzUJRlduxsGT_kXkmG-Jki2N-gyGkNHNNwXi4=.f139275c-bc20-4f0b-9eef-c979c3e83e12@github.com>

On Thu, 31 Oct 2024 21:11:39 GMT, Fredrik Bredberg <fbredberg at openjdk.org> wrote:

>> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.
>
> Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero.

Yes, I missed to include it in the previous changes. I actually removed the assignment altogether since there is no need to rely on particular values (although it will start at zero by default).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825202651

From fbredberg at openjdk.org  Wed Nov  6 17:40:09 2024
From: fbredberg at openjdk.org (Fredrik Bredberg)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <7t9xWQTF0Mgo-9zOy4M__2HR1-0h-fxddfL8NIh7bZo=.678389b1-d552-4a98-b34c-549c08eb660b@github.com>
 <FfdCysWEzm4GuGUDDVgxDLo7eQe_WaV-O62sVXxWZ20=.aa9be48e-ff04-4fc9-b710-97a07bff94cc@github.com>
Message-ID: <F49eyeqm5FGxKLSvctGdef_KLU0WAiADSzkRzgtTxYg=.ee840655-7678-4bd7-b236-3686448cfec3@github.com>

On Thu, 31 Oct 2024 20:05:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.hpp line 66:
>> 
>>> 64: 
>>> 65:   enum preempt_kind {
>>> 66:     freeze_on_monitorenter = 1,
>> 
>> Is there a reason why the first enumerator doesn't start at zero?
>
> There was one value that meant to be for the regular freeze from java. But it was not used so I removed it.

Fair enough, but I would prefer if you start at zero. Just so people like me don't start scratching their head trying to figure out the cosmic reason for why it doesn't start at zero.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1825168519

From stefank at openjdk.org  Wed Nov  6 17:40:09 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
 <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@github.com>
Message-ID: <LV6Dm-t5T74_nOhEb_IE311wK6cXA5whb8Q24Es_TLI=.45cc1977-ff7e-4f27-a30d-1c640049f336@github.com>

On Wed, 30 Oct 2024 23:14:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.
>
> If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore.

This code in `StackChunkAllocator::initialize` mimics the clearing code in:

void MemAllocator::mem_clear(HeapWord* mem) const {
  assert(mem != nullptr, "cannot initialize null object");
  const size_t hs = oopDesc::header_size();
  assert(_word_size >= hs, "unexpected object size");
  oopDesc::set_klass_gap(mem, 0);
  Copy::fill_to_aligned_words(mem + hs, _word_size - hs);
}


but with a limited amount of clearing at the end of the object, IIRC. So, this looks like a good fix. With JEP 450 we have added an assert to set_klass_gap and changed the code in `mem_clear` to be:

  if (oopDesc::has_klass_gap()) {
    oopDesc::set_klass_gap(mem, 0);
  }


So, unchanged, this code will start to assert when the to projects merge. Maybe it would be nice to make a small/trivial upstream PR to add this code to both `MemAllocator::mem_clear` and `StackChunkAllocator::initialize`?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827424227

From sspitsyn at openjdk.org  Wed Nov  6 17:40:08 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
Message-ID: <FKZnn7aT8nPcZxjsPU2a96efMUA2BkOBGXQhZ4KIlR4=.cc0d07d1-c07e-4641-8c27-cb065a202297@github.com>

On Wed, 30 Oct 2024 20:10:03 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuation.cpp line 88:
>> 
>>> 86:       if (_target->has_async_exception_condition()) {
>>> 87:         _failed = true;
>>> 88:       }
>> 
>> Q: I wonder why the failed conditions are not checked before the `start_VTMS_transition()` call. At least, it'd be nice to add a comment about on this.
>
> These will be rare conditions so I don't think it matters to check them before. But I can move them to some method that we call before and after if you prefer.

Just wanted to understand what needs to be checked after the start_VTMS_transition() call.
You are right, we need to check the `_thread->has_async_exception_condition()` after the call.
The pending `popframe` and  `earlyret` can be checked before as I understand.
I'm not sure there is a real need in double-checking before and after. So, let's keep it as it is for now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824134075

From pchilanomate at openjdk.org  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <quw4M6XfUMacyyBxaRKjeVhu2vql_xk_hiowQ10TD7I=.b6fe5a70-25da-48f4-8e14-66278c0d73a5@github.com>
Message-ID: <qRpbr47FvEPGhLussKp7jw1JxoXEaKJNNgo3kIfQldc=.36e05b24-3543-48c0-bc90-73ec5ebd9039@github.com>

On Wed, 30 Oct 2024 19:02:05 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1411:
>> 
>>> 1409:     // zero out fields (but not the stack)
>>> 1410:     const size_t hs = oopDesc::header_size();
>>> 1411:     oopDesc::set_klass_gap(mem, 0);
>> 
>> Why, bug fix or cleanup?
>
> This might confuse the change for JEP 450 since with CompactObjectHeaders there's no klass_gap, so depending on which change goes first, there will be conditional code here. Good question though, it looks like we only ever want to copy the payload of the object.

If I recall correctly this was a bug where one of the stackChunk fields was allocated in that gap, but since we didn't zeroed it out it would start with some invalid value. I guess the reason why we are not hitting this today is because one of the fields we do initialize (sp/bottom/size) is being allocated there, but with the new fields I added to stackChunk that is not the case anymore.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823580273

From pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
Message-ID: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@github.com>

On Tue, 22 Oct 2024 11:51:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.cpp line 1545:
>> 
>>> 1543:     if (is_vthread_mounted()) {
>>> 1544:       // _lock_id is the thread ID of the mounted virtual thread
>>> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());
>> 
>> What is the interaction here with `switchToCarrierThread` and the window between?
>> 
>>         carrier.setCurrentThread(carrier);
>>         Thread.setCurrentLockId(this.threadId());
>> 
>> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).
>
> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.
> 
> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).

The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811240529

From pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.9a8ae7fc-1822-4afa-a37b-5ed672801f22@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
 <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.9a8ae7fc-1822-4afa-a37b-5ed672801f22@github.com>
Message-ID: <uhUjIm6NwTlveCt80zVVVMHSs2D2aVRo0oGpZfuiKyk=.32dc9e94-a405-4fe5-872e-c9e5762d02ba@github.com>

On Wed, 23 Oct 2024 09:58:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/hotspot/share/runtime/javaThread.hpp line 166:
>> 
>>> 164:   // current _vthread object, except during creation of the primordial and JNI
>>> 165:   // attached thread cases where this field can have a temporary value.
>>> 166:   int64_t _lock_id;
>> 
>> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.
>
> Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them.

I extended the comment to mention this case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814189388

From alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
Message-ID: <_NABF4JJUlSQ9_XfNtXtDGFIkqOPpDcUaoL6wAaJFkY=.70199a12-d9cd-4a85-86e1-2dbdaf474300@github.com>

On Wed, 23 Oct 2024 00:56:34 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/javaThread.cpp line 2002:
> 
>> 2000: #ifdef SUPPORT_MONITOR_COUNT
>> 2001: 
>> 2002: #ifdef LOOM_MONITOR_SUPPORT
> 
> If LOOM_MONITOR_SUPPORT is not true, this would skip this block and assert for LIGHTWEIGHT locking. Do we need this #ifdef ?

LOOM_MONITOR_SUPPORT was only needed when there were ports missing. All 4 are included now so this goes away.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812389702

From alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
Message-ID: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>

On Mon, 21 Oct 2024 15:41:45 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/javaThread.cpp line 1545:
> 
>> 1543:     if (is_vthread_mounted()) {
>> 1544:       // _lock_id is the thread ID of the mounted virtual thread
>> 1545:       st->print_cr("   Carrying virtual thread #" INT64_FORMAT, lock_id());
> 
> What is the interaction here with `switchToCarrierThread` and the window between?
> 
>         carrier.setCurrentThread(carrier);
>         Thread.setCurrentLockId(this.threadId());
> 
> Will we print the carrier threads id as a virtual threads id? (I am guessing that is_vthread_mounted is true when switchToCarrierThread is called).

Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.

In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).

> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:
> 
>> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
>> 61:         MONITOR(3, "Monitor held"),
>> 62:         CRITICAL_SECTION(4, "In critical section");
> 
> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 
> 
> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.

That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue.

Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810578179
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1827316145

From aboldtch at openjdk.org  Wed Nov  6 17:40:09 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
Message-ID: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.9ddfb6f5-32e3-4eda-b111-de05375183ef@github.com>

On Tue, 22 Oct 2024 19:04:16 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2234:
>> 
>>> 2232:     retry_fast_path = true;
>>> 2233:   } else {
>>> 2234:     relativize_chunk_concurrently(chunk);
>> 
>> Is the `relativize_chunk_concurrently` solution to the race only to have a single flag read in `can_thaw_fast` or is there some other subtlety here? 
>> 
>> While not required for the PR, if it is just to optimise the `can_thaw_fast` check, it can probably be made to work with one load and still allow concurrent gcs do fast_thaw when we only get here due to a lockstack.
>
> Yes, it's just to do a single read. I guess you are thinking of combining flags and lockStackSize into a int16_t?

Something along those lines, yes.

>> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 2247:
>> 
>>> 2245:     _thread->lock_stack().move_from_address(tmp_lockstack, lockStackSize);
>>> 2246: 
>>> 2247:     chunk->set_lockstack_size(0);
>> 
>> After some discussion here at the office we think there might be an issue here with simply hiding the oops without clearing them. Below in `recurse_thaw` we `do_barriers`. But it does not touch these lockstack. Missing the SATB store barrier is probably fine from a liveness perspective, because the oops in the lockstack must also be in the frames. But removing the oops without a barrier and clear will probably lead to problems down the line.
>> 
>> Something like the following would probably handle this. Or even fuse the `copy_lockstack` and `clear_lockstack` together into some kind of `transfer_lockstack` which both loads and clears the oops.
>> 
>> 
>> diff --git a/src/hotspot/share/oops/stackChunkOop.cpp b/src/hotspot/share/oops/stackChunkOop.cpp
>> index d3d63533eed..f737bd2db71 100644
>> --- a/src/hotspot/share/oops/stackChunkOop.cpp
>> +++ b/src/hotspot/share/oops/stackChunkOop.cpp
>> @@ -470,6 +470,28 @@ void stackChunkOopDesc::copy_lockstack(oop* dst) {
>>    }
>>  }
>>  
>> +void stackChunkOopDesc::clear_lockstack() {
>> +  const int cnt = lockstack_size();
>> +  const bool requires_gc_barriers = is_gc_mode() || requires_barriers();
>> +  const bool requires_uncompress = has_bitmap() && UseCompressedOops;
>> +  const auto clear_obj = [&](intptr_t* at) {
>> +    if (requires_uncompress) {
>> +      HeapAccess<>::oop_store(reinterpret_cast<narrowOop*>(at), nullptr);
>> +    } else {
>> +      HeapAccess<>::oop_store(reinterpret_cast<oop*>(at), nullptr);
>> +    }
>> +  };
>> +
>> +  if (requires_gc_barriers) {
>> +    intptr_t* lockstack_start = start_address();
>> +    for (int i = 0; i < cnt; i++) {
>> +      clear_obj(&lockstack_start[i]);
>> +    }
>> +  }
>> +  set_lockstack_size(0);
>> +  set_has_lockstack(false);
>> +}
>> +
>>  void stackChunkOopDesc::print_on(bool verbose, outputStream* st) const {
>>    if (*((juint*)this) == badHeapWordVal) {
>>      st->print_cr("BAD WORD");
>> diff --git a/src/hotspot/share/oops/stackChunkOop.hpp b/src/hotspot/share/oops/stackChunkOop.hpp
>> index 28e0576801e..928e94dd695 100644
>> --- a/src/hotspot/share/oops/stackChunkOop.hpp
>> +++ b/src/hotspot/share/oops/stackChunkOop.hpp
>> @@ -167,6 +167,7 @@ class stackChunkOopDesc : public instanceOopDesc {
>>    void fix_thawed_frame(const frame& f, const RegisterMapT* map);
>>  
>>    void copy_lo...
>
> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?

The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before  we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment.  The nicest model would have been to first fix the oops, (mem)copy, then clear them.  But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store.

It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811903902
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811900946

From pchilanomate at openjdk.org  Wed Nov  6 17:40:09 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:09 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.9ddfb6f5-32e3-4eda-b111-de05375183ef@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <HXEXE1mcqRwtcMNJDUElMjDuMCaTjncxfYuThUfL7cQ=.6394dba6-3184-4760-9580-443ebc838013@github.com>
 <SfoZENdVhxSFtX0Z90Ok9PTPj-0Qwj3C_HwT9qaqiQk=.9ddfb6f5-32e3-4eda-b111-de05375183ef@github.com>
Message-ID: <21HfKDagatsu-A7zva9eZ_ndGye37_BRkJ3cyAKQoN0=.4428db89-23a9-4968-878d-c2427ee67622@github.com>

On Wed, 23 Oct 2024 05:33:55 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

>> Ok, I'll change copy_lockstack to both load and clear the oops in the same method. Now, when we call do_barriers on recurse_thaw we don't clear the oops, we just load and store the loaded value again. Is it the case that we just need to do a store, so that already works, or are we missing clearing the oops from the copied frames?
>
> The store is the important part for SATB. The fact that do_barriers (only) does a self store seems is an optimisation. As we need to do the store before  we do the copy (to enable a plane memcpy). And clearing is not something that we rely on / need at the moment.  The nicest model would have been to first fix the oops, (mem)copy, then clear them.  But as mentioned, clearing is currently unnecessary. For the lockstack we do not need this optimisation as we do the copy when we do the load barrier. So we can just clear in our store.
> 
> It is a little interesting that we template parameterise `do_barriers` on the barrier type and instantiate all the load functions, while only ever using the store version. Guess it is a remnant from some earlier model.

I renamed it to transfer_lockstack() and applied the suggested version with the lambda.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813224287

From pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.7fd42d93-19c3-4a49-a668-ae26910077b5@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@github.com>
 <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.7fd42d93-19c3-4a49-a668-ae26910077b5@github.com>
Message-ID: <Q4NNfZ8Vuzy9966oDBrXA3pf4818J5MEL13_l_KLmzQ=.63f24f0a-9304-4bf9-98bf-a70928b4d130@github.com>

On Wed, 23 Oct 2024 09:53:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.
>
> It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended.

Pushed a fix to avoid printing the virtual thread tid if we hit that case.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814186777

From sspitsyn at openjdk.org  Wed Nov  6 17:40:10 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
Message-ID: <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>

On Wed, 6 Nov 2024 09:24:03 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> So at some point I think we need to figure out how to make them go away  ...

Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes.

> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor...

The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though.

> That's the path a virtual thread will take if pinned. 

Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831293112

From alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
Message-ID: <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>

On Wed, 6 Nov 2024 00:01:21 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>>  Is this posted after the VirtualThreadMount extension event posted?
>>>
>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor: https://github.com/openjdk/jdk/blob/124efa0a6b8d05909e10005f47f06357b2a73949/src/hotspot/share/runtime/continuationFreezeThaw.cpp#L1620
>
>> The JvmtiExport::post_monitor_waited() is called at the line 1801.
>> Does it post the MonitorWaited event for this virtual thread as well?
>>
> That's the path a virtual thread will take if pinned. This case is when we were able to unmount the vthread. It is the equivalent, where the vthread finished the wait part (notified, interrupted or timed-out case) and it's going to retry acquiring the monitor.

Just to add that the 2 extension events (VirtualThreadMount and  VirtualThreadUnmount) are not part of any supported/documented interface. They are a left over from the exploration phase of virtual threads when we assumed the debugger agent would need to track the transitions. So at some point I think we need to figure out how to make them go away as they are an attractive nuisance (esp. if the event callback were to upcall and execute Java code).

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1830657204

From dholmes at openjdk.org  Wed Nov  6 17:40:10 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>

On Fri, 25 Oct 2024 18:46:52 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.cpp line 2028:
>> 
>>> 2026:   // First time we run after being preempted on Object.wait().
>>> 2027:   // Check if we were interrupted or the wait timed-out, and in
>>> 2028:   // that case remove ourselves from the _WaitSet queue.
>> 
>> I'm not sure how to interpret this comment block - is this really two sentences because the first is not actually a sentence. Also unclear what "run" and "First time" relate to.
>
> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.

The first sentence is not a sentence. Is it supposed to be saying:

// The first time we run after being preempted on Object.wait()
// we check if we were interrupted or the wait timed-out ...

?

>> src/hotspot/share/runtime/objectMonitor.hpp line 292:
>> 
>>> 290: 
>>> 291:   static int64_t owner_for(JavaThread* thread);
>>> 292:   static int64_t owner_for_oop(oop vthread);
>> 
>> Some comments describing this API would be good. I'm struggling a bit with the "owner for" terminology. I think `owner_from` would be better. And can't these just overload rather than using different names?
>
> I changed them to `owner_from`. I added a comment referring to the return value as tid, and then I used this tid name in some other comments. Maybe this methods should be called `tid_from()`? Alternatively we could use the term owner id instead, and these would be `owner_id_from()`. In theory, this tid term or owner id (or whatever other name) does not need to be related to `j.l.Thread.tid`, it just happens that that's what we are using as the actual value for this id.

I like the idea of using `owner_id_from` but it then suggests to me that `JavaThread::_lock_id` should be something like `JavaThread::_monitor_owner_id`. 

The use of `tid` in comments can be confusing when applied to a `JavaThread` as the "tid" there would normally be a reference of its `osThread()->thread_id()" not it's `threadObj()->thread_id()`. I don't have an obviously better suggestion though.

>> src/hotspot/share/runtime/objectMonitor.hpp line 302:
>> 
>>> 300:   // Simply set _owner field to new_value; current value must match old_value.
>>> 301:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>>> 302:   void      set_owner_from(int64_t old_value, JavaThread* current);
>> 
>> Again some comments describing API would good. The old API had vague names like old_value and new_value because of the different forms the owner value could take. Now it is always a thread-id we can do better I think. The distinction between the raw and non-raw forms is unclear and the latter is not covered by the initial comment.
>
> I added a comment. How about s/old_value/old_tid and s/new_value/new_tid?

old_tid/new_tid works for me.

>> src/hotspot/share/runtime/objectMonitor.hpp line 302:
>> 
>>> 300:   void      set_owner_from(int64_t old_value, JavaThread* current);
>>> 301:   // Set _owner field to tid of current thread; current value must be ANONYMOUS_OWNER.
>>> 302:   void      set_owner_from_BasicLock(JavaThread* current);
>> 
>> Shouldn't tid there be the basicLock?
>
> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.

Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have:

Before: owner = BasicLock* belonging to current
After: owner = JavaThread* of current

with the new version we have:

Before: owner = ANONYMOUS_OWNER
After: owner = tid of current

so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ?

>> src/hotspot/share/runtime/objectMonitor.hpp line 349:
>> 
>>> 347:   ObjectWaiter* first_waiter()                                         { return _WaitSet; }
>>> 348:   ObjectWaiter* next_waiter(ObjectWaiter* o)                           { return o->_next; }
>>> 349:   JavaThread* thread_of_waiter(ObjectWaiter* o)                        { return o->_thread; }
>> 
>> This no longer looks correct if the waiter is a vthread. ??
>
> It is, we still increment _waiters for the vthread case.

Sorry the target of my comment was not clear.  `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread?

>> src/hotspot/share/runtime/synchronizer.cpp line 670:
>> 
>>> 668:   // Top native frames in the stack will not be seen if we attempt
>>> 669:   // preemption, since we start walking from the last Java anchor.
>>> 670:   NoPreemptMark npm(current);
>> 
>> Don't we still pin for JNI monitor usage?
>
> Only when facing contention on this call. But once we have the monitor we don't.

But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ???

>> src/java.base/share/classes/java/lang/VirtualThread.java line 111:
>> 
>>> 109:      *  BLOCKING -> BLOCKED        // blocked on monitor enter
>>> 110:      *   BLOCKED -> UNBLOCKED      // unblocked, may be scheduled to continue
>>> 111:      * UNBLOCKED -> RUNNING        // continue execution after blocked on monitor enter
>> 
>> Presumably this one means it acquired the monitor?
>
> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.

So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:

RUNNING -> BLOCKING -> BLOCKED
BLOCKED -> UNBLOCKING -> RUNNABLE

I'm just trying to get a better sense of what we can infer if we see these "transition" states.

>> src/java.base/share/classes/java/lang/VirtualThread.java line 952:
>> 
>>> 950:         for (;;) {
>>> 951:             boolean unblocked = false;
>>> 952:             synchronized (timedWaitLock()) {
>> 
>> Where is the overall design of the timed-wait protocol and it use of synchronization described?
>
> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.

Thanks for the explanation but that needs to be documented somewhere.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818239594
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811933408
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811935087
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814330162
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818236368
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240013
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814163283
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818228510

From alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
Message-ID: <yWmsM-bQU00t7EQ9jQvi8y7zXE-5q5uVzP1C7_Hso6Q=.9a8ae7fc-1822-4afa-a37b-5ed672801f22@github.com>

On Wed, 23 Oct 2024 09:53:53 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/javaThread.hpp line 166:
> 
>> 164:   // current _vthread object, except during creation of the primordial and JNI
>> 165:   // attached thread cases where this field can have a temporary value.
>> 166:   int64_t _lock_id;
> 
> Following the review I wanted to better understand when `_lock_id` changes. There seems to be another exception to the rule that `_lock_id` is equal to the `tid` of the current `_vthread`. I think they won't be equal when switching temporarily from the virtual to the carrier thread in `VirtualThread::switchToCarrierThread()`.

Right, and we hope this temporary. We had more use of temporary transitions when the feature was initially added in JDK 19, now we mostly down to the nested parking issue. That will go away when we get to replacing the timer code, and we should be able to remove the switchXXX method and avoid the distraction/complexity that goes with them.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812385061

From alanb at openjdk.org  Wed Nov  6 17:40:10 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
 <NrG8HxgGL2KlSdGgiVBjhIpitNwiAg1Iu1o3ynbAEBk=.de8e9fc1-a8e7-4739-9f9e-fe1f6055c34f@github.com>
Message-ID: <givmBO4QCTi5UO6jcgLq7pyMw341taGPjB4UOCWFWuE=.7fd42d93-19c3-4a49-a668-ae26910077b5@github.com>

On Tue, 22 Oct 2024 19:02:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Just to say that we hope to eventually remove these "temporary transitions". This PR brings in a change that we've had in the loom repo to not need this when calling out to the scheduler. The only significant remaining use is timed-park. Once we address that then we will remove the need to switch the thread identity and remove some complexity, esp. for JVMTI and serviceability.
>> 
>> In the mean-time, yes, the JavaThread.lock_id will temporarily switch to the carrier so a thread-dump/safepoint at just the right time looks like it print will be tid of the carrier rather than the mounted virtual thread. So we should fix that. (The original code in main line skipped this case so was lossy when taking a thread dump when hitting this case, David might remember the discussion on that issue).
>
> The problem is that within that window we don't have access to the virtual thread's tid. The current thread has already been changed and we haven't yet set the lock id back. Since this will be a rare corner case maybe we can just print tid unavailable if we hit it. We could also add a boolean to setCurrentThread to indicate we don't want to change the lock_id, but not sure it's worth it.

It should be rare and once we make further progress on timers then the use of temporary transitions will mostly disappear. I think the main thing for the thread dump is not to print a confusing "Carrying virtual thread" with the tid of the carrier. This came up in [pull/19482](https://github.com/openjdk/jdk/pull/19482) when the thread was extended.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812377091

From pchilanomate at openjdk.org  Wed Nov  6 17:40:10 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:10 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
Message-ID: <Z-POFV3noL0adSkJwHIfc-RbkfBedii0V1qRp-WQ6Ws=.78c0709c-fc26-4804-ac21-1adea8356c8f@github.com>

On Mon, 28 Oct 2024 00:35:11 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> This vthread was unmounted on the call to `Object.wait`. Now it is mounted and "running" again, and we need to check which case it is in: notified, interrupted or timed-out. "First time" means it is the first time it's running after the original unmount on `Object.wait`. This is because once we are on the monitor reentry phase, the virtual thread can be potentially unmounted and mounted many times until it successfully acquires the monitor. Not sure how to rewrite the comment to make it clearer.
>
> The first sentence is not a sentence. Is it supposed to be saying:
> 
> // The first time we run after being preempted on Object.wait()
> // we check if we were interrupted or the wait timed-out ...
> 
> ?

Yes, I fixed the wording.

>> So the value stored in _owner has to be ANONYMOUS_OWNER. We cannot store the BasicLock* in there as before since it can clash with some other thread's tid. We store it in the new field _stack_locker instead.
>
> Right I understand we can't store the BasicLock* directly in owner, but the naming of this method has me confused as to what it actually does. With the old version we have:
> 
> Before: owner = BasicLock* belonging to current
> After: owner = JavaThread* of current
> 
> with the new version we have:
> 
> Before: owner = ANONYMOUS_OWNER
> After: owner = tid of current
> 
> so "BasicLock" doesn't mean anything here any more. Isn't this just `set_owner_from_anonymous` ?

I see your point. I removed this method and had the only caller just call set_owner_from_anonymous() and set_stack_locker(nullptr). There was one other caller in ObjectMonitor::complete_exit() but it was actually not needed so I removed it. ObjectMonitor::complete_exit() is only called today on JavaThread exit to possibly unlock monitors acquired through JNI that where not unlocked.

>> It is, we still increment _waiters for the vthread case.
>
> Sorry the target of my comment was not clear.  `thread_of_waiter` looks suspicious - will JVMTI find the vthread from the JavaThread?

If the ObjectWaiter is associated with a vthread(we unmounted in `Object.wait`) we just return null. We'll skip it from JVMTI code.

>> Only when facing contention on this call. But once we have the monitor we don't.
>
> But if this is from JNI then we have at least one native frame on the stack making the JNI call, so we have to be pinned if we were to block on the monitor. ???

We will have the native wrapper frame at the top, but we still need to add some extra check to differentiate this `jni_enter()` case with respect to the case of facing contention on a synchronize native method, where we do allow to unmount (only when coming from the interpreter since the changes to support it where minimal). I used the NoPreemptMark here, but we could filter this case anywhere along the freeze path. Another option could be to check `thread->current_pending_monitor_is_from_java()` in the ObjectMonitor code before trying to preempt.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907304
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697784
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819834478
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819907921

From pchilanomate at openjdk.org  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.58504887-41cd-4fd5-bd60-f780c202bf04@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
 <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.58504887-41cd-4fd5-bd60-f780c202bf04@github.com>
Message-ID: <2y3cYO8ua_6QovrRnR6ndjSA6apEMXRdaNfnn_m2NdE=.0f1297b9-be4e-4fb9-b34d-4db86ad9a7f8@github.com>

On Mon, 28 Oct 2024 13:12:22 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 202:
>> 
>>> 200: 
>>> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
>>> 202:   BasicLock* volatile _stack_locker;
>> 
>> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
>> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?
>
> `ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`.

I remember I thought about doing this but discarded it. I don't think it will reduce complexity since we still need to handle that as a special case. In fact I removed several checks throughout the ObjectMonitor code where we had to check for this case. Now it works like with LM_LIGHTWEIGHT (also a plus), where once the owner gets into ObjectMonitor the owner will be already fixed. So setting and clearing _stack_locker is contained here in ObjectSynchronizer::inflate_impl(). Granted that we could do the same when restricting the ids, but then complexity would be the same. Also even though there are no guarantees about the ids I think it might look weird for somebody looking at a thread dump to only see odd ids.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819748043

From rrich at openjdk.org  Wed Nov  6 17:40:11 2024
From: rrich at openjdk.org (Richard Reingruber)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <1Vvtaabv1ja9uV8GJa4iQYvJIIrGABTNHvOm1OmuKj4=.72d8d29e-57bc-4164-bcdb-8687ee20c030@github.com>
Message-ID: <mhwQn72TSXLud6v7HeTrkIzL2SbixvSV6k3j9_MRDX4=.58504887-41cd-4fd5-bd60-f780c202bf04@github.com>

On Mon, 28 Oct 2024 13:08:37 GMT, Richard Reingruber <rrich at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/objectMonitor.hpp line 202:
> 
>> 200: 
>> 201:   // Used in LM_LEGACY mode to store BasicLock* in case of inflation by contending thread.
>> 202:   BasicLock* volatile _stack_locker;
> 
> IIUC the new field `_stack_locker` is needed because we cannot store the `BasicLock*` anymore in the `_owner` field as it could be interpreted as a thread id by mistake.
> Wouldn't it be an option to have only odd thread ids? Then we could store the `BasicLock*` in the `_owner` field without loosing the information if it is a `BasicLock*` or a thread id. I think this would reduce complexity quite a bit, woudn't it?

`ObjectMonitor::_owner` would never be `ANONYMOUS_OWNER` with `LM_LEGACY`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819034645

From coleenp at openjdk.org  Wed Nov  6 17:40:11 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
Message-ID: <mHKxi5OLZX0oPMqn6app9G5OQcbaOYlcHvumIufOXZQ=.daf4b060-ef66-4034-9e46-def2136b81c5@github.com>

On Wed, 23 Oct 2024 20:42:44 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 299:
>> 
>>> 297:   // Simply set _owner field to new_value; current value must match old_value.
>>> 298:   void      set_owner_from_raw(int64_t old_value, int64_t new_value);
>>> 299:   // Same as above but uses tid of current as new value.
>> 
>> By `tid` here (and elsewhere) you actually mean `thread->threadObj()->thread_id()` - right?
>
> It is `thread->vthread()->thread_id()` but it will match `thread->threadObj()->thread_id()` when there is no virtual thread mounted. But we cache it in thread->_lockd_id so we retrieve it from there. I think we should probably change the name of _lock_id.

but we can't change it there to thread_id because then it would be too confusing.  Since it's used for locking, lock_id seems like a good name.

>> src/hotspot/share/runtime/objectMonitor.hpp line 315:
>> 
>>> 313:   void      set_succesor(oop vthread);
>>> 314:   void      clear_succesor();
>>> 315:   bool      has_succesor();
>> 
>> Sorry but `successor` has two `s` before `or`.
>
> Fixed.

Yes, need to fix successor spelling.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817420867
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811616558

From stefank at openjdk.org  Wed Nov  6 17:40:11 2024
From: stefank at openjdk.org (Stefan Karlsson)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.6c015b39-cd12-4386-af9c-da57e7f17750@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

src/hotspot/share/runtime/objectMonitor.hpp line 325:

> 323:   }
> 324: 
> 325:   bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }

Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814489387

From dholmes at openjdk.org  Wed Nov  6 17:40:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
Message-ID: <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.eb067df9-4805-4fe0-9ecd-85d7c4d3bb22@github.com>

On Fri, 25 Oct 2024 11:59:03 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.hpp line 174:
>> 
>>> 172: 
>>> 173:   int64_t volatile _owner;  // Either tid of owner, NO_OWNER, ANONYMOUS_OWNER or DEFLATER_MARKER.
>>> 174:   volatile uint64_t _previous_owner_tid;  // thread id of the previous owner of the monitor
>> 
>> Looks odd to have the current owner as `int64_t` but we save the previous owner as `uint64_t`. ??
>
> I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id.
> 
> 
> $ grep -r JFR_THREAD_ID
> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread))
> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id())
> runtime/objectMonitor.cpp:    _previous_owner_tid = JFR_THREAD_ID(current);
> runtime/objectMonitor.cpp:    iterator->_notifier_tid = JFR_THREAD_ID(current);
> runtime/vmThread.cpp:  event->set_caller(JFR_THREAD_ID(op->calling_thread()));

Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818234543

From pchilanomate at openjdk.org  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>
Message-ID: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.563f9d5c-56e2-498e-b16e-c2ef76af4b01@github.com>

On Thu, 31 Oct 2024 02:26:42 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:
>> 
>>> 205: }
>>> 206: 
>>> 207: inline bool ObjectMonitor::has_successor() {
>> 
>> Why are _succ accesses atomic here when previously they were not?
>
> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.

> Why are _succ accesses atomic here when previously they were not?
>
They should had always been atomic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794270

From pchilanomate at openjdk.org  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.6c015b39-cd12-4386-af9c-da57e7f17750@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <SaodDmNMx4QKphVMSnJsI2gkE_2xLazHe8uyOA61SkI=.6c015b39-cd12-4386-af9c-da57e7f17750@github.com>
Message-ID: <gLdoEBbkdZ34VkSGPRJ9GVsSE3guDPf_s8Rk0eiv6N8=.3f921a6c-ffb1-4cbf-9a5b-5afbd747b177@github.com>

On Thu, 24 Oct 2024 08:08:56 GMT, Stefan Karlsson <stefank at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/objectMonitor.hpp line 325:
> 
>> 323:   }
>> 324: 
>> 325:   bool has_owner_anonymous() const { return owner_raw() == ANONYMOUS_OWNER; }
> 
> Small, drive-by comment. The rename to `has_owner_anonymous` sounds worse than the previous `is_owner_anonymous` name. I think the code reads better if you change it to `has_anonymous_owner`.

I renamed both `set/has_owner_anonymous` to `set/has_anonymous_owner`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815701746

From pchilanomate at openjdk.org  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
Message-ID: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>

On Fri, 25 Oct 2024 12:00:43 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> src/hotspot/share/runtime/synchronizer.cpp line 1440:
>> 
>>> 1438: }
>>> 1439: 
>>> 1440: ObjectMonitor* ObjectSynchronizer::inflate_impl(JavaThread* inflating_thread, oop object, const InflateCause cause) {
>> 
>> `inflating_thread` doesn't sound right as it is always the current thread that is doing the inflating. The passed in thread may be a different thread trying to acquire the monitor ... perhaps `contending_thread`?
>
> If it's always the current thread, then it should be called 'current' imo.

I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389380

From pchilanomate at openjdk.org  Wed Nov  6 17:40:11 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.563f9d5c-56e2-498e-b16e-c2ef76af4b01@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>
 <n1Tts70_jTyatMdkbxNiZk9ZKtWe-5XVObdstcOLvJw=.563f9d5c-56e2-498e-b16e-c2ef76af4b01@github.com>
Message-ID: <jY7WaK5NmmdDNXECTw7ByGpZ-QFceabiNhX5fucWL_E=.ef9c3659-88c3-4e87-93b0-15361ba0a96c@github.com>

On Thu, 31 Oct 2024 16:34:41 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.
>
>> Why are _succ accesses atomic here when previously they were not?
>>
> They should had always been atomic.

> But I agree it seems odd when direct accesses to _succ in the main cpp file are not atomic.
>
There was only one remaining direct access in debugging function `print_debug_style_on` which I fixed now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1824794795

From dholmes at openjdk.org  Wed Nov  6 17:40:11 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <6tuWDfkvasNaSP449aPvzBoQYN6e6VaxaLXs3VWdNF8=.67f63f45-ca6f-4e4c-8989-00e3740a861a@github.com>

On Thu, 31 Oct 2024 01:32:19 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/share/runtime/objectMonitor.inline.hpp line 207:
> 
>> 205: }
>> 206: 
>> 207: inline bool ObjectMonitor::has_successor() {
> 
> Why are _succ accesses atomic here when previously they were not?

General convention is that racily accessed variables should be accessed via Atomic::load/store to make it clear(er) they are racy accesses. But I agree it seems odd when direct accesses to `_succ` in the main cpp file are not atomic.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1823698001

From coleenp at openjdk.org  Wed Nov  6 17:40:12 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
Message-ID: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>

On Fri, 25 Oct 2024 21:29:05 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.
>
>> If it's always the current thread, then it should be called 'current' imo.
>>
> The inflating thread is always the current one but it's not always equal to `inflating_thread`.

I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817423564

From pchilanomate at openjdk.org  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
Message-ID: <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>

On Fri, 25 Oct 2024 21:28:22 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If it's always the current thread, then it should be called 'current' imo.
>
> I see that in lightweightSynchronizer.cpp we already use the name `locking_thread` (although `LightweightSynchronizer::inflate_into_object_header` still uses `inflating_thread`). So how about using `locking_thread` instead? I can fix `LightweightSynchronizer::inflate_into_object_header` too.

> If it's always the current thread, then it should be called 'current' imo.
>
The inflating thread is always the current one but it's not always equal to `inflating_thread`.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1817389882

From pchilanomate at openjdk.org  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.a83114d0-b859-48c8-bc95-a5662963aa32@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com>
 <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.a83114d0-b859-48c8-bc95-a5662963aa32@github.com>
Message-ID: <1MAelVhUXDdz7GI63iJPUEg6QeOQ4DO4S0B0_eC3CRQ=.ec5ff767-4b75-40ab-b40c-1579907b978a@github.com>

On Mon, 28 Oct 2024 11:59:57 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.
>
> ok, I now I see what the discussion is.  Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this.

Changed to locking_thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1819461999

From dholmes at openjdk.org  Wed Nov  6 17:40:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
Message-ID: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com>

On Fri, 25 Oct 2024 22:29:56 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>>> If it's always the current thread, then it should be called 'current' imo.
>>>
>> The inflating thread is always the current one but it's not always equal to `inflating_thread`.
>
> I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.

The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818240440

From coleenp at openjdk.org  Wed Nov  6 17:40:12 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <LtQYg4YVtNT2bd2PbbuAY91msy66JQN12vt1X6ruQhI=.069081f9-f4ce-41de-aa9a-94e99cb4013f@github.com>
 <AuyHqHsMW6tCqrFKWXjCmhsY4Jbsnu6PpqrPUuyOG-k=.0000dd7c-2cc6-4098-9e10-fc97ba6129fd@github.com>
 <OLVo4qK4vV1pXVU_5l6UFehPuGVWIuZNqpkdmgLUDfo=.f81839e8-7b63-4dfd-8543-7bad8e4495b6@github.com>
 <1o1dQuZURkIjZi-aUVP_jLJwoL6P40ZSGPME4C9KzpU=.96865d82-6267-4065-a3d5-6eb56d958a00@github.com>
Message-ID: <r-3PFg-niReTCfkxeLXn8URDG_cPb4fCROJ0TxtZobg=.a83114d0-b859-48c8-bc95-a5662963aa32@github.com>

On Mon, 28 Oct 2024 00:38:39 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I thought locking_thread there may not be the current thread for enter_for() in deopt.  It's the thread that should hold the lock but not the current thread.  But it might be different now.
>
> The thread passed in need not be the current thread, and IIUC is the thread that should become the owner of the newly inflated monitor (either current thread or a suspended thread). The actual inflation is always done by the current thread.

ok, I now I see what the discussion is.  Yes I think locking_thread is better than inflating thread in this. Unless it's a bigger cleanup and we can do it post-integrating this.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818935916

From dholmes at openjdk.org  Wed Nov  6 17:40:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
Message-ID: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>

On Tue, 22 Oct 2024 12:31:24 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Okay but ....
>> 1. We have the current virtual thread
>> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
>> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?
>
> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.

If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.

Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811877637

From dholmes at openjdk.org  Wed Nov  6 17:40:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
Message-ID: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>

On Tue, 22 Oct 2024 11:52:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/VirtualThread.java line 115:
>> 
>>> 113:      *   RUNNING -> WAITING        // transitional state during wait on monitor
>>> 114:      *   WAITING -> WAITED         // waiting on monitor
>>> 115:      *    WAITED -> BLOCKED        // notified, waiting to be unblocked by monitor owner
>> 
>> Waiting to re-enter the monitor?
>
> yes

Okay so should it say that?

>> src/java.base/share/classes/java/lang/VirtualThread.java line 178:
>> 
>>> 176:     // timed-wait support
>>> 177:     private long waitTimeout;
>>> 178:     private byte timedWaitNonce;
>> 
>> Strange name - what does this mean?
>
> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.

Suggestion: `timedWaitCounter` ?

>> src/java.base/share/classes/java/lang/VirtualThread.java line 530:
>> 
>>> 528:                 && carrier == Thread.currentCarrierThread();
>>> 529:         carrier.setCurrentThread(carrier);
>>> 530:         Thread.setCurrentLockId(this.threadId()); // keep lock ID of virtual thread
>> 
>> I'm struggling to understand the different threads in play when this is called and what the method actual does to which threads. ??
>
> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).
> 
> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.

Okay but ....
1. We have the current virtual thread
2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811937674
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1811938604
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810615473

From dholmes at openjdk.org  Wed Nov  6 17:40:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
 <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
Message-ID: <uhNEFqOmOPAUXR5vCaSiMeOvh23OjcpBiUgxjZ5PByU=.c3df6add-a985-422b-bb57-e236e8fb1f40@github.com>

On Thu, 24 Oct 2024 08:26:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
>> 
>> RUNNING -> BLOCKING -> BLOCKED
>> BLOCKED -> UNBLOCKING -> RUNNABLE
>> 
>> I'm just trying to get a better sense of what we can infer if we see these "transition" states.
>
> We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it.

Okay but I'm finding it hard to see these names and easily interpret what some of them mean. I think there is a difference between UNBLOCKED and UNPARKED, because as an API once you are unparked that is it - operation over. But for UNBLOCKED you are still in a transitional state and it is not yet determined what you will actually end up doing i.e. get the monitor or block again.

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

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815761305

From alanb at openjdk.org  Wed Nov  6 17:40:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
Message-ID: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>

On Thu, 24 Oct 2024 02:47:14 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Not really, it is the state we set when the virtual thread is mounted and runs again. In this case it will just run to re-contest for the monitor.
>
> So really UNBLOCKED is UNBLOCKING and mirrors BLOCKING , so we have:
> 
> RUNNING -> BLOCKING -> BLOCKED
> BLOCKED -> UNBLOCKING -> RUNNABLE
> 
> I'm just trying to get a better sense of what we can infer if we see these "transition" states.

We named it UNBLOCKED when unblocked, like UNPARKED when unparked, as that accurately describes the state at this point. It's not mounted but may be scheduled to continue. In the user facing APIs this is mapped to "RUNNABLE", it's the equivalent of OS thread queued to the OS scheduler. So I think the name is good and would prefer not change it.

>> When we unmount on a timed-wait call we schedule a wakeup task at the end of `afterYield`. There are two mechanisms that avoid the scheduled task to run and wake up the virtual thread on a future timed-wait call, since in this call the virtual thread could have been already notified before the scheduled task runs. The first one is to cancel the scheduled task once we return from the wait call (see `Object.wait(long timeoutMillis)`). Since the task could have been already started though, we also use `timedWaitSeqNo`, which the wake up task checks here to make sure it is not an old one. Since we synchronize on `timedWaitLock` to increment `timedWaitSeqNo` and change state to `TIMED_WAIT` before scheduling the wake up task in `afterYield`, here either a wrong `timedWaitSeqNo` or a state different than `TIMED_WAIT` means there is nothing to do. The only exception is checking for `SUSPENDED` state, in which case we just loop to retry.
>
> Thanks for the explanation but that needs to be documented somewhere.

The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814517084
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1818670426

From alanb at openjdk.org  Wed Nov  6 17:40:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
Message-ID: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>

On Wed, 23 Oct 2024 06:11:26 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Sequence number, nouce, anything will work here as it's just to deal with the scenario where the timeout task for a previous wait may run concurrently with a subsequent wait.
>
> Suggestion: `timedWaitCounter` ?

We could rename it to timedWaitSeqNo if needed.

>> A virtual thread is mounted but doing a timed-park that requires temporarily switching to the identity of the carrier (identity = Therad.currentThread) when queuing the timer task. As mentioned in a reply to Axel, we are close to the point of removing this (nothing to do with object monitors of course, we've had the complexity with temporary transitions since JDK 19).
>> 
>> More context here is that there isn't support yet for a carrier to own a monitor before a virtual thread is mounted, and same thing during these temporary transitions. If support for custom schedulers is exposed then that issue will need to be addressed as you don't want some entries on the lock stack owned by the carrier and the others by the mounted virtual thread. Patricio has mentioned inflating any held monitors before mount. There are a couple of efforts in this area going on now, all would need that issue fixed before anything is exposed.
>
> Okay but ....
> 1. We have the current virtual thread
> 2. We have the current carrier for that virtual thread (which is iotself a java.alng.Thread object
> 3. We have Thread.setCurrentLockId which ... ? which thread does it update? And what does "current" refer to in the name?

Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1812537648
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1810636960

From pchilanomate at openjdk.org  Wed Nov  6 17:40:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
Message-ID: <v_7OhzC9sq5rI3jGQjn-W8sPfuqFRlaFWPwvxylxDYM=.e6f250ff-e193-4bca-b23b-ce79633376d2@github.com>

On Wed, 23 Oct 2024 11:32:54 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Suggestion: `timedWaitCounter` ?
>
> We could rename it to timedWaitSeqNo if needed.

Ok, renamed to timedWaitSeqNo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813240667

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
Message-ID: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>

On Wed, 23 Oct 2024 20:34:48 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.
>> 
>> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>
> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.
> 
> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491

> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>
Yes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813507846

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
Message-ID: <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>

On Wed, 23 Oct 2024 05:18:10 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Thread identity switches to the carrier so Thread.currentThread() is the carrier thread and JavaThread._lock_id is the thread identifier of the carrier.  setCurrentLockId changes JavaThread._lock_id back to the virtual thread's identifier.
>
> If the virtual thread is un-mounting from the carrier, why do we need to set the "lock id" back to the virtual thread's id? Sorry I'm finding this quite confusing.
> 
> Also `JavaThread::_lock_id` in the VM means "the java.lang.Thread thread-id to use for locking" - correct?

Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.

[1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1813503450

From dholmes at openjdk.org  Wed Nov  6 17:40:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
Message-ID: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>

On Wed, 23 Oct 2024 20:36:23 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Sorry, I should add context on why this is needed. The problem is that inside this temporal transition we could try to acquire some monitor. If the monitor is not inflated we will try to use the LockStack, but the LockStack might be full from monitors the virtual thread acquired before entering this transition. Since the LockStack is full we will try to make room by inflating one or more of the monitors in it [1]. But when inflating the monitors we would be using the j.l.Thread.tid of the carrier (set into _lock_id when switching the identity), which is wrong. We need to use the j.l.Thread.tid of the virtual thread, so we need to change _lock_id back.
>> We are not really unmounting the virtual thread, the only thing that we want is to set the identity to the carrier thread so that we don't end up in this nested calls to parkNanos.
>> 
>> [1] https://github.com/openjdk/jdk/blob/afb62f73499c09f4a7bde6f522fcd3ef1278e526/src/hotspot/share/runtime/lightweightSynchronizer.cpp#L491
>
>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>>
> Yes.

I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1814167842

From dholmes at openjdk.org  Wed Nov  6 17:40:13 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@github.com>
Message-ID: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.fb618b04-c12f-44de-8297-743adca17504@github.com>

On Thu, 24 Oct 2024 21:08:47 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.
>
> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.

Sorry to belabour this but why are we temporarily changing the  thread identity? What is the bigger operation that in underway here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815762233

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
Message-ID: <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@github.com>

On Thu, 24 Oct 2024 02:55:18 GMT, David Holmes <dholmes at openjdk.org> wrote:

>>> Also JavaThread::_lock_id in the VM means "the java.lang.Thread thread-id to use for locking" - correct?
>>>
>> Yes.
>
> I guess I don't understand where this piece code fits in the overall transition of the virtual thread to being parked. I would have expected the LockStack to already have been moved by the time we switch identities to the carrier thread.

We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1815697084

From alanb at openjdk.org  Wed Nov  6 17:40:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIYrMRbyEEY=.fb618b04-c12f-44de-8297-743adca17504@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <05dUigiY1OQWtk8p1xL8GlFClg4gTmP7rluFyh0f6Es=.722b3692-cd3c-4ca0-affb-8c695b6849ae@github.com>
 <7BYPwAm8OvYFldeIFsYf5m9MbocP5Wue35H-Ix_erw0=.c6161aa9-4831-4498-aa68-e9b6ffa7ca75@github.com>
 <NsZBsuJYcYBZPzwUWhoQHWknPWT6wC2znk9XQrEi6Ew=.2e89e89e-7a7d-40a4-877c-7a99c536ebc9@github.com>
 <tynrUNA6-7Kh5Ej2yemZrCORYLLKIPufE-rGr3atzPE=.f0884abc-80be-4316-91e1-5379f7174cde@github.com>
 <kBYPH4u9_6kmqDW0d1h-XqLnV1FnNHJl9tF3Mjk4aMA=.4b64307d-c503-4556-9bf3-4283e1d38486@github.com>
 <D9JbbwYOVTcy4IzKIiqTQFc87p2fDASAmnhv4FW86XA=.978feba6-8c3f-4944-86ca-3413e07e5569@github.com>
 <6IyizKWQ3ev2YfWJiyVhEsENxlHJ3fsY-cPGXNCyI2g=.9c35109b-7e23-4525-8ca7-7fc3d272844b@github.com>
 <U287JlGB0fNByIas2R7lBvLNrOSLyfF6lzuZr6vy5zA=.afbdecbd-4be0-4ac9-afa5-2a3fbdc8f5a8@github.com>
 <pL_mxHTMFZLyfV8uFSJHcahiCdGm5ZnCRIY
 rMRbyEEY=.fb618b04-c12f-44de-8297-743adca17504@github.com>
Message-ID: <bIj9x7QeQeCoCgHy7PkpwOy0SLdF2lRnZ8oKN7yjILk=.b468afba-a5cc-467d-9cbd-a8ed5aade243@github.com>

On Thu, 24 Oct 2024 22:13:27 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> We don't unmount the virtual thread here, we just temporarily change the thread identity. You could think of this method as switchIdentityToCarrierThread if that helps.
>
> Sorry to belabour this but why are we temporarily changing the  thread identity? What is the bigger operation that in underway here?

We've had these temporary transitions from day 1. The changes in this PR remove one usage, they don't add any new usages. The intention is to make this nuisance go away. The last usage requires changes to the timer support, working on it. For now, it's easiest to think of it as a "java on java" issue where critical code is in Java rather than the VM. The timer issue arises when a virtual thread does a timed park needs to schedule and cancel a timer. This currently requires executing Java code that may contend on a timer or trigger a timer thread to start. This has implications for thread state, the park blocker, and the parking permit. Adding support for nested parking gets very messy, adds overhead, and is confusing for serviceability observers.  The exiting behavior is to just temporarily switch the thread identity (as in Thread::currentThread) so it executes in the context of the carrier rather than the virtual thread. As I said, we are working to make this go away, it would have 
 been nice to have removed in advance of the changes here.

Update: The temporary transitions are now removed in the fibers branch (loom repo). This removes the switchToCarrierThread and switchToVirtualThread methods, and removes the need to introduce setCurrentLockId that is hard to explain in the discussions here. Need to decide if we should include it in this PR or try to do it before or after.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1816425590

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
Message-ID: <cbf7sd9t-JRpuKIcvoZXbga78_Uwu_mqHYxoto2prGs=.6bf41cae-c413-490c-8ae5-7a676986524c@github.com>

On Thu, 31 Oct 2024 20:28:06 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/security/ssl/X509TrustManagerImpl.java line 57:
>> 
>>> 55:     static {
>>> 56:         try {
>>> 57:             MethodHandles.lookup().ensureInitialized(AnchorCertificates.class);
>> 
>> Why is this needed?  A comment would help.
>
> That's probably a good idea.  It?s caused by pinning due to the sun.security.util.AnchorCertificates?s class initializer, some of the http client tests are running into this. Once monitors are out of the way then class initializers, both executing, and waiting for, will be a priority.

Added comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826153929

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.54ad6bb0-5193-4f13-a1a0-1c019bd130d2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.54ad6bb0-5193-4f13-a1a0-1c019bd130d2@github.com>
Message-ID: <wr2gUUNCp_fXQM_ggvjcOSk72PpT3vWBYDmeoL1Bsog=.0dd96592-8976-4522-899a-9bb3dc7d9231@github.com>

On Mon, 21 Oct 2024 08:01:09 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323:
> 
>> 321:             var started2 = new AtomicBoolean();
>> 322: 
>> 323:             Thread vthread1 =  Thread.ofVirtual().unstarted(() -> {
> 
> Suggestion:
> 
>             Thread vthread1 = Thread.ofVirtual().unstarted(() -> {

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1809073267

From aturbanov at openjdk.org  Wed Nov  6 17:40:13 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <uy9lrVCVvtkZGTDILOIF2ldcRZmgw3Ax4TM991_GA-Q=.54ad6bb0-5193-4f13-a1a0-1c019bd130d2@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

test/jdk/java/lang/Thread/virtual/JfrEvents.java line 323:

> 321:             var started2 = new AtomicBoolean();
> 322: 
> 323:             Thread vthread1 =  Thread.ofVirtual().unstarted(() -> {

Suggestion:

            Thread vthread1 = Thread.ofVirtual().unstarted(() -> {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1808287799

From pchilanomate at openjdk.org  Wed Nov  6 17:40:13 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:40:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <8si6-v5lNlqeJzOwpLSqrl7N4wbs-udt2BFPzUVMY90=.150eea1c-8608-4497-851e-d8506b2b305f@github.com>
 <HvpCLMiAPYs6SH0LXa6YDcyLcfUeLDseSBHOgX9DJUs=.590f0163-ca3c-4eb8-918d-b173435ffded@github.com>
 <77_fMY08zucHFP6Zo0sbJabtL1hdYdRVTsp_vkcSSow=.c460c377-e8a9-4fd3-b8f4-5063ddd5aedd@github.com>
Message-ID: <eQsNuW1dYTC5Jth_rKACj76kGFv3ShNY0hP525XOIM8=.c45f0843-0844-4eaf-80f1-5715dd6520f6@github.com>

On Mon, 28 Oct 2024 09:19:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Thanks for the explanation but that needs to be documented somewhere.
>
> The comment in afterYield has been expanded in the loom repo, we may be able to bring that update in.

Brought the comment from the loom repo.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1826160691

From pchilanomate at openjdk.org  Wed Nov  6 17:53:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:53:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <onW4676sjxkma718RYvcVqQkIUUXJFJiu1RE2PPwlVw=.386030d1-be51-472d-b834-66b748be1545@github.com>
Message-ID: <4EGJTS9LsdYLK3ecIsExhUZaQupaES8wASP95dS88Cc=.3646b0fe-6e6c-4884-b37f-08360f8e144b@github.com>

On Mon, 4 Nov 2024 07:59:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/vm/Continuation.java line 62:
>> 
>>> 60:         NATIVE(2, "Native frame or <clinit> on stack"),
>>> 61:         MONITOR(3, "Monitor held"),
>>> 62:         CRITICAL_SECTION(4, "In critical section");
>> 
>> Is there a reason that the `reasonCode` values does not match the `freeze_result` reason values used in `pinnedReason(int reason)` to create one of these? 
>> 
>> I cannot see that it is used either. Only seem to be read for JFR VirtualThreadPinned Event which only uses the string.
>
> That's a good question as they should match. Not noticed as it's not currently used. As it happens, this has been reverted in the loom repo as part of improving this code and fixing another issue.
> 
> Related is the freeze_result enum has new members, e.g. freeze_unsupported for LM_LEGACY, that don't have a mapping to a Pinned, need to check if we could trip over that.

These have been updated with the latest JFR changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831465256

From pchilanomate at openjdk.org  Wed Nov  6 17:52:59 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 17:52:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
Message-ID: <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>

On Wed, 6 Nov 2024 06:36:58 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
> 
> ```
> // the sp of the oldest known interpreted/call_stub frame inside the
> // continuation that we know about
> ```
>
Updated comment.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2460396452

From alexey.semenyuk at oracle.com  Wed Nov  6 18:04:33 2024
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Wed, 6 Nov 2024 13:04:33 -0500
Subject: [jpackage] Changes to icon handling between Java 17 and Java 21
 on Windows
In-Reply-To: <CAAoP7T6SPwhxKUxsFG91Of5hWdBugTw9uJzev1DoM-s1MbKSRA@mail.gmail.com>
References: <CAAoP7T6SPwhxKUxsFG91Of5hWdBugTw9uJzev1DoM-s1MbKSRA@mail.gmail.com>
Message-ID: <d28f07fb-f642-487b-beae-4f2cfbbf711b@oracle.com>

Hi Daniel,

On Windows, the jpackage embeds icons in app launcher executables and 
there is no reason to keep these .ico files in the app image. In [1], it 
was reasonably requested not to include app launcher icons in the app 
image on Windows, and that was fulfilled.

[1] https://bugs.openjdk.org/browse/JDK-8281682

- Alexey


On 11/6/2024 4:19 AM, Daniel Peintner wrote:
> Hello,
>
> I am not sure if this is the right place to ask, but I hope so.
> If not please let me know where I can report this kind of problem.
>
> Recently we changed from JDK 17 to JDK 21 and something seems to have 
> changed when running jpackage with --icon option.
>
> Produced structure on Windows for
>
> # Java 17
> /app
> /runtime
> foo.exe
> foo.ico
>
> while for
>
> # Java 21 (v 21.0.5)
> /app
> /runtime
> foo.exe
>
> As you can see the foo.ico is missing.
> Note: the foo.exe still shows the right icon when looking at it in 
> FileExplorer.
>
> Anyhow, on some devices the missing ico file is causing issues.
> There is no icon on the program list nor in the taskbar (see attached 
> images).
>
> Note: On some windows installations it works without issues.
>
> Is this a known problem? I tried to browse through 
> https://bugs.openjdk.org without finding such a bug report.
>
> Thanks for any input/advice.
>
> -- Daniel
>
>


From tprinzing at openjdk.org  Wed Nov  6 18:35:32 2024
From: tprinzing at openjdk.org (Tim Prinzing)
Date: Wed, 6 Nov 2024 18:35:32 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <ZFOO5n1jTQ28-cpz5qoTZOEnnXjKM9otE4KMeiX2S50=.9bd63cf6-5ff0-487f-94b9-19e5f782428f@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
 <ZFOO5n1jTQ28-cpz5qoTZOEnnXjKM9otE4KMeiX2S50=.9bd63cf6-5ff0-487f-94b9-19e5f782428f@github.com>
Message-ID: <yVdfC0Ppn2f0s6M3teSgz3BLizzZgQSCmmN5_sPkQkc=.ba8b05e1-2f49-483f-85e0-0831d1b97d8f@github.com>

On Wed, 6 Nov 2024 07:31:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   suggested changes
>
> src/jdk.jfr/share/classes/jdk/jfr/internal/JDKEvents.java line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2016, 2023, Oracle and/or its affiliates. All rights reserved.
> 
> I assume you didn't mean to change that.

Not sure how that happened, but I'll fix it

> test/jdk/jdk/jfr/event/io/TestSocketChannelEvents.java line 106:
> 
>> 104: 
>> 105:                 try (SocketChannel sc = SocketChannel.open(ssc.getLocalAddress())) {
>> 106:                     addExpectedEvent(IOEvent.createSocketConnectEvent(sc.socket()));
> 
> This is SocketChannel in blocking mode where the connect succeeds. There is also the non-blocking and where connect fails. In addition the connection can established with the socket adaptor. So 6 possible cases for SocketChannel if the test is expanded.

yes, testing still to be done

> test/jdk/jdk/jfr/event/io/TestSocketEvents.java line 108:
> 
>> 106:                 try (Socket s = new Socket()) {
>> 107:                     s.connect(ss.getLocalSocketAddress());
>> 108:                     addExpectedEvent(IOEvent.createSocketConnectEvent(s));
> 
> This is Socket.connect success case, I assume we'll need a test for fail case too.

yes

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831527507
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831529879
PR Review Comment: https://git.openjdk.org/jdk/pull/21528#discussion_r1831529362

From viktor.klang at oracle.com  Wed Nov  6 19:08:00 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 6 Nov 2024 19:08:00 +0000
Subject: Should the documentation state peekFirst() as equivalent to
 Stack's peek()?
In-Reply-To: <CACQZjSNcWi5KH9x6wpZNkWkN+U+gWTvtWwgmhzy2J6dR-yYMhg@mail.gmail.com>
References: <CACQZjSOmYz0mBpi1PYbPVuS5HpSrvcK7CyDyB4iHdmF_aM46uw@mail.gmail.com>
 <CH3PR10MB76776DB1E0785202759C910BA2AB2@CH3PR10MB7677.namprd10.prod.outlook.com>
 <CACQZjSNcWi5KH9x6wpZNkWkN+U+gWTvtWwgmhzy2J6dR-yYMhg@mail.gmail.com>
Message-ID: <MW4PR10MB5774AB1CD4A6C091BEACD182FF532@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi,

The change was merged after 23 had already been branched off, so it is destined for 24 as can be seen in the tag associated with the commit (attached).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Turkhan Badalov <badalov.turxan at gmail.com>
Sent: Wednesday, 6 November 2024 16:22
To: core-libs-dev at openjdk.org <core-libs-dev at openjdk.org>
Subject: Re: Should the documentation state peekFirst() as equivalent to Stack's peek()?

Hi!

After this commit https://github.com/openjdk/jdk/commit/1846a65e32624f6da691c1072f44fcb762b43233#diff-f7198d7dbc99fe4e161d39db820508c743fe03ecf004085625ab241255c98e76L164, I was expecting the docs to get updated with the release of Java 23.

However, the typo is still there: https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/Deque.html

Wondering when is the change supposed to take effect or does it mean the fix is not complete?

Regards,
Turkhan


On Thu, Jul 25, 2024 at 3:57?PM Chen Liang <chen.l.liang at oracle.com<mailto:chen.l.liang at oracle.com>> wrote:
Hi Turkhan, this mail belongs to core-libs-dev list. I have forwarded your mail to the right list.

Indeed, we should claim that peek() is equivalent to peekFirst(); the information in stack section should be a typo, as peek() being the same as peekFirst() is claimed by the deque section and the peek() specification.

I have created a ticket on the Java Bug System to track this issue: [JDK-8337205] Typo in Stack vs Deque Method table in Deque specification - Java Bug System (openjdk.org)<https://bugs.openjdk.org/browse/JDK-8337205>

Feel free to open a pull request to jdk to fix this bug.

Best, Chen Liang
________________________________
From: jdk-dev <jdk-dev-retn at openjdk.org<mailto:jdk-dev-retn at openjdk.org>> on behalf of Turkhan Badalov <badalov.turxan at gmail.com<mailto:badalov.turxan at gmail.com>>
Sent: Thursday, July 25, 2024 4:58 AM
To: jdk-dev at openjdk.org<mailto:jdk-dev at openjdk.org> <jdk-dev at openjdk.org<mailto:jdk-dev at openjdk.org>>
Subject: Should the documentation state peekFirst() as equivalent to Stack's peek()?

Here is the table "Comparison of Stack and Deque methods" that lists equivalent Deque methods compared to Stack methods: https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html

At the moment, getFirst() is said to be equivalent to peek(). Since peek() doesn't throw an exception when the queue/stack is empty, peekFirst() could be a better equivalent because getFirst() throws.

In fact, the documentation of the peek() method itself says that this method is equivalent to peekFirst(): https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/util/Deque.html#peek().

If this should be posted somewhere else, please let me know. I am still new to using mailing lists. Cheers.


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241106/bf2d8968/attachment-0001.htm>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Screenshot 2024-11-06 at 20.07.21.png
Type: image/png
Size: 64213 bytes
Desc: Screenshot 2024-11-06 at 20.07.21.png
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241106/bf2d8968/Screenshot2024-11-06at20.07.21-0001.png>

From pchilanomate at openjdk.org  Wed Nov  6 19:40:47 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 19:40:47 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.eb067df9-4805-4fe0-9ecd-85d7c4d3bb22@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <XGtbH9JB-6KZzjM4l5HJ_HrRYJ9G8nMn7cKyMTNK2VE=.c4027615-c524-4b71-bfb5-a0fce4a384ad@github.com>
 <JixDDjqaQEJFg7QMZ0XYKsP2qU9J_L_54ND9wm3E8Ew=.049d5535-7894-402d-9397-74275ab3ecd8@github.com>
 <IYc7WvyHe-vip5iSiNwfJFsGnwEkB5o1KFXnD5jT_gk=.eb067df9-4805-4fe0-9ecd-85d7c4d3bb22@github.com>
Message-ID: <79vVMnHrSZ9MEDcn0UzBYaPJKz63XZ3a7Qn4N0i-pa8=.adbe56c4-4a73-4015-b364-0196f1a4a75a@github.com>

On Mon, 28 Oct 2024 00:29:25 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> I was wondering what this was too but the _previous_owner_tid is the os thread id, not the Java thread id.
>> 
>> 
>> $ grep -r JFR_THREAD_ID
>> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) (JfrThreadLocal::external_thread_id(thread))
>> jfr/support/jfrThreadId.hpp:#define JFR_THREAD_ID(thread) ((traceid)(thread)->osthread()->thread_id())
>> runtime/objectMonitor.cpp:    _previous_owner_tid = JFR_THREAD_ID(current);
>> runtime/objectMonitor.cpp:    iterator->_notifier_tid = JFR_THREAD_ID(current);
>> runtime/vmThread.cpp:  event->set_caller(JFR_THREAD_ID(op->calling_thread()));
>
> Then it looks like the JFR code needs updating as well, otherwise it is going to be reporting inconsistent information when virtual threads are locking monitors.

So we use the os thread id when INCLUDE_JFR is not defined, but in that case we never actually post JFR events. So these _previous_owner_tid/_notifier_tid will be unused.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831592617

From pchilanomate at openjdk.org  Wed Nov  6 19:40:46 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 19:40:46 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
Message-ID: <EOwH-8BGyV4XLxc63jWvTHTNiWhowp0oLqacwI-5_Os=.e1c144a2-30ce-49bf-8589-931b150ca095@github.com>

On Tue, 29 Oct 2024 02:09:24 GMT, Dean Long <dlong at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> src/hotspot/cpu/x86/c1_Runtime1_x86.cpp line 223:
> 
>> 221: }
>> 222: 
>> 223: void StubAssembler::epilogue(bool use_pop) {
> 
> Is there a better name we could use, like `trust_fp` or `after_resume`?

I think `trust_fp` would be confusing because at this point rfp will have an invalid value and we don't want to use it to restore sp, i.e. we should not trust fp. And `after_resume` wouldn't always apply since we don't always preempt. The `use_pop` name was copied form x64, but I think it's still fine here. We also have the comment right below this line which explains why we don't want to use `leave()` and instead pop the top words from the stack.

> src/hotspot/cpu/x86/c2_MacroAssembler_x86.cpp line 324:
> 
>> 322:   movq(scrReg, tmpReg);
>> 323:   xorq(tmpReg, tmpReg);
>> 324:   movptr(boxReg, Address(r15_thread, JavaThread::lock_id_offset()));
> 
> I don't know if it helps to schedule this load earlier (it is used in the next instruction), but it probably won't hurt.

I moved it before `movq(scrReg, tmpReg)` since we need `boxReg` above, but I don't think this will change anything.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1659:
> 
>> 1657:   int i = 0;
>> 1658:   for (frame f = freeze_start_frame(); Continuation::is_frame_in_continuation(ce, f); f = f.sender(&map), i++) {
>> 1659:     if (!((f.is_compiled_frame() && !f.is_deoptimized_frame()) || (i == 0 && (f.is_runtime_frame() || f.is_native_frame())))) {
> 
> OK, `i == 0` just means first frame here, so you could use a bool instead of an int, or even check for f == freeze_start_frame(), right?

Changed to use boolean `is_top_frame`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831594384
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831597325
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831599268

From pchilanomate at openjdk.org  Wed Nov  6 19:40:48 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Wed, 6 Nov 2024 19:40:48 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <kAsIWxColst2MUjz1XmuMGwD9UN2_hSodEIZX2xf7jw=.a59ddaab-8cb0-4145-bd22-c65f32dca9f9@github.com>
 <DcWgDwNFi11X0zV9Wys1PuTfnEDcAEzs9WDZOvviQ0A=.2b27ed8d-cf74-47bd-9a13-19e7b99ccd0d@github.com>
Message-ID: <ZfWP6cjSC8ObaZ0mNXei9U7I83oQdlk9nhxSOjporZU=.cd529cda-8caa-4358-95d2-1430d546b783@github.com>

On Sat, 26 Oct 2024 05:39:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/java/lang/reflect/callerCache/ReflectionCallerCacheTest.java line 30:
>> 
>>> 28:  *         by reflection API
>>> 29:  * @library /test/lib/
>>> 30:  * @requires vm.compMode != "Xcomp"
>> 
>> If there is a problem with this test running with -Xcomp and virtual threads, maybe it should be handled as a separate bug fix.
>
> JBS has several issues related to ReflectionCallerCacheTest.java and -Xcomp, going back several releases. It seems some nmethod is keeping objects alive and is preventing class unloading in this test. The refactoring of j.l.ref in JDK 19 to workaround pinning issues made it go away. There is some minimal revert in this PR to deal with the potential for preemption when polling a reference queue and it seems the changes to this Java code have brought back the issue. So it's excluded from -Xcomp again.  Maybe it would be better to add it to ProblemList-Xcomp.txt instead? That would allow it to link to one of the JSB issue on this issue.

I added the test to `test/jdk/ProblemList-Xcomp.txt` instead with a reference to 8332028.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831604339

From vromero at openjdk.org  Wed Nov  6 20:08:54 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 6 Nov 2024 20:08:54 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v2]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - fixing build error
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - 8343286: Redundant cast in polymorphic method call

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/3ead0d87..34b5b020

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=00-01

  Stats: 6969 lines in 231 files changed: 5321 ins; 959 del; 689 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

PR: https://git.openjdk.org/jdk/pull/21914

From darcy at openjdk.org  Wed Nov  6 20:08:54 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 6 Nov 2024 20:08:54 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <_cMEb_DycFx605fxkjmSja7db4SJ2RbMZiR1oIb2c1s=.59015f58-375a-47f1-9403-71d21c2856f9@github.com>

On Tue, 5 Nov 2024 19:51:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Hi @vicente-romero-oracle , please file a CSR to evaluate the behavioral changes here. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21914#issuecomment-2458209273

From jvernee at openjdk.org  Wed Nov  6 20:52:44 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 6 Nov 2024 20:52:44 GMT
Subject: RFR: 8334107: Specification for MemorySegment::get/setString could
 use some clarification
In-Reply-To: <U-YFiGau2bynPVoOpPTB6SMseinf264wWJ_wxlEPQkE=.d1489660-3db0-4d00-8c1a-ad244fd1f67a@github.com>
References: <U-YFiGau2bynPVoOpPTB6SMseinf264wWJ_wxlEPQkE=.d1489660-3db0-4d00-8c1a-ad244fd1f67a@github.com>
Message-ID: <PvOtOhs779kuQYwsTHYPnUKbegXCcbvClluLS6hPD80=.3dad203e-f1b2-4bfc-806c-29ff399c2b2d@github.com>

On Wed, 6 Nov 2024 13:52:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add additional text for the `@param charset` tags in the `MemorySegment.(get|set)String` overloads that take a `charset`. 
> 
> This PR does not need a CSR, as the specs already state that an exception will be thrown if the provided `charset` is not a standard charset.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21927#pullrequestreview-2419390961

From kbarrett at openjdk.org  Wed Nov  6 21:27:59 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 6 Nov 2024 21:27:59 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <rVJXGo-DF04qPDC5s93gZktZ41429-h2ZNFRCSERbzI=.86b0f46c-62a0-4f4d-8af7-c05ef0dd511a@github.com>

On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FIXME

Looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2419454529

From kbarrett at openjdk.org  Wed Nov  6 21:28:00 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Wed, 6 Nov 2024 21:28:00 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
 <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>
Message-ID: <ebrOcbIXqNUwLD-vhw4PyoMIl8KShh6JCCjE9xMwmFk=.fbed032e-4207-451b-a985-55ef5523862b@github.com>

On Wed, 6 Nov 2024 15:27:16 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/share/native/libjava/NativeLibraries.c line 67:
>> 
>>> 65:         strcat(jniEntryName, "_");
>>> 66:         strcat(jniEntryName, cname);
>>> 67:     }
>> 
>> I would prefer this be directly inlined at the sole call (in findJniFunction),
>> to make it easier to verify there aren't any buffer overrun problems. (I don't
>> think there are, but looking at this in isolation triggered warnings in my
>> head.)
>> 
>> Also, it looks like all callers of findJniFunction ensure the cname argument
>> is non-null. So there should be no need to handle the null case in
>> findJniFunction (other than perhaps an assert or something). That could be
>> addressed in a followup. (I've already implicitly suggested elsewhere in this
>> PR revising this function in a followup because of the JNI_ON[UN]LOAD_SYMBOLS
>> thing.)
>
> @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already.

The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here.  The second part,
cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm
okay with being in a followup.  I guess I can live with the first part being in that followup too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1831728737

From mcimadamore at openjdk.org  Wed Nov  6 22:07:43 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 6 Nov 2024 22:07:43 GMT
Subject: RFR: 8343394: Make MemorySessionImpl.state a stable field [v5]
In-Reply-To: <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
 <FHRprPutPrO6gpKMMpbg6aY7y0oM_L4Smi0wOoj3LN4=.72deccd9-357a-4ad4-b5c7-0d889bb22db2@github.com>
Message-ID: <EwsfOOotb9zagg9EvmQXiAlp8_dMblrP1nyWtj8CWfc=.79e0af95-227d-4f75-b6fc-f86aa69f1f9d@github.com>

On Tue, 5 Nov 2024 14:07:12 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
>> 
>> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
>> 
>> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
>> 
>> For reference this is the results without this patch:
>> 
>>     Benchmark                      Mode  Cnt  Score   Error  Units
>>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
>> 
>> Please kindly review, thanks very much.
>
> Quan Anh Mai has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - copyright year
>  - address reviews

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21810#pullrequestreview-2419514822

From pchilanomate at openjdk.org  Thu Nov  7 00:38:18 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:38:18 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:

  Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/211c6c81..37e30171

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=00-01

  Stats: 108 lines in 7 files changed: 65 ins; 33 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Thu Nov  7 00:43:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
Message-ID: <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>

On Wed, 6 Nov 2024 16:31:24 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Regarding the pop_frame/early_ret/async_exception conditions, not checking for them after we started the transition would be an issue.
>> For pop_frame/early_ret checks, the problem is that if any of them are installed in `JvmtiUnmountBeginMark()` while trying to start the transition, and later the call to freeze succeeds, when returning to the interpreter (monitorenter case) we will incorrectly follow the JVMTI code [1], instead of going back to `call_VM_preemptable` to clear the stack from the copied frames. As for the asynchronous exception check, if it gets installed in `JvmtiUnmountBeginMark()` while trying to start the transition, the exception would be thrown in the carrier instead, very likely while executing the unmounting logic.
>> When unmounting from Java, although the race is also there when starting the VTMS transition as you mentioned, I think the end result will be different. For pop_frame/early_ret we will just bail out if trying to install them since the top frame will be a native method (`notifyJvmtiUnmount`). For the async exception, we would process it on return from `notifyJvmtiUnmount` which would still be done in the context of the vthread.
>> 
>> [1]  https://github.com/openjdk/jdk/blob/471f112bca715d04304cbe35c6ed63df8c7b7fee/src/hotspot/cpu/x86/macroAssembler_x86.cpp#L1629
>
> Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.
> 
>> but does the specs say the event has to be posted in the context of the vthread?
> 
> As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.
> 
>> For pop_frame/early_ret checks ...
> 
> The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
> 
>> Maybe we could go with this simplified code now and work on it later...
> 
> Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
> It would be nice to fix a couple of nits though:
>  - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
>  - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter

Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898126

From pchilanomate at openjdk.org  Thu Nov  7 00:43:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
Message-ID: <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>

On Thu, 7 Nov 2024 00:37:17 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Thank you for the comment! I'm okay with your modified suggestion in general if there are no road blocks.
>> 
>>> but does the specs say the event has to be posted in the context of the vthread?
>> 
>> As Alan said below we do not have an official spec for this but still the events need to be posted in vthread context.
>> 
>>> For pop_frame/early_ret checks ...
>> 
>> The pop_frame/early_ret conditions are installed in handshakes with a context of `JvmtiVTMSTransitionDisabler`. As you noted the `JVMTI_ERROR_OPAQUE_FRAME` might be also returned by the JVMTI `FramePop` and `ForceEarlyReturn*` for some specific cases. So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>> 
>>> Maybe we could go with this simplified code now and work on it later...
>> 
>> Whatever works better for you. An alternate approach could be to file an enhancement to simplify/refactor this.
>> It would be nice to fix a couple of nits though:
>>  - the call to `java_lang_Thread::set_is_in_VTMS_transition()`is not needed in `JvmtiUnmountBeginMark`
>>  - the function `is_vthread_safe_to_preempt()` does not need the `vthread` parameter
>
> Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished.

> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>
The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898439

From pchilanomate at openjdk.org  Thu Nov  7 00:43:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
 <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
Message-ID: <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>

On Thu, 7 Nov 2024 00:37:53 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Great, I applied the suggested simplification. I had to update test `VThreadEventTest.java` to check the stack during the mount/unmount events to only count the real cases. This is because now we are getting a variable number of spurious mount/unmount events (freeze failed) generated during the initialization of some class (`VirtualThreadEndEvent`) after the task is finished.
>
>> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>>
> The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java.

> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark
>
Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831898891

From pchilanomate at openjdk.org  Thu Nov  7 00:43:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
 <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
 <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>
Message-ID: <kEcDoawSPu6W5TMBXMcjhhwHWDdYjoaYJahRCySSs9E=.4111eada-1ef0-4183-92cc-fb17ab60bce2@github.com>

On Thu, 7 Nov 2024 00:38:40 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> So, it feels like it should not be a problem. I'm thinking if adding an assert at the VTMS transition end would help.
>>>
>> The problem here is that for monitorenter the top frame will not be a native method, so the bail out will not happen as it would when unmounting from Java.
>
>> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark
>>
> Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both?

> the function is_vthread_safe_to_preempt() does not need the vthread parameter
> 
Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899049

From pchilanomate at openjdk.org  Thu Nov  7 00:43:08 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 00:43:08 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
 <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>
Message-ID: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com>

On Wed, 6 Nov 2024 15:57:55 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix.
>
If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1831899882

From jpai at openjdk.org  Thu Nov  7 00:55:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Nov 2024 00:55:52 GMT
Subject: Integrated: 8342647: [macosx] Clean up the NSInvocation based call to
 NSProcessInfo.operatingSystemVersion
In-Reply-To: <SzZICb-aR_RUOor8aydA6hvQ0GbxEUquGvtTk1joe-Y=.91179760-d934-471e-bf2d-9af6466c1502@github.com>
References: <SzZICb-aR_RUOor8aydA6hvQ0GbxEUquGvtTk1joe-Y=.91179760-d934-471e-bf2d-9af6466c1502@github.com>
Message-ID: <sP0KwE36JwIYt2vGZD-O8tLFGHLl8Uqn993gPf23C7g=.96b50eb2-a993-4c51-8054-d34c14ea9168@github.com>

On Sun, 20 Oct 2024 06:41:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which does a tiny cleanup in the macosx specific code in `java_props_macosx.c`?
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8342647 the `setOSNameAndVersion` function used to dynamically call `NSProcessInfo.operatingSystemVersion` because that property wasn't (statically) available until macosx 10.10 version. Since that version this property has been available even in the latest macosx versions https://developer.apple.com/documentation/foundation/nsprocessinfo/1410906-operatingsystemversion, so it's now possible to statically reference it in the code.
> 
> The change in this PR replaces the use of `NSInvocation` with the static reference to this property. No new tests have been added. Existing tier1, tier2 and tier3 tests with this change have all passed.

This pull request has now been integrated.

Changeset: 9e31e78e
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9e31e78e39a4b573c158ef31af3ab4e9a1e229de
Stats:     43 lines in 1 file changed: 3 ins; 22 del; 18 mod

8342647: [macosx] Clean up the NSInvocation based call to NSProcessInfo.operatingSystemVersion

Reviewed-by: bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/21595

From pkoppula at openjdk.org  Thu Nov  7 04:44:25 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 7 Nov 2024 04:44:25 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v11]
In-Reply-To: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
Message-ID: <e9XneE4CQS0xlG3zIFZbOCt6j-gz0kRRUTLh45Pjxbs=.6f4cf332-68e1-4546-a859-435a72669094@github.com>

> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.

Prasadrao Koppula has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge master
 - initialized storeName with empty string
 - Replaced Paths.get with Path.of
 - Removed unnecessary code
 - Removed unnecessary code
 - Handled nested wrappers around FileInputStream
 - Handled BIS case as well
 - JDK-8329251
 - JDK-8329251
 - JDK-8329251
 - ... and 1 more: https://git.openjdk.org/jdk/compare/f2316f68...c90b4f30

-------------

Changes: https://git.openjdk.org/jdk/pull/20414/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20414&range=10
  Stats: 341 lines in 12 files changed: 330 ins; 1 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/20414.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20414/head:pull/20414

PR: https://git.openjdk.org/jdk/pull/20414

From mchung at openjdk.org  Thu Nov  7 04:57:02 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 7 Nov 2024 04:57:02 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v45]
In-Reply-To: <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
Message-ID: <FLNjVnC9cyaloHfgY1Z3Kv-QJryKeZXmDmwWkc_oZG4=.3084cfc8-2441-4bd7-a15d-22e0f485712a@github.com>

On Wed, 6 Nov 2024 11:24:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Make capability in --help human readable
>  - Fix comment
>  - Fix SystemModulesTest2 when linkable runtime but no packaged modules
>  - Rename PackagedModulesVsJmodLessTest => PackagedModulesVsRuntimeImageLinkTest
>  - Rename JmodLess => runtimeImage
>  - Refactor tests so that they run for default build
>    
>    When a default JDK build is being produced, the tests create a run-time
>    image capable JDK as an interim step before everything else is being
>    verified.
>    
>    For a build that has the run-time image link capability already turned
>    on, this extra step is being omitted.
>  - Mandy's feedback
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Some test fixes
>  - ... and 170 more: https://git.openjdk.org/jdk/compare/83f3d42d...e83b9584

Another question about the tests.  Most of the tests have 2 `@test id=XXX` for example `@test id=packaged_modules` requires `jlink.packagedModules` `@test id=linkable_jdk_runtimes` requires `jlink.runtime.linkable & !jlink.packagedModules`.   Similarly, the new `runtimeImage` tests have `@test id=default_build` and `@test id=linkable_runtime`.  `@run` is passed with an additional argument (true or false) to the main program to indicate the JDK configuration.

For each test execution with one test JDK which is built with one configuration, it can only have at most one test run and the other `@test` will be skipped. It seems to me that it's much simpler to keep it a single `@test` instead of 2 different `@test` (avoid duplicating with all test tags) and have the main method to determine if the JDK is linkable run-time image and it has packaged modules via test library.  Or am I missing something of testing story?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2461316942

From pkoppula at openjdk.org  Thu Nov  7 05:11:43 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 7 Nov 2024 05:11:43 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v9]
In-Reply-To: <4RUG7fJhlj6bGn0lG6KisaeKTCYR528mUHIpvLA7mmo=.2c019424-b526-4934-a143-6d990cb37a89@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <Oyz2VnEyiPMEx8inZTUalDGMIXn9PHN7KP_lB6FXa1s=.e058d113-f858-44ae-b04c-2d2516578de3@github.com>
 <4RUG7fJhlj6bGn0lG6KisaeKTCYR528mUHIpvLA7mmo=.2c019424-b526-4934-a143-6d990cb37a89@github.com>
Message-ID: <T-LFYZ80hmY8jyY2Z4MEBZYaMVm1neCf2jRd-A_1GLQ=.35164ee9-5f76-4fa6-8855-6ebe8d5782ad@github.com>

On Wed, 6 Nov 2024 14:27:15 GMT, Sean Coffey <coffeys at openjdk.org> wrote:

> This looks good to me.
> 
> I'd suggest logging a new JBS issue to track removal of the Debug.getInstance("pkcs12") use case and substituting it with getInstance("keystore") code (esp. since pkcs12 is now the default keystore type)

New JBS: https://bugs.openjdk.org/browse/JDK-8343743

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20414#issuecomment-2461330408

From mchung at openjdk.org  Thu Nov  7 05:18:07 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Thu, 7 Nov 2024 05:18:07 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v45]
In-Reply-To: <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
Message-ID: <Z42zmzw3iJObSLyQ46aE_h7kUTF4Vk_hsw5jWfxAsQk=.538364e9-4f89-40cd-a0fb-e93ef4e33c68@github.com>

On Wed, 6 Nov 2024 11:24:23 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits:
> 
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Make capability in --help human readable
>  - Fix comment
>  - Fix SystemModulesTest2 when linkable runtime but no packaged modules
>  - Rename PackagedModulesVsJmodLessTest => PackagedModulesVsRuntimeImageLinkTest
>  - Rename JmodLess => runtimeImage
>  - Refactor tests so that they run for default build
>    
>    When a default JDK build is being produced, the tests create a run-time
>    image capable JDK as an interim step before everything else is being
>    verified.
>    
>    For a build that has the run-time image link capability already turned
>    on, this extra step is being omitted.
>  - Mandy's feedback
>  - Merge branch 'master' into jdk-8311302-jmodless-link
>  - Some test fixes
>  - ... and 170 more: https://git.openjdk.org/jdk/compare/83f3d42d...e83b9584

I reviewed and approved the source changes.   For the test changes, I believe multiple `@test` tags to verify a JDK of linkable run-time image and another JDK with packaged modules are not necessary.  Each test execution can only verify one JDK.  The tests can keep one single `@test` and the main method has to determine the test JDK configuration for test verification.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 132:

> 130:         } catch (RuntimeImageLinkException e) {
> 131:             // populate modified files exception
> 132:             throw e;

It's unchecked exception and this catch clause can be dropped.

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/RuntimeImageLinkException.java line 45:

> 43:     public RuntimeImageLinkException(String file, Reason reason) {
> 44:         this.file = file;
> 45:         this.reason = reason;

Suggestion:

        this.file = Objects.requireNonNull(file);
        this.reason = Objects.requireNonNull(reason);

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 126:

> 124: \ and cannot be used to create another image with the jdk.jlink module
> 125: err.runtime.link.packaged.mods=This JDK has no packaged modules.\
> 126: \ --keep-packaged-modules is not supported.

Suggestion:

err.runtime.link.packaged.mods=This JDK has no packaged modules.\
\ --keep-packaged-modules is not supported

-------------

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2419929066
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1832055001
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1832055943
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1832040227

From aturbanov at openjdk.org  Thu Nov  7 06:35:45 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 7 Nov 2024 06:35:45 GMT
Subject: RFR: 8342693: Use byte[] as parameter in a FDBigInteger
 constructor and as field
In-Reply-To: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>
References: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>
Message-ID: <OSHvk1om1LqpXFZ2TAtRE2K7CaEcH1V-XkdM3pjYbX0=.b555fb19-42d1-42de-b6db-5d5fa5e5eb5b@github.com>

On Mon, 21 Oct 2024 14:25:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This helps in reducing memory consumption, especially for long inputs.

src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1875:

> 1873:             }  // look for and process decimal floating-point string
> 1874: 
> 1875:             byte[] digits = new byte[ len ];

Suggestion:

            byte[] digits = new byte[len];

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21614#discussion_r1832129129

From pminborg at openjdk.org  Thu Nov  7 07:28:47 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Nov 2024 07:28:47 GMT
Subject: Integrated: 8334107: Specification for MemorySegment::get/setString
 could use some clarification
In-Reply-To: <U-YFiGau2bynPVoOpPTB6SMseinf264wWJ_wxlEPQkE=.d1489660-3db0-4d00-8c1a-ad244fd1f67a@github.com>
References: <U-YFiGau2bynPVoOpPTB6SMseinf264wWJ_wxlEPQkE=.d1489660-3db0-4d00-8c1a-ad244fd1f67a@github.com>
Message-ID: <gDkNP8P-NhttF7w0IBiZrKGEStr6T1zRSOq4x0Azjr0=.50b63ea4-5582-42ab-839a-9f7a0e469b27@github.com>

On Wed, 6 Nov 2024 13:52:32 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add additional text for the `@param charset` tags in the `MemorySegment.(get|set)String` overloads that take a `charset`. 
> 
> This PR does not need a CSR, as the specs already state that an exception will be thrown if the provided `charset` is not a standard charset.

This pull request has now been integrated.

Changeset: 619b4d59
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/619b4d596634ee84b9bf5884b97a69eb01661657
Stats:     5 lines in 1 file changed: 3 ins; 0 del; 2 mod

8334107: Specification for MemorySegment::get/setString could use some clarification

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21927

From turbanoff at gmail.com  Thu Nov  7 08:17:00 2024
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Thu, 7 Nov 2024 11:17:00 +0300
Subject: Can LinkedHashMap(accessOrder=true) be guarded by ReadWriteLock ?
Message-ID: <CAF+DQ5ciFShpYPkgLaaHOPdiQdpQ-0veo9GLKtiY1NM9GbhTAw@mail.gmail.com>

Hello.
I've got a question about LinkedHashMap created with accessOrder=true flag.
Usually this constructor is used when we want to build LRU cache.
https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/LinkedHashMap.html#<init>(int,float,boolean)

        LinkedHashMap<MyKey, MyValue> cache = new LinkedHashMap<>(8, 1f, true) {
            @Override
            protected boolean removeEldestEntry(Map.Entry<MyKey,
MyValue> eldest) {
                return size() > 32;
            }
        };

LinkedHashMap is not a thread-safe data structure, so to be able to
use it in a concurrent environment, access to it should be guarded by
some kind of synchronization.
I often see in many projects that such access is guarded by
ReentrantReadWriteLock.
Example in OpenJDK:
https://github.com/openjdk/jdk/blob/0e1c1b793d43064aabe9571057284899c9580f30/src/java.desktop/share/classes/sun/awt/image/ImageCache.java#L46

private final ReentrantReadWriteLock readWriteLock = new
ReentrantReadWriteLock();

public MyValue get(MyKey key) {
    readWriteLock.readLock().lock();
    try {
        return cache.get(key);
    } finally {
        readWriteLock.readLock().unlock();
    }
}

public void put(MyKey key, MyValue value) {
    readWriteLock.writeLock().lock();
    try {
        cache.put(key, value);
    } finally {
        readWriteLock.writeLock().unlock();
    }
}

I can see in LHM javadoc that LinkedHashMap.get in such a case can
cause structural modification:
"In access-ordered linked hash maps, merely querying the map with get
is a structural modification."

As I understand, it means that LinkedHashMap.get can't be guarded
_just_ by ReadLock.
Is my assumption correct?

Andrey Turbanov

From forax at univ-mlv.fr  Thu Nov  7 08:28:51 2024
From: forax at univ-mlv.fr (Remi Forax)
Date: Thu, 7 Nov 2024 09:28:51 +0100 (CET)
Subject: Can LinkedHashMap(accessOrder=true) be guarded by ReadWriteLock ?
In-Reply-To: <CAF+DQ5ciFShpYPkgLaaHOPdiQdpQ-0veo9GLKtiY1NM9GbhTAw@mail.gmail.com>
References: <CAF+DQ5ciFShpYPkgLaaHOPdiQdpQ-0veo9GLKtiY1NM9GbhTAw@mail.gmail.com>
Message-ID: <1902759052.19912535.1730968131954.JavaMail.zimbra@univ-eiffel.fr>

----- Original Message -----
> From: "Andrey Turbanov" <turbanoff at gmail.com>
> To: "core-libs-dev" <core-libs-dev at openjdk.java.net>
> Sent: Thursday, November 7, 2024 9:17:00 AM
> Subject: Can LinkedHashMap(accessOrder=true) be guarded by ReadWriteLock ?

> Hello.
> I've got a question about LinkedHashMap created with accessOrder=true flag.
> Usually this constructor is used when we want to build LRU cache.
> https://docs.oracle.com/en/java/javase/21/docs/api/java.base/java/util/LinkedHashMap.html#<init>(int,float,boolean)
> 
>        LinkedHashMap<MyKey, MyValue> cache = new LinkedHashMap<>(8, 1f, true) {
>            @Override
>            protected boolean removeEldestEntry(Map.Entry<MyKey,
> MyValue> eldest) {
>                return size() > 32;
>            }
>        };
> 
> LinkedHashMap is not a thread-safe data structure, so to be able to
> use it in a concurrent environment, access to it should be guarded by
> some kind of synchronization.
> I often see in many projects that such access is guarded by
> ReentrantReadWriteLock.
> Example in OpenJDK:
> https://github.com/openjdk/jdk/blob/0e1c1b793d43064aabe9571057284899c9580f30/src/java.desktop/share/classes/sun/awt/image/ImageCache.java#L46
> 
> private final ReentrantReadWriteLock readWriteLock = new
> ReentrantReadWriteLock();
> 
> public MyValue get(MyKey key) {
>    readWriteLock.readLock().lock();
>    try {
>        return cache.get(key);
>    } finally {
>        readWriteLock.readLock().unlock();
>    }
> }
> 
> public void put(MyKey key, MyValue value) {
>    readWriteLock.writeLock().lock();
>    try {
>        cache.put(key, value);
>    } finally {
>        readWriteLock.writeLock().unlock();
>    }
> }
> 
> I can see in LHM javadoc that LinkedHashMap.get in such a case can
> cause structural modification:
> "In access-ordered linked hash maps, merely querying the map with get
> is a structural modification."
> 
> As I understand, it means that LinkedHashMap.get can't be guarded
> _just_ by ReadLock.
> Is my assumption correct?
> 
> Andrey Turbanov

Hello Andrey,
yes !

This flavor of LinkedHashMap has always been a little dubious because having a Map.get() that does a structural modification can be qualified at best as surprising, at worst as not compliant with the contract of Map.

regards,
R?mi

From daniel.peintner at gmail.com  Thu Nov  7 08:43:27 2024
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 7 Nov 2024 09:43:27 +0100
Subject: [jpackage] Changes to icon handling between Java 17 and Java 21
 on Windows
In-Reply-To: <d28f07fb-f642-487b-beae-4f2cfbbf711b@oracle.com>
References: <CAAoP7T6SPwhxKUxsFG91Of5hWdBugTw9uJzev1DoM-s1MbKSRA@mail.gmail.com>
 <d28f07fb-f642-487b-beae-4f2cfbbf711b@oracle.com>
Message-ID: <CAAoP7T5+5KgYeg1dWNBb0N0pbw0=nOvv5a1e5j=BLNvKhuNsGw@mail.gmail.com>

Hi Alexey, all,

Thank you very much for your reply and the pointers you provided.

Honestly I don't mind whether the ico file is part of the exe or not. It
should just work as expected.
Having said that, we are seeing issues that in some cases it doesn't seem
to work (i.e., not showing any icon).

Let's hope this is an exception?

Thanks,

-- Daniel



On Wed, Nov 6, 2024 at 7:04?PM Alexey Semenyuk <alexey.semenyuk at oracle.com>
wrote:

> Hi Daniel,
>
> On Windows, the jpackage embeds icons in app launcher executables and
> there is no reason to keep these .ico files in the app image. In [1], it
> was reasonably requested not to include app launcher icons in the app
> image on Windows, and that was fulfilled.
>
> [1] https://bugs.openjdk.org/browse/JDK-8281682
>
> - Alexey
>
>
> On 11/6/2024 4:19 AM, Daniel Peintner wrote:
> > Hello,
> >
> > I am not sure if this is the right place to ask, but I hope so.
> > If not please let me know where I can report this kind of problem.
> >
> > Recently we changed from JDK 17 to JDK 21 and something seems to have
> > changed when running jpackage with --icon option.
> >
> > Produced structure on Windows for
> >
> > # Java 17
> > /app
> > /runtime
> > foo.exe
> > foo.ico
> >
> > while for
> >
> > # Java 21 (v 21.0.5)
> > /app
> > /runtime
> > foo.exe
> >
> > As you can see the foo.ico is missing.
> > Note: the foo.exe still shows the right icon when looking at it in
> > FileExplorer.
> >
> > Anyhow, on some devices the missing ico file is causing issues.
> > There is no icon on the program list nor in the taskbar (see attached
> > images).
> >
> > Note: On some windows installations it works without issues.
> >
> > Is this a known problem? I tried to browse through
> > https://bugs.openjdk.org without finding such a bug report.
> >
> > Thanks for any input/advice.
> >
> > -- Daniel
> >
> >
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241107/d669f791/attachment.htm>

From amitkumar at openjdk.org  Thu Nov  7 08:47:14 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 7 Nov 2024 08:47:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
Message-ID: <8WsQTNy83zv4Z7kD6SPo60kURL1EFe3ZMbD4QCqo3II=.3895ed74-7940-436a-aff2-f7aeafbef2b3@github.com>

On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Good work! I'll approve the GC related changes.
>> 
>> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.
>> 
>> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.
>> 
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> ```
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>> ```
>>
> Updated comment.

@pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes.

One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x. 

[CancelTimerWithContention.log](https://github.com/user-attachments/files/17658594/CancelTimerWithContention.log)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461640546

From mbaesken at openjdk.org  Thu Nov  7 09:16:42 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Thu, 7 Nov 2024 09:16:42 GMT
Subject: RFR: 8343610: InOutPathTest jpackage test produces invalid app
 image on macOS
In-Reply-To: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
References: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
Message-ID: <YZzmyvnrJc-FFiiW9a2xPFPVXkcDFUGIhSD-DG04WVk=.1ad6dc75-6672-4671-84e8-12006d1ef334@github.com>

On Tue, 5 Nov 2024 16:08:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - fix `JPackageCommand.excludeAppLayoutAsserts()`;
> - fix `InOutPath` test case that will make jpackage produce an invalid app image on macOS.

Hi Aleksei, with your patch added I see so far no errors any more related to InOutPathTest test in our test env .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21909#issuecomment-2461701125

From alanb at openjdk.org  Thu Nov  7 09:43:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Nov 2024 09:43:11 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
Message-ID: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>

On Wed, 6 Nov 2024 17:38:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> Good work! I'll approve the GC related changes.
>> 
>> There are some simplifications I think can be done in the ObjectMonitor layer, but nothing that should go into this PR.
>> 
>> Similarly, (even if some of this is preexisting issues) I think that the way we describe the frames and the different frame transitions should be overhauled and made easier to understand. There are so many unnamed constants and adjustments which are spread out everywhere, which makes it hard to get an overview of exactly what happens and what interactions are related to what.  You and Dean did a good job at simplifying and adding comments in this PR. But I hope this can be improved in the fututre.
>> 
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>
>> A small note on `_cont_fastpath`, as it is now also used for synchronised native method calls (native wrapper) maybe the comment should be updated to reflect this.
>> 
>> ```
>> // the sp of the oldest known interpreted/call_stub frame inside the
>> // continuation that we know about
>> ```
>>
> Updated comment.

> @pchilano `CancelTimerWithContention.java` test is failing on s390x with Timeout Error. One weird thing is that it only fails when I run whole tier1 test suite. But when ran independently test passes.
> 
> One thing I would like to mention is that I ran test by **disabling** VMContinuations, as Vthreads are not yet supported by s390x.

We added this test to provoke contention on the delay queues, lots of timed-Object.wait with notification before the timeout is reached. This code is not used when running with -XX:+UnlockExperimentalVMOptions -XX:-VMContinuation. In that execution mode, each virtual thread is backed by a platform/native thread and in this test it will ramp up 10_000 virtual threads. The output in your log suggests it gets to ~4700 threads before the jtreg timeout kicks in. It might be that when you run the test on its own that there is enough resources for the test to pass, but not enough resources (just too slow) when competing with other tests.

I think we can add `@requires vm.continuations` to this test. It's not useful to run with the alternative virtual thread implementation.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461756432

From amitkumar at openjdk.org  Thu Nov  7 09:49:12 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Thu, 7 Nov 2024 09:49:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
 <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>
Message-ID: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com>

On Thu, 7 Nov 2024 09:40:19 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation.

Sure, that sounds ok. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2461768715

From galder at openjdk.org  Thu Nov  7 10:20:45 2024
From: galder at openjdk.org (Galder =?UTF-8?B?WmFtYXJyZcOxbw==?=)
Date: Thu, 7 Nov 2024 10:20:45 GMT
Subject: RFR: 8307513: C2: intrinsify Math.max(long,long) and
 Math.min(long,long)
In-Reply-To: <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
References: <6uzJCMkW_tFnyxzMbFGYfs7p3mezuBhizHl9dkR1Jro=.2da99701-7b40-492f-b15a-ef1ff7530ef7@github.com>
 <yVFbVwZTQCEgaPhy1gw8MPd3RaqlMxxwPFNpxm2SCfs=.aef2f2d3-527d-4218-b307-d49bd217f59e@github.com>
Message-ID: <ozyEuvjJJbZDecwHL46BN52RrExjTrLOFgSqiLaLvDQ=.910a6144-353e-4c09-b1b1-7f66854f7ec7@github.com>

On Thu, 11 Jul 2024 22:30:45 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> Overall, looks fine.
> 
> So, there will be `inline_min_max`, `inline_fp_min_max`, and `inline_long_min_max` which slightly vary. I'd prefer to see them unified. (Or, at least, enhance `inline_min_max` to cover `minL`/maxL` cases).
> 
> Also, it's a bit confusing to see int variants names w/o basic type (`_min`/`_minL` vs `_minI`/`_minL`). Please, clean it up along the way. (FTR I'm also fine handling the renaming as a separate change.)

@iwanowww I applied the changes you suggested. Could you review them?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20098#issuecomment-2461843670

From dfuchs at openjdk.org  Thu Nov  7 10:25:48 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 7 Nov 2024 10:25:48 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <HEatBbxojCf_pdp6huYY8ehSoDPC2fX-2mzy-kh99tA=.fa421c23-9fdd-4b19-9274-18d2247bdd26@github.com>

On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

The code changes look reasonable to me. I had to re-read the documentation of `finishConnect` to get to that point. I mistakenly thought that this method was reserved for the fully non blocking case. I hadn't realised you could start connect() in non blocking mode and finish it in blocking mode... Thanks @AlanBateman for the thorough review of all these odd cases.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21528#pullrequestreview-2420545416

From alanb at openjdk.org  Thu Nov  7 11:09:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Nov 2024 11:09:02 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v32]
In-Reply-To: <mCQ63s2R90MfME2IcNJo0uRcyBhdh5SyXHcDciviM9w=.81e78abe-23fb-46e8-80c3-eb809d70ed09@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <epmqwL577o7SZIu_l6y13bnYHRqJOAz15i_CmMhf8j0=.ac12ae3a-b1d2-4f63-832b-b8e76cda7908@github.com>
 <Jd1IjGY4f5x21FEtT-G0v8Bz8E5Ufg4HoZvLK5C1q04=.bb931989-1eff-4e8c-8798-6d25bf36c211@github.com>
 <2HKfxaPysSsNwikk5Kgqx3_mNarIC_DRycPLyP_Hlwk=.7253908b-6e5a-4d5c-a968-5af0d9db94ae@github.com>
 <mCQ63s2R90MfME2IcNJo0uRcyBhdh5SyXHcDciviM9w=.81e78abe-23fb-46e8-80c3-eb809d70ed09@github.com>
Message-ID: <VNTO5__GNhL2agnPXxGjDVCw00vJTDQn4hQQBZF8OCI=.3db91b7e-c40d-4317-a796-fed4835a0b26@github.com>

On Fri, 14 Jun 2024 06:49:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> My aim will be to bring this into JDK 24 with a JEP then. Hopefully we can bring this to a successful conclusion that way.
>> 
>> @AlanBateman JEP draft is here:
>> https://openjdk.org/jeps/8333799
>> 
>> Could you please help review it? Thanks!
>
>> Could you please help review it? Thanks!
> 
> Yes, on my list.

> Therefore, paging @AlanBateman @mlchung @mbreinhold @magicus for their final thoughts. Thank you!

ACK. I'll do another pass on the changes in the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2461950790

From vromero at openjdk.org  Thu Nov  7 12:03:43 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 12:03:43 GMT
Subject: RFR: 8341399: Add since checker tests to the langtools modules
 [v6]
In-Reply-To: <fBPuS7YR_HLfktERI27HgDiEpp1SiV42VXSCfBcP450=.10284966-be20-4c6f-a35c-ae2f3e961677@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
 <fBPuS7YR_HLfktERI27HgDiEpp1SiV42VXSCfBcP450=.10284966-be20-4c6f-a35c-ae2f3e961677@github.com>
Message-ID: <MaOvobvcBg5KPvjonbtkI80u1-IyucOfKd585y2zu8A=.13719c83-8fde-46e3-a8cd-8b07459bff20@github.com>

On Mon, 4 Nov 2024 18:30:50 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

>> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
>> 
>> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
>> 
>> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
>> 
>> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
>> 
>> TIA
>
> Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:
> 
>   tiny change in test summary

lgtm

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21542#pullrequestreview-2420781852

From shade at openjdk.org  Thu Nov  7 12:12:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Nov 2024 12:12:01 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
Message-ID: <ek4kHDWK2rAwjeLVCxTjp0ddd0-gAV0JDSxjltGk7vQ=.2d6b3642-1e93-4221-936a-a35466011d8e@github.com>

On Wed, 6 Nov 2024 00:56:49 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   fix: jvm_md.h was included, but not jvm.h...
>
> src/hotspot/os/windows/os_windows.cpp line 510:
> 
>> 508: // Thread start routine for all newly created threads.
>> 509: // Called with the associated Thread* as the argument.
>> 510: static unsigned thread_native_entry(void* t) {
> 
> Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`.
> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170

Not sure why this comment was marked as "Resolved". I have the same question here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832573434

From shade at openjdk.org  Thu Nov  7 12:18:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 7 Nov 2024 12:18:57 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>

On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FIXME

I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2420814976

From jwaters at openjdk.org  Thu Nov  7 12:18:58 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Thu, 7 Nov 2024 12:18:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <ek4kHDWK2rAwjeLVCxTjp0ddd0-gAV0JDSxjltGk7vQ=.2d6b3642-1e93-4221-936a-a35466011d8e@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <Hsc2n3FHTJ8KKNxguL5kGJPpVmW-QaGzJW7aMKFjYIw=.fb2a9887-1bfb-4adf-bf5a-8c977df593da@github.com>
 <ek4kHDWK2rAwjeLVCxTjp0ddd0-gAV0JDSxjltGk7vQ=.2d6b3642-1e93-4221-936a-a35466011d8e@github.com>
Message-ID: <tS1vWH4y8eWktyKyl4SSRdmz-g-WlQtjcHGggdbLD_Y=.7a9eda40-4d5f-458f-95cf-bd65f4623c2c@github.com>

On Thu, 7 Nov 2024 12:08:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/hotspot/os/windows/os_windows.cpp line 510:
>> 
>>> 508: // Thread start routine for all newly created threads.
>>> 509: // Called with the associated Thread* as the argument.
>>> 510: static unsigned thread_native_entry(void* t) {
>> 
>> Whoa! Hold on there. The `_stdcall` is required here and nothing to do with 32-bit. We use `begindthreadex` to start threads and the entry function is required to be `_stdcall`.
>> https://learn.microsoft.com/en-us/cpp/c-runtime-library/reference/beginthread-beginthreadex?view=msvc-170
>
> Not sure why this comment was marked as "Resolved". I have the same question here.

@shipilev See addressing comments below:

> https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170
> On ARM and x64 processors, __stdcall is accepted and ignored by the compiler; on ARM and x64 architectures, by convention, arguments are passed in registers when possible, and subsequent arguments are passed on the stack.






> To my knowledge the only thing __cdecl and __stdcall do is affect the argument passing on the stack since 32 bit uses the stack to pass arguments. Since 64 bit passes arguments inside registers and then only later uses the stack if there are too many parameters to fit in the parameter registers (Basically permanent __fastcall), these specifiers are probably ignored in all 64 bit platforms

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1832581212

From asemenyuk at openjdk.org  Thu Nov  7 12:35:48 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Nov 2024 12:35:48 GMT
Subject: Integrated: 8343610: InOutPathTest jpackage test produces invalid app
 image on macOS
In-Reply-To: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
References: <7peutmMBIPuHcDFo1ps2iq-KaPTsXe5329u_QOn9vEA=.9a9d0016-027d-4525-b427-61cfb3c76400@github.com>
Message-ID: <D4ZOgmBV5qIMBxKnRuc-rVep8APvPSPuu_VoXbtesqw=.a793e2a0-a697-4224-9986-19bee70823c5@github.com>

On Tue, 5 Nov 2024 16:08:20 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> - fix `JPackageCommand.excludeAppLayoutAsserts()`;
> - fix `InOutPath` test case that will make jpackage produce an invalid app image on macOS.

This pull request has now been integrated.

Changeset: ac82a8f8
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ac82a8f89c7066fb1d379b12bcfd68053cb39ba4
Stats:     59 lines in 4 files changed: 46 ins; 0 del; 13 mod

8343610: InOutPathTest jpackage test produces invalid app image on macOS

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/21909

From asemenyuk at openjdk.org  Thu Nov  7 12:36:08 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Nov 2024 12:36:08 GMT
Subject: RFR: 8343396: Use OperatingSystem, Architecture,
 and OSVersion in jpackage tests
Message-ID: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>

Use internal jdk API instead of parsing JVM properties where appropriate in jpackage tests

-------------

Commit messages:
 - 8343396: Use OperatingSystem, Architecture, and OSVersion in jpackage tests

Changes: https://git.openjdk.org/jdk/pull/21940/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21940&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343396
  Stats: 8 lines in 2 files changed: 2 ins; 2 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21940.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21940/head:pull/21940

PR: https://git.openjdk.org/jdk/pull/21940

From asemenyuk at openjdk.org  Thu Nov  7 12:36:08 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Nov 2024 12:36:08 GMT
Subject: RFR: 8343396: Use OperatingSystem, Architecture,
 and OSVersion in jpackage tests
In-Reply-To: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
References: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
Message-ID: <sbu4iUMoFUNeYg8eRiHcCu06obWMEoz12FtIMtQveP8=.6117cc0a-a8e5-4177-bb98-c0dc72887e54@github.com>

On Wed, 6 Nov 2024 21:42:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use internal jdk API instead of parsing JVM properties where appropriate in jpackage tests

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21940#issuecomment-2462120368

From alexey.semenyuk at oracle.com  Thu Nov  7 12:54:11 2024
From: alexey.semenyuk at oracle.com (Alexey Semenyuk)
Date: Thu, 7 Nov 2024 07:54:11 -0500
Subject: [External] : Re: [jpackage] Changes to icon handling between Java
 17 and Java 21 on Windows
In-Reply-To: <CAAoP7T5+5KgYeg1dWNBb0N0pbw0=nOvv5a1e5j=BLNvKhuNsGw@mail.gmail.com>
References: <CAAoP7T6SPwhxKUxsFG91Of5hWdBugTw9uJzev1DoM-s1MbKSRA@mail.gmail.com>
 <d28f07fb-f642-487b-beae-4f2cfbbf711b@oracle.com>
 <CAAoP7T5+5KgYeg1dWNBb0N0pbw0=nOvv5a1e5j=BLNvKhuNsGw@mail.gmail.com>
Message-ID: <6983407a-0127-4397-bb9f-4dfd0b0f1bcf@oracle.com>

Hi Daniel,

Given your description of the issue with blank icons as specific to some 
deployments only, it may be a Windows issue.
"missing" .ico files in app image should not be the cause.

However, I find it suspicious that other app icons are OK on your 
screenshots and only an icon of the package-created app is blank. If you 
have a reproducible example, please file a bug!

- Alexey

On 11/7/2024 3:43 AM, Daniel Peintner wrote:
> Hi Alexey, all,
>
> Thank you very much for your reply and the pointers you provided.
>
> Honestly I don't mind whether the ico file is part of the exe or not. 
> It should just work as expected.
> Having said that, we are seeing issues that in some cases it doesn't 
> seem to work (i.e., not showing any icon).
>
> Let's hope this is an exception?
>
> Thanks,
>
> -- Daniel
>
>
>
> On Wed, Nov 6, 2024 at 7:04?PM Alexey Semenyuk 
> <alexey.semenyuk at oracle.com> wrote:
>
>     Hi Daniel,
>
>     On Windows, the jpackage embeds icons in app launcher executables and
>     there is no reason to keep these .ico files in the app image. In
>     [1], it
>     was reasonably requested not to include app launcher icons in the app
>     image on Windows, and that was fulfilled.
>
>     [1] https://bugs.openjdk.org/browse/JDK-8281682
>
>     - Alexey
>
>
>     On 11/6/2024 4:19 AM, Daniel Peintner wrote:
>     > Hello,
>     >
>     > I am not sure if this is the right place to ask, but I hope so.
>     > If not please let me know where I can report this kind of problem.
>     >
>     > Recently we changed from JDK 17 to JDK 21 and something seems to
>     have
>     > changed when running jpackage with --icon option.
>     >
>     > Produced structure on Windows for
>     >
>     > # Java 17
>     > /app
>     > /runtime
>     > foo.exe
>     > foo.ico
>     >
>     > while for
>     >
>     > # Java 21 (v 21.0.5)
>     > /app
>     > /runtime
>     > foo.exe
>     >
>     > As you can see the foo.ico is missing.
>     > Note: the foo.exe still shows the right icon when looking at it in
>     > FileExplorer.
>     >
>     > Anyhow, on some devices the missing ico file is causing issues.
>     > There is no icon on the program list nor in the taskbar (see
>     attached
>     > images).
>     >
>     > Note: On some windows installations it works without issues.
>     >
>     > Is this a known problem? I tried to browse through
>     > https://bugs.openjdk.org without finding such a bug report.
>     >
>     > Thanks for any input/advice.
>     >
>     > -- Daniel
>     >
>     >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241107/129a8da6/attachment-0001.htm>

From ihse at openjdk.org  Thu Nov  7 13:00:02 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 7 Nov 2024 13:00:02 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <VMSSoQiOvCT10eG-TxugJELfCwvPJGH5Ms4mEPsWpEk=.b2cc32e1-93dd-4626-9aaf-561a19255bac@github.com>

On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

@shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish.

Removing dead code like this is both a bit of an iterative process ("oh, now that we removed X, we can also remove Y"), and a bit of a judgement call ("now that `JNICALL` is not needed,we can remove it"). Sometimes it is not clear where to draw the line. Personally, I'm mostly interested in getting rid of all the junk in the build system; all the rest is just stuff I do as a "community service" to avoid having stuff laying around. (And I did it, under the (apparently na?ve) assumption that this would not require that much extra work :-), coupled with the (more cynical) assumption that if I did not do this, nothing would really happen on this front...)

I personally do think that removing the obsolete `_stdcall` is "provably, uncontroversially, visibly safe". But then again, it's not me who is going to have to chase the future bugs, so I respect your opinion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462174907

From sgehwolf at openjdk.org  Thu Nov  7 13:15:05 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 7 Nov 2024 13:15:05 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v45]
In-Reply-To: <Z42zmzw3iJObSLyQ46aE_h7kUTF4Vk_hsw5jWfxAsQk=.538364e9-4f89-40cd-a0fb-e93ef4e33c68@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
 <Z42zmzw3iJObSLyQ46aE_h7kUTF4Vk_hsw5jWfxAsQk=.538364e9-4f89-40cd-a0fb-e93ef4e33c68@github.com>
Message-ID: <vFV5P5ISQ56tGSc68oPpulybkG0n1Sz8ILs9cWscn5k=.926a60bd-b09e-4714-9ecf-a838226fff04@github.com>

On Thu, 7 Nov 2024 05:00:46 GMT, Mandy Chung <mchung at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 180 commits:
>> 
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Make capability in --help human readable
>>  - Fix comment
>>  - Fix SystemModulesTest2 when linkable runtime but no packaged modules
>>  - Rename PackagedModulesVsJmodLessTest => PackagedModulesVsRuntimeImageLinkTest
>>  - Rename JmodLess => runtimeImage
>>  - Refactor tests so that they run for default build
>>    
>>    When a default JDK build is being produced, the tests create a run-time
>>    image capable JDK as an interim step before everything else is being
>>    verified.
>>    
>>    For a build that has the run-time image link capability already turned
>>    on, this extra step is being omitted.
>>  - Mandy's feedback
>>  - Merge branch 'master' into jdk-8311302-jmodless-link
>>  - Some test fixes
>>  - ... and 170 more: https://git.openjdk.org/jdk/compare/83f3d42d...e83b9584
>
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/RuntimeImageLinkException.java line 45:
> 
>> 43:     public RuntimeImageLinkException(String file, Reason reason) {
>> 44:         this.file = file;
>> 45:         this.reason = reason;
> 
> Suggestion:
> 
>         this.file = Objects.requireNonNull(file);
>         this.reason = Objects.requireNonNull(reason);

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1832657318

From sgehwolf at openjdk.org  Thu Nov  7 13:27:41 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 7 Nov 2024 13:27:41 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with six additional commits since the last revision:

 - Mandy's feedback
 - Remove "jlink.runtime.linkable" property from VMProps
   
   It's no longer used in any tests.
 - Fix JLinkDedupTestBatchSizeOne.java
 - Fix plugins/IncludeLocalesPluginTest.java
   
   Similar to GenerateJLIClassesPluginTest.java, the default module path
   doesn't need to be explicitly specified.
 - Fix plugins/GenerateJLIClassesPluginTest.java test
   
   The test doesn't need the default module path and default jmods
   generated from the helper. Using this approach makes it work for
   linkable run-time images as well.
 - Simplify runtimeImage tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/e83b9584..f55bb853

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=45
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=44-45

  Stats: 479 lines in 24 files changed: 23 ins; 375 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sgehwolf at openjdk.org  Thu Nov  7 13:27:43 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 7 Nov 2024 13:27:43 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v45]
In-Reply-To: <Z42zmzw3iJObSLyQ46aE_h7kUTF4Vk_hsw5jWfxAsQk=.538364e9-4f89-40cd-a0fb-e93ef4e33c68@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <1RhnbiSN1S3VQJ-s6MaxCn-lxYq5fCUe1utRdKghf6U=.123eda16-45f0-4924-97d1-58077122c86a@github.com>
 <Z42zmzw3iJObSLyQ46aE_h7kUTF4Vk_hsw5jWfxAsQk=.538364e9-4f89-40cd-a0fb-e93ef4e33c68@github.com>
Message-ID: <V-n87RdwQn0QXU7w_LoOyC4ZE6VNWPzMXoiyU2PQFLE=.904f9872-eca6-4293-a911-611c4c3afaef@github.com>

On Thu, 7 Nov 2024 05:15:09 GMT, Mandy Chung <mchung at openjdk.org> wrote:

> For the test changes, I believe multiple `@test` tags to verify a JDK of linkable run-time image and another JDK with packaged modules are not necessary. Each test execution can only verify one JDK. The tests can keep one single `@test` and the main method has to determine the test JDK configuration for test verification.

Done in the latest update. Thanks again for the review!

> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JRTArchive.java line 132:
> 
>> 130:         } catch (RuntimeImageLinkException e) {
>> 131:             // populate modified files exception
>> 132:             throw e;
> 
> It's unchecked exception and this catch clause can be dropped.

Correct. Fixed.

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 126:
> 
>> 124: \ and cannot be used to create another image with the jdk.jlink module
>> 125: err.runtime.link.packaged.mods=This JDK has no packaged modules.\
>> 126: \ --keep-packaged-modules is not supported.
> 
> Suggestion:
> 
> err.runtime.link.packaged.mods=This JDK has no packaged modules.\
> \ --keep-packaged-modules is not supported

Thanks. Fixed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2462230045
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1832665852
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1832659096

From sgehwolf at openjdk.org  Thu Nov  7 13:27:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 7 Nov 2024 13:27:45 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v42]
In-Reply-To: <7zzFJwLb-7avQbBufmGg0PvYEPHc-ySXmcbg7sn6Xq8=.af0737b3-fac2-48dd-82fd-25d3dcb93e1d@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <Kp7JATx4ZWyym1WBbRYWe-1iHR4YDaDb8Q0gzbdG2_k=.becd0bda-9e12-4620-9e2a-a7328f93ff7f@github.com>
 <GeX-p8oPeUPnmtFX5WQh9IW_ZLcf86EgOjYgBkGSWyA=.50a46579-ba96-4a18-a168-e00ebd9190a1@github.com>
 <7zzFJwLb-7avQbBufmGg0PvYEPHc-ySXmcbg7sn6Xq8=.af0737b3-fac2-48dd-82fd-25d3dcb93e1d@github.com>
Message-ID: <JbXR3UvlkQNOZoP75soJuD92jVn3njIwioAU-K176JM=.664502a5-3e40-4c74-aa05-3c9d7fb9d1be@github.com>

On Tue, 5 Nov 2024 17:02:24 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jtreg-ext/requires/VMProps.java line 743:
>> 
>>> 741:         // jdk.jlink module has the following resource indicating a runtime-linkable
>>> 742:         // image. It's the diff file for runtime linking of the java.base module.
>>> 743:         String linkableRuntimeResource = "jdk/tools/jlink/internal/runtimelink/diff_java.base";
>> 
>> Can this access `LinkableRuntimeImage::DIFF_PATTERN` via qualified exports?
>
> I don't see how, but I may be missing something. `VMProps` isn't in any named module is it? Is it worth sprinkling `jdk.jlink`'s `module-info.java` classes with those exports for test-only purposes, though? Is there precedent that I can look at?
> 
> It appears this hard-coded resource seems the lesser of the two evils to me. Thoughts?

With the latest changes there is no `VMProps` extension to determine a run-time image link capable JDK anymore. So this is gone.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1832668508

From coleenp at openjdk.org  Thu Nov  7 13:34:50 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Nov 2024 13:34:50 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v8]
In-Reply-To: <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
Message-ID: <XD8qrmQwEjFWaTgTDsIbrDoFK0Qg3SBDvGzac7W0Y1o=.2c26584d-43ec-43b5-98be-877718a3c9db@github.com>

On Mon, 4 Nov 2024 23:57:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   @DanHeidinga comment -- exit VM when runtimeSetup() fails

I had a couple of drive by comments.

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.

If this is a new file, it shouldn't have 2022 in the copyright year.

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 81:

> 79:     }
> 80: 
> 81:     if (!k->is_instance_klass()) {

How can a field, interface or method cp reference point to a non-instance klass?  Or is this for a method in java.lang.Object, which can be an array klass ?  I doubt you should bother to support this special case.

src/hotspot/share/cds/aotConstantPoolResolver.cpp line 138:

> 136:     } else if (elem->is_typeArray_klass()) {
> 137:       return true;
> 138:     } else {

I think bottom_klass can only be InstanceKlass or typeArrayKlass, so else should be not possible and an assert.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2420951812
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832663874
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832668217
PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832674559

From coleenp at openjdk.org  Thu Nov  7 13:34:51 2024
From: coleenp at openjdk.org (Coleen Phillimore)
Date: Thu, 7 Nov 2024 13:34:51 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v8]
In-Reply-To: <XD8qrmQwEjFWaTgTDsIbrDoFK0Qg3SBDvGzac7W0Y1o=.2c26584d-43ec-43b5-98be-877718a3c9db@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <uJr36IfowVYruukRJvCLFpPbiQMU_BCgtBx6-ipvABU=.1fd0c51b-2530-487d-af00-3ebcfa8d0155@github.com>
 <XD8qrmQwEjFWaTgTDsIbrDoFK0Qg3SBDvGzac7W0Y1o=.2c26584d-43ec-43b5-98be-877718a3c9db@github.com>
Message-ID: <j_1w0mlnKHEXwNdRlCR5inUfY5PUhrfzP76JZ3KB4WY=.d8e0f2b2-f226-4e5e-ba58-adc5782201e4@github.com>

On Thu, 7 Nov 2024 13:16:19 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   @DanHeidinga comment -- exit VM when runtimeSetup() fails
>
> src/hotspot/share/cds/aotConstantPoolResolver.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2022, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> If this is a new file, it shouldn't have 2022 in the copyright year.

Oh looks like it's been moved from classPrelinker, except git doesn't show it's moved.  If it's added as a moved file, would there be less diffs to look at?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1832685160

From duke at openjdk.org  Thu Nov  7 13:48:02 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 7 Nov 2024 13:48:02 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg [v3]
In-Reply-To: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
Message-ID: <oWA2okRVfVjwsy6qW_1n0UK2TV0ROJgZ_h-otglPTTo=.a2adf0b6-7416-4379-966b-5fa99dc1c028@github.com>

> This change optimizes the runtime of `Class.getMethod(String, Class<?>[])` by reducing the cost of the existing search logic.  Specifically, while iterating across each Method to find a match (existing logic) it now compares parameter count before checking method name.  This check is substantially faster.
> 
> A benchmark and unit tests are included; benchmark results (below) show an improvement in all cases, and an especially large gain when the immediate class contains the no-arg target.
> 
> Base:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    94.586 ?  0.733  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    75.587 ? 11.300  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   215.794 ?  7.713  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   200.418 ?  4.352  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2207.928 ? 49.767  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   190.142 ?  1.995  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   153.943 ?  7.491  ns/op
> 
> 
> Modified:
> 
> Benchmark                          Mode  Cnt     Score    Error  Units
> ClassGetMethod.getConcreteFiveArg  avgt    6    94.409 ?  1.642  ns/op
> ClassGetMethod.getConcreteNoArg    avgt    6    77.748 ? 11.618  ns/op
> ClassGetMethod.getIntfFiveArg      avgt    6   193.816 ?  4.250  ns/op
> ClassGetMethod.getIntfNoArg        avgt    6   205.565 ?  9.140  ns/op
> ClassGetMethod.getNoSuchMethod     avgt   10  2231.248 ? 67.711  ns/op
> ClassGetMethod.getSuperFiveArg     avgt    6   169.971 ?  0.883  ns/op
> ClassGetMethod.getSuperNoArg       avgt    6   129.188 ?  8.421  ns/op

jengebr has updated the pull request incrementally with one additional commit since the last revision:

  Switching back to Array.equals() for parameter type comparison loop

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21929/files
  - new: https://git.openjdk.org/jdk/pull/21929/files/b0b63ecb..55f7e372

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21929&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21929&range=01-02

  Stats: 11 lines in 1 file changed: 0 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21929.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21929/head:pull/21929

PR: https://git.openjdk.org/jdk/pull/21929

From duke at openjdk.org  Thu Nov  7 13:48:02 2024
From: duke at openjdk.org (jengebr)
Date: Thu, 7 Nov 2024 13:48:02 GMT
Subject: RFR: 8343559: Optimize Class.getMethod(String,
 Class<?>...) for methods with no-arg [v3]
In-Reply-To: <CwDFv6ndMA23N5btyJhOoi0-CYjNJiSQudUZelFaG54=.d9b99093-d52e-42c8-8e3d-a21b15551266@github.com>
References: <kBazeJKFj5XxqW6Xl_dnC4_iUtveUaCs9D7308p6jBI=.5df22f8f-cd6e-4891-82de-fd85d69e3aa3@github.com>
 <pt49NbVGAEAAvGqIFu1BJD2fGxQKmgUFZjjrxdJm68E=.af7ff91c-21af-42c1-a06f-d4d8394259e8@github.com>
 <4ZT226VcGPQltW-uje_qA0bdntPigpCmwIUeNpckcfo=.194b18ca-0c8e-4299-85bd-b60708a91227@github.com>
 <fIHbESK8uBQ5rip0SXs8ELTdXyDYSV6QVgDVqCBQGHI=.1e04cfd4-3773-4388-b685-63ab1912c489@github.com>
 <CwDFv6ndMA23N5btyJhOoi0-CYjNJiSQudUZelFaG54=.d9b99093-d52e-42c8-8e3d-a21b15551266@github.com>
Message-ID: <7b0gxdLqQRn7qvBi-QJux-XUpGQUTMidg62RCW4VC3U=.9d70d62b-3176-4387-9d1f-813fd8edf534@github.com>

On Wed, 6 Nov 2024 17:35:36 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I don't like the style of a custom loop rather than `Arrays.equals()` but there is a perf benefit to it.  Curious what you think?
>
> Sure, moving param count ahead is fine.  Note that `Arrays.equals` is subject to profile pollution at runtime, so the benchmark results might not be applicable in practice.

@liach changes complete.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21929#discussion_r1832705057

From mcimadamore at openjdk.org  Thu Nov  7 14:01:42 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 14:01:42 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v2]
In-Reply-To: <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>
Message-ID: <7kV-EtrszbxJk8rD4Og8ErcLP7zy-a-ZgLim78KW77U=.06fc43c5-6d5b-4945-8422-24783d09d944@github.com>

On Wed, 6 Nov 2024 20:08:54 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is not issuing a mandated unchecked cast warning for code like:
>> 
>> 
>> import java.lang.invoke.VarHandle;
>> 
>> class VarHandleCast<V> {
>>      VarHandle vh;
>>      V method(Object obj) {
>>          return (V)vh.getAndSet(this, obj);
>>      }
>> }
>> 
>> 
>> according to the spec the return type inferred for this method polymorphic method should be Object see:
>> 
>> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
>> ...
>>     ? The compile-time result is determined as follows:
>>         Otherwise, if the method invocation expression is the operand of a cast
>>     expression (?15.16), the compile-time result is the erasure of the type of the
>>     cast expression (?4.6).
>> 
>> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
>> 
>> TIA
>> 
>> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug
>
> Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - fixing build error
>  - Merge branch 'master' into JDK-8343286
>  - fixing build error
>  - 8343286: Redundant cast in polymorphic method call

Changes look good. The extra suppress warnings seem to indicate that the logic is now working as intended :-)

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21914#pullrequestreview-2421062251

From jpai at openjdk.org  Thu Nov  7 14:16:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Nov 2024 14:16:36 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - update tests to match the new specification
 - Stuart's review - update the close() and end() expectations
 - Stuart's review - improve class level javadoc
 - merge latest from master branch
 - merge latest from master branch
 - Chen's suggestion - improve code comment
 - convert the tests to junit
 - fix whitespace
 - 8225763: Inflater and Deflater should implement AutoCloseable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19675/files
  - new: https://git.openjdk.org/jdk/pull/19675/files/4a52fe2b..c4e84dd4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=02-03

  Stats: 604975 lines in 6487 files changed: 434883 ins; 119223 del; 50869 mod
  Patch: https://git.openjdk.org/jdk/pull/19675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675

PR: https://git.openjdk.org/jdk/pull/19675

From rriggs at openjdk.org  Thu Nov  7 14:21:42 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Nov 2024 14:21:42 GMT
Subject: RFR: 8343293: Remove the check for <apphome>/jre/lib/libjava.dylib
 from the launcher's java_md_macosx.m [v2]
In-Reply-To: <jimrIPiksROK_-goTNbNi0HmPC2qGhiUmzRv6wfsmbI=.859344ce-f50a-420c-a7c6-bb1168a20ab2@github.com>
References: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
 <jimrIPiksROK_-goTNbNi0HmPC2qGhiUmzRv6wfsmbI=.859344ce-f50a-420c-a7c6-bb1168a20ab2@github.com>
Message-ID: <6czGJ3yPAPupEE-p7CG5BklMvF3cyJ1ceB3pluMYaa4=.6283c6de-6210-4bb9-b75e-ec8fd3f836df@github.com>

On Fri, 1 Nov 2024 14:51:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up a leftover code from the launcher's java_md_macosx.m file?
>> 
>> In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the launcher code to remove checks for  `<apphome>/jre/lib/` when determining the JDK installation root. Those changes were done in the Unix and Windows files and the macosx one got left out, likely due to an oversight.
>> 
>> The commit in this PR removes that leftover code. No new tests have been added and existing tier1, tier2, tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - introduce log message to match unix/windows

Thanks fro the extra logging.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21789#pullrequestreview-2421118301

From vromero at openjdk.org  Thu Nov  7 14:26:42 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 14:26:42 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v2]
In-Reply-To: <7kV-EtrszbxJk8rD4Og8ErcLP7zy-a-ZgLim78KW77U=.06fc43c5-6d5b-4945-8422-24783d09d944@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <GMeZKfu-dXDW2MQUu9BOMWqDHD8-znJEBbR8qETC-cs=.fa771733-6d5b-4c7a-8d82-be1e9a8e8811@github.com>
 <7kV-EtrszbxJk8rD4Og8ErcLP7zy-a-ZgLim78KW77U=.06fc43c5-6d5b-4945-8422-24783d09d944@github.com>
Message-ID: <u9v3SPpQETXZTeZQSfrH0IZ_2hUK0ODYaxILLL1uzBQ=.6ba1cf16-e3eb-40a8-9bba-107affb45429@github.com>

On Thu, 7 Nov 2024 13:59:03 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> Changes look good. The extra suppress warnings seem to indicate that the logic is now working as intended :-)

thanks for the review. As suggested above I created a CSR, could you please review it too? Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21914#issuecomment-2462367928

From qamai at openjdk.org  Thu Nov  7 14:35:10 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Thu, 7 Nov 2024 14:35:10 GMT
Subject: Integrated: 8343394: Make MemorySessionImpl.state a stable field
In-Reply-To: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
References: <hSHZb9ZCGHJ5n0dm0EDUZL3L7m6eLIIugjYuTR3sbwM=.535a52cf-356d-4721-9c90-c4b1a7c6ae39@github.com>
Message-ID: <SBYLI0Yeu_xjlUnjzT0fFaZJEtJ_l9l1-Magead4K18=.3b8c94e7-276f-4ba6-a48c-f5b72006b172@github.com>

On Thu, 31 Oct 2024 15:52:04 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch makes `MemorySessionImpl.state` a `Stable` field so that liveness check of non-closeable scopes such as the global scope can be elided.
> 
> Currently, the `state` field is overloaded with 2 responsibilities, to act as a communication device between `close` and `checkValidState`, as well as a communication device between `close`, `acquire`, and `release`. This patch separates those concerns into `state` and `acquireCount`, allowing `state` to be marked as `@Stable`.
> 
> With the patch, in `MemorySegmentGetUnsafe`, `panama` is able to be on par with `unsafe`:
> 
>     Benchmark                      Mode  Cnt  Score   Error  Units
>     MemorySegmentGetUnsafe.panama  avgt   30  0.340 ? 0.008  ns/op
>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.332 ? 0.004  ns/op
> 
> For reference this is the results without this patch:
> 
>     Benchmark                      Mode  Cnt  Score   Error  Units
>     MemorySegmentGetUnsafe.panama  avgt   30  0.420 ? 0.019  ns/op
>     MemorySegmentGetUnsafe.unsafe  avgt   30  0.329 ? 0.003  ns/op
> 
> Please kindly review, thanks very much.

This pull request has now been integrated.

Changeset: 1d117f65
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1d117f65f06456ae571aecc146542c2f79d402cf
Stats:     267 lines in 7 files changed: 224 ins; 17 del; 26 mod

8343394: Make MemorySessionImpl.state a stable field

Co-authored-by: Maurizio Cimadamore <mcimadamore at openjdk.org>
Reviewed-by: mcimadamore, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21810

From jpai at openjdk.org  Thu Nov  7 14:35:51 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Nov 2024 14:35:51 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
Message-ID: <vj3AMasgrCEhQ44zKAzQShNk3ANUGUVNDeOznCkNcJM=.cd02dd92-a66d-4f6b-9c7b-178e57954a24@github.com>

On Thu, 7 Nov 2024 14:16:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
>> 
>> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
>> 
>> To summarize those discussions, we had concluded that:
>> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
>> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
>> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
>> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
>> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
>> 
>> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
>> 
>> I'll file a CSR shortly.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - update tests to match the new specification
>  - Stuart's review - update the close() and end() expectations
>  - Stuart's review - improve class level javadoc
>  - merge latest from master branch
>  - merge latest from master branch
>  - Chen's suggestion - improve code comment
>  - convert the tests to junit
>  - fix whitespace
>  - 8225763: Inflater and Deflater should implement AutoCloseable

Thank you Stuart for your inputs.

> class specification
>
> I think the class specification needs to be clearer about the positioning of end() and close(). The end() method has done the real work of "closing" since the classes were introduced. We're retrofitting them to to have a close() method that's essentially just a synonym for end(), and it's still perfectly legal for clients and subclasses to call end() instead of close(). I think we need to say that close() is present mainly to support AutoCloseable and try-with-resources.

I've now updated the class level javadoc of both Inflater and Deflater to be more explicit on the purpose of close() method and how it relates to the end() method.


> end() specification
>
> I don't think that "may throw an exception" is strong enough. Also, on these classes (not subclasses) end() is idemopotent, isn't it? If so, this should be specified. The end() specs need to say something like, closes and releases resources, etc., henceforth operations will throw an exception (which? -- see below) but that subsequent calls to end() do nothing.

I've updated both the end() and close() method javadocs. It now states that end() is idempotent and at the same time states that calling several other methods on a closed Inflater/Deflater will throw a specific exception (noted below). I copied over the sentence which states "Several other methods defined..." from an existing Java SE API.


> Which exceptions on closed Deflater/Inflater?
>
> Oddly, it doesn't seem to be specified anywhere what exceptions are thrown if operations are attempted on a closed object. And the implementation actually throws NPE??!? Ideally we should specify what exception is thrown in this circumstance, but NPE seems wrong. Maybe we want to change the behavior to throw a different exception type. IllegalStateException seems like a reasonable candidate.

Yes, it is indeed odd that it's throwing a `NullPointerException` when ensuring the Inflater/Deflater is open. I have changed that part to throw an `IllegalStateException` and make a mention of this exception in the end() method specification. Clearly, changing `NullPointerException` to `IllegalStateException` is a change in behaviour of public APIs and ideally should be done separately. But, given the context that it gets thrown only from an instance that's already closed (and thus of no real use), I think the chances of this change severly impacting applications is very limited. So, in my opinion, it's perhaps OK to include this change of exception type as part of this change and have it recorded through the same CSR that we use for this current enhancement. Do let me know if we should do that change separately.

> close() specification
>
> The 2019 discussion kind of assumed that we want close() to be idempotent. I'm not sure this is necessary. Alan said the implementation might need to be "heroic" but Peter Levart's arrangement (carried through here, apparently) isn't terribly bad. And @liach suggests more comments on this code, quite reasonably... but the comment begs the question, why do we need to avoid calling end() more than once? I'm rethinking the need for close() to be idempotent. Maybe close() should simply call end(). It would simplify the implementation and the specs -- the implSpec would simply say that it calls the end() method.

I ran various corpus experiments. Based on that what I have noticed is that, in that corpus, there are extremely few (less than 10) classes which override end() of either the Inflater or Deflater class. Furthermore, all these implementations have implemented their end() in a manner that calling it more than once will act as a no-op for subsequent invocations. So I think, like you note, we should just specify that close() calls end() and stop trying to prevent end() being called more than once. Given this, I've now updated the PR to do just that and also updated the new tests to match this specification updates.

tier testing is currently in progress for this current state of the PR. If the current state of the PR looks reasonable, then I'll focus on the CSR text for these changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19675#issuecomment-2462388705

From rriggs at openjdk.org  Thu Nov  7 14:38:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Nov 2024 14:38:59 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
Message-ID: <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>

On Thu, 7 Nov 2024 14:16:36 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
>> 
>> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
>> 
>> To summarize those discussions, we had concluded that:
>> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
>> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
>> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
>> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
>> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
>> 
>> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
>> 
>> I'll file a CSR shortly.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - update tests to match the new specification
>  - Stuart's review - update the close() and end() expectations
>  - Stuart's review - improve class level javadoc
>  - merge latest from master branch
>  - merge latest from master branch
>  - Chen's suggestion - improve code comment
>  - convert the tests to junit
>  - fix whitespace
>  - 8225763: Inflater and Deflater should implement AutoCloseable

src/java.base/share/classes/java/util/zip/Deflater.java line 902:

> 900:      */
> 901:     @Override
> 902:     public void close() {

Can/should this method be final?  The real/original cleanup method is `end` and if both `close()` and `end()` are overriddable, there may be some confusion about which to implement.

src/java.base/share/classes/java/util/zip/Inflater.java line 719:

> 717:      */
> 718:     @Override
> 719:     public void close() {

Ditto, should this be `final` to be clear about what should be overridden to perform cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1832777080
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1832787363

From rriggs at openjdk.org  Thu Nov  7 14:41:49 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 7 Nov 2024 14:41:49 GMT
Subject: RFR: 8343396: Use OperatingSystem, Architecture,
 and OSVersion in jpackage tests
In-Reply-To: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
References: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
Message-ID: <J-ee24vOClMnRuoCRjJ5_v2QP1IavPTz4ICXrv3pO6k=.4670af08-eff9-4646-804b-d5976aba7130@github.com>

On Wed, 6 Nov 2024 21:42:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use internal jdk API instead of parsing JVM properties where appropriate in jpackage tests

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21940#pullrequestreview-2421175432

From jpai at openjdk.org  Thu Nov  7 14:46:50 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Nov 2024 14:46:50 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
 <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
Message-ID: <HaROiuwLaPbPqU0yCkjrF_sErOyFu9SmyJ2Kz7mq1rw=.5dcd201b-6fe4-4c2b-a4c1-d9598bbdf641@github.com>

On Thu, 7 Nov 2024 14:28:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - update tests to match the new specification
>>  - Stuart's review - update the close() and end() expectations
>>  - Stuart's review - improve class level javadoc
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - Chen's suggestion - improve code comment
>>  - convert the tests to junit
>>  - fix whitespace
>>  - 8225763: Inflater and Deflater should implement AutoCloseable
>
> src/java.base/share/classes/java/util/zip/Deflater.java line 902:
> 
>> 900:      */
>> 901:     @Override
>> 902:     public void close() {
> 
> Can/should this method be final?  The real/original cleanup method is `end` and if both `close()` and `end()` are overriddable, there may be some confusion about which to implement.

Hello Roger, I think that's a good idea. At least until there is a real reason for `close()` to be overridden by subclasses. I went back and checked the mailing list discussions (linked in this PR description) and I don't think marking `close()` as `final` has been suggested or rejected before. I will give others a chance to provide their inputs before I do this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1832803053

From daniel.peintner at gmail.com  Thu Nov  7 14:53:15 2024
From: daniel.peintner at gmail.com (Daniel Peintner)
Date: Thu, 7 Nov 2024 15:53:15 +0100
Subject: [External] : Re: [jpackage] Changes to icon handling between Java
 17 and Java 21 on Windows
In-Reply-To: <6983407a-0127-4397-bb9f-4dfd0b0f1bcf@oracle.com>
References: <CAAoP7T6SPwhxKUxsFG91Of5hWdBugTw9uJzev1DoM-s1MbKSRA@mail.gmail.com>
 <d28f07fb-f642-487b-beae-4f2cfbbf711b@oracle.com>
 <CAAoP7T5+5KgYeg1dWNBb0N0pbw0=nOvv5a1e5j=BLNvKhuNsGw@mail.gmail.com>
 <6983407a-0127-4397-bb9f-4dfd0b0f1bcf@oracle.com>
Message-ID: <CAAoP7T4XoW5jovUy-fbV58+wZhcr5L=fqA7XK-JDfoR+5pOuWQ@mail.gmail.com>

Hi Alexey,

However, I find it suspicious that other app icons are OK on your
> screenshots and only an icon of the package-created app is blank. If you
> have a reproducible example, please file a bug!
>

I have tried the *same* msi installer on 3 windows machines and only one
shows no app icon.
Hence, I don't really have a reproducible example. If I manage to generate
one I will file a bug and come back to you.

Thank you!

-- Daniel




> - Alexey
>
> On 11/7/2024 3:43 AM, Daniel Peintner wrote:
>
> Hi Alexey, all,
>
> Thank you very much for your reply and the pointers you provided.
>
> Honestly I don't mind whether the ico file is part of the exe or not. It
> should just work as expected.
> Having said that, we are seeing issues that in some cases it doesn't seem
> to work (i.e., not showing any icon).
>
> Let's hope this is an exception?
>
> Thanks,
>
> -- Daniel
>
>
>
> On Wed, Nov 6, 2024 at 7:04?PM Alexey Semenyuk <alexey.semenyuk at oracle.com>
> wrote:
>
>> Hi Daniel,
>>
>> On Windows, the jpackage embeds icons in app launcher executables and
>> there is no reason to keep these .ico files in the app image. In [1], it
>> was reasonably requested not to include app launcher icons in the app
>> image on Windows, and that was fulfilled.
>>
>> [1] https://bugs.openjdk.org/browse/JDK-8281682
>>
>> - Alexey
>>
>>
>> On 11/6/2024 4:19 AM, Daniel Peintner wrote:
>> > Hello,
>> >
>> > I am not sure if this is the right place to ask, but I hope so.
>> > If not please let me know where I can report this kind of problem.
>> >
>> > Recently we changed from JDK 17 to JDK 21 and something seems to have
>> > changed when running jpackage with --icon option.
>> >
>> > Produced structure on Windows for
>> >
>> > # Java 17
>> > /app
>> > /runtime
>> > foo.exe
>> > foo.ico
>> >
>> > while for
>> >
>> > # Java 21 (v 21.0.5)
>> > /app
>> > /runtime
>> > foo.exe
>> >
>> > As you can see the foo.ico is missing.
>> > Note: the foo.exe still shows the right icon when looking at it in
>> > FileExplorer.
>> >
>> > Anyhow, on some devices the missing ico file is causing issues.
>> > There is no icon on the program list nor in the taskbar (see attached
>> > images).
>> >
>> > Note: On some windows installations it works without issues.
>> >
>> > Is this a known problem? I tried to browse through
>> > https://bugs.openjdk.org without finding such a bug report.
>> >
>> > Thanks for any input/advice.
>> >
>> > -- Daniel
>> >
>> >
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241107/2813bd9a/attachment-0001.htm>

From stuefe at openjdk.org  Thu Nov  7 15:28:05 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Thu, 7 Nov 2024 15:28:05 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <6qzIK_QQ2Rs5deO4jIyicr7ob4CZCg7ajBnbEd9vCFU=.6fc95a24-9f01-4e61-bb21-442720c53437@github.com>

On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

@shipilev @magicus Okay but where do we draw the line? Because then we also need to keep the code that takes care of x86 calling convention name mangling.

[Microsoft states](https://learn.microsoft.com/en-us/cpp/cpp/stdcall?view=msvc-170) "On ARM and x64 processors, __stdcall is accepted and *ignored by the compiler*; on ARM and x64 architectures, by convention, arguments are passed in registers 
when possible, and subsequent arguments are passed on the stack."

Similar statements can be found in the MSDN documentation for __cdecl and __fastcall.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462517302

From mcimadamore at openjdk.org  Thu Nov  7 15:29:58 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 15:29:58 GMT
Subject: RFR: 8343770: Build fails due to use of sun.misc.Unsafe in
 LoopOverRandom
Message-ID: <u9UMXf_RcfgLBYD5DqDQl0gGIPSHmdImGaJHCUfedG8=.7cbb990e-fb2b-42d3-896a-2301536abe69@github.com>

This small PR fixes a build failure due to usage of sun.misc.Unsafe in a new benchmark.

FFM benchmarks appear to be broken -- because of JDK-8332744 -- but we will fix that separately.

-------------

Commit messages:
 - Initial push

Changes: https://git.openjdk.org/jdk/pull/21958/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21958&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343770
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21958.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21958/head:pull/21958

PR: https://git.openjdk.org/jdk/pull/21958

From alanb at openjdk.org  Thu Nov  7 15:29:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Nov 2024 15:29:58 GMT
Subject: RFR: 8343770: Build fails due to use of sun.misc.Unsafe in
 LoopOverRandom
In-Reply-To: <u9UMXf_RcfgLBYD5DqDQl0gGIPSHmdImGaJHCUfedG8=.7cbb990e-fb2b-42d3-896a-2301536abe69@github.com>
References: <u9UMXf_RcfgLBYD5DqDQl0gGIPSHmdImGaJHCUfedG8=.7cbb990e-fb2b-42d3-896a-2301536abe69@github.com>
Message-ID: <xDgs5ktYzm4cdA1PFu2dGD4QuCYIRd4qJuKTr2HvsEU=.cbc5ba46-2afd-438b-91fa-ed12b0b4661d@github.com>

On Thu, 7 Nov 2024 15:12:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This small PR fixes a build failure due to usage of sun.misc.Unsafe in a new benchmark.
> 
> FFM benchmarks appear to be broken -- because of JDK-8332744 -- but we will fix that separately.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21958#pullrequestreview-2421275027

From jpai at openjdk.org  Thu Nov  7 15:30:33 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 7 Nov 2024 15:30:33 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v4]
In-Reply-To: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
Message-ID: <x0KtumUt8LRIQuhT5u4l4GVTIJfqNj-dlkeGLnVqov8=.a86f7e51-1ffe-4f79-a401-1dc1e629ac53@github.com>

> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
> 
> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
> 
> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - 8341184: Clean up the interaction between the launcher native code and the LauncherHelper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21256/files
  - new: https://git.openjdk.org/jdk/pull/21256/files/3993eca5..45f1b33c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=02-03

  Stats: 136881 lines in 846 files changed: 106790 ins; 10786 del; 19305 mod
  Patch: https://git.openjdk.org/jdk/pull/21256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256

PR: https://git.openjdk.org/jdk/pull/21256

From vromero at openjdk.org  Thu Nov  7 15:31:10 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Thu, 7 Nov 2024 15:31:10 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v3]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <ILALv3qFqzV2al0VAAiylmg9c99cPehLQOxdEXCyAOE=.0130eeff-5828-46c3-8e41-78d1a360f1ff@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - 8343286: Redundant cast in polymorphic method call

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/34b5b020..5bfcf8ef

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=01-02

  Stats: 996 lines in 62 files changed: 572 ins; 306 del; 118 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

PR: https://git.openjdk.org/jdk/pull/21914

From mcimadamore at openjdk.org  Thu Nov  7 15:33:47 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 7 Nov 2024 15:33:47 GMT
Subject: Integrated: 8343770: Build fails due to use of sun.misc.Unsafe in
 LoopOverRandom
In-Reply-To: <u9UMXf_RcfgLBYD5DqDQl0gGIPSHmdImGaJHCUfedG8=.7cbb990e-fb2b-42d3-896a-2301536abe69@github.com>
References: <u9UMXf_RcfgLBYD5DqDQl0gGIPSHmdImGaJHCUfedG8=.7cbb990e-fb2b-42d3-896a-2301536abe69@github.com>
Message-ID: <bbrBI8Ia5O9oRV_9JMssM1nqqwQ6dYeMIM_ta5pe6G4=.46e8a985-0f84-4596-9df1-651441cdfd9a@github.com>

On Thu, 7 Nov 2024 15:12:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This small PR fixes a build failure due to usage of sun.misc.Unsafe in a new benchmark.
> 
> FFM benchmarks appear to be broken -- because of JDK-8332744 -- but we will fix that separately.

This pull request has now been integrated.

Changeset: d3c042f9
Author:    Maurizio Cimadamore <mcimadamore at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d3c042f9a0cd91e7cdf7f45cb0ea387f7ba9785b
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8343770: Build fails due to use of sun.misc.Unsafe in LoopOverRandom

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21958

From bpb at openjdk.org  Thu Nov  7 16:23:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 7 Nov 2024 16:23:44 GMT
Subject: RFR: 8343293: Remove the check for <apphome>/jre/lib/libjava.dylib
 from the launcher's java_md_macosx.m [v2]
In-Reply-To: <jimrIPiksROK_-goTNbNi0HmPC2qGhiUmzRv6wfsmbI=.859344ce-f50a-420c-a7c6-bb1168a20ab2@github.com>
References: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
 <jimrIPiksROK_-goTNbNi0HmPC2qGhiUmzRv6wfsmbI=.859344ce-f50a-420c-a7c6-bb1168a20ab2@github.com>
Message-ID: <q9JbBfLhizYuSbplfqoVZJqsqo9LFOW4bihU1L9l4Lk=.a511a9aa-32ee-44b3-9117-1a00116fc5bb@github.com>

On Fri, 1 Nov 2024 14:51:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up a leftover code from the launcher's java_md_macosx.m file?
>> 
>> In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the launcher code to remove checks for  `<apphome>/jre/lib/` when determining the JDK installation root. Those changes were done in the Unix and Windows files and the macosx one got left out, likely due to an oversight.
>> 
>> The commit in this PR removes that leftover code. No new tests have been added and existing tier1, tier2, tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - introduce log message to match unix/windows

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21789#pullrequestreview-2421491741

From vaivanov at openjdk.org  Thu Nov  7 16:42:55 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 7 Nov 2024 16:42:55 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v2]
In-Reply-To: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
Message-ID: <0uxIktvIJM7t6QIhBoB3Tx5paMdtYBwCC3_lc4PAAzM=.2f817c59-a1f1-4e23-871a-cfc5782d6ea3@github.com>

> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
> Unit tests was not affected:
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp                                     516   516     0     0
>    jtreg:test/jdk/javax/xml                             70    70     0     0
> ==============================
> TEST SUCCESS
> 
> The tier1 is OK too.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  8317542: Specjvm::xml have scalability issue for high vCPU numbers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21815/files
  - new: https://git.openjdk.org/jdk/pull/21815/files/b6894386..6bf932ab

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21815&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21815&range=00-01

  Stats: 19 lines in 1 file changed: 1 ins; 15 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21815/head:pull/21815

PR: https://git.openjdk.org/jdk/pull/21815

From alanb at openjdk.org  Thu Nov  7 16:56:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 7 Nov 2024 16:56:44 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v2]
In-Reply-To: <0uxIktvIJM7t6QIhBoB3Tx5paMdtYBwCC3_lc4PAAzM=.2f817c59-a1f1-4e23-871a-cfc5782d6ea3@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
 <0uxIktvIJM7t6QIhBoB3Tx5paMdtYBwCC3_lc4PAAzM=.2f817c59-a1f1-4e23-871a-cfc5782d6ea3@github.com>
Message-ID: <9zoGTdvRlbWXkdm1xgJ4PRmQAwVV4oYMMiY1U0iByTY=.7e4ca268-3d46-492e-bf44-7ff1a3ea0277@github.com>

On Thu, 7 Nov 2024 16:42:55 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
>> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
>> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
>> Unit tests was not affected:
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp                                     516   516     0     0
>>    jtreg:test/jdk/javax/xml                             70    70     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> The tier1 is OK too.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317542: Specjvm::xml have scalability issue for high vCPU numbers

src/java.xml/share/classes/com/sun/org/apache/xerces/internal/impl/xpath/regex/RegularExpression.java line 2019:

> 2017:         int length;
> 2018:         Match match;
> 2019:         private Semaphore inuse = new Semaphore(1, true);

Does it require fairness? The existing code using object monitors so I assume not. I assume "inuse" can be final.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21815#discussion_r1833031188

From sgehwolf at openjdk.org  Thu Nov  7 17:15:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 7 Nov 2024 17:15:11 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
Message-ID: <v5nzFt3URCw3-qQI2wO47xVzbjPwXGfDNGAd-YhJJFI=.b38d3077-f2fc-4282-a76e-881f99384dc8@github.com>

On Thu, 7 Nov 2024 13:27:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Mandy's feedback
>  - Remove "jlink.runtime.linkable" property from VMProps
>    
>    It's no longer used in any tests.
>  - Fix JLinkDedupTestBatchSizeOne.java
>  - Fix plugins/IncludeLocalesPluginTest.java
>    
>    Similar to GenerateJLIClassesPluginTest.java, the default module path
>    doesn't need to be explicitly specified.
>  - Fix plugins/GenerateJLIClassesPluginTest.java test
>    
>    The test doesn't need the default module path and default jmods
>    generated from the helper. Using this approach makes it work for
>    linkable run-time images as well.
>  - Simplify runtimeImage tests

GHA failure on aarch64 MacOSX is infra related.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2462796078

From joehw at openjdk.org  Thu Nov  7 18:04:43 2024
From: joehw at openjdk.org (Joe Wang)
Date: Thu, 7 Nov 2024 18:04:43 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v2]
In-Reply-To: <0uxIktvIJM7t6QIhBoB3Tx5paMdtYBwCC3_lc4PAAzM=.2f817c59-a1f1-4e23-871a-cfc5782d6ea3@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
 <0uxIktvIJM7t6QIhBoB3Tx5paMdtYBwCC3_lc4PAAzM=.2f817c59-a1f1-4e23-871a-cfc5782d6ea3@github.com>
Message-ID: <lCYcbBBYNdgtf8H8Wads4xNvjtN_GT6pEfjXYpS-UFo=.bbcaf4d3-2646-4007-a25e-7f4d47810e1d@github.com>

On Thu, 7 Nov 2024 16:42:55 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
>> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
>> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
>> Unit tests was not affected:
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp                                     516   516     0     0
>>    jtreg:test/jdk/javax/xml                             70    70     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> The tier1 is OK too.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317542: Specjvm::xml have scalability issue for high vCPU numbers

Nice improvement on specjvm2008::xml.validation. Would you be willing to take a look at specjvm2008::xml.transform? I wonder if similar issue exists there with high vCPUs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2462898340

From vaivanov at openjdk.org  Thu Nov  7 18:30:22 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 7 Nov 2024 18:30:22 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v3]
In-Reply-To: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
Message-ID: <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>

> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
> Unit tests was not affected:
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp                                     516   516     0     0
>    jtreg:test/jdk/javax/xml                             70    70     0     0
> ==============================
> TEST SUCCESS
> 
> The tier1 is OK too.

Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:

  8317542: Specjvm::xml have scalability issue for high vCPU numbers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21815/files
  - new: https://git.openjdk.org/jdk/pull/21815/files/6bf932ab..d9da6501

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21815&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21815&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21815.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21815/head:pull/21815

PR: https://git.openjdk.org/jdk/pull/21815

From sspitsyn at openjdk.org  Thu Nov  7 18:33:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:33:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
Message-ID: <RGAabYiTSOR77XDt_hdE_eTifrzPya410sFk8nrcI8M=.84db63f4-dcaf-4f41-862c-19da134eaa65@github.com>

On Thu, 7 Nov 2024 00:38:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount

Thank you for updates! Looks good.
Overall, it is a great job!

test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104:

> 102: 
> 103:     err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr);
> 104:     check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call");

Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here.
Also, the `methodName` is better to deallocate with the `deallocate() function.
The same is in the `VirtualThreadMount` callback.

-------------

Marked as reviewed by sspitsyn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2421828032
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833167652

From sspitsyn at openjdk.org  Thu Nov  7 18:33:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:33:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <kEcDoawSPu6W5TMBXMcjhhwHWDdYjoaYJahRCySSs9E=.4111eada-1ef0-4183-92cc-fb17ab60bce2@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <P2oWH67vhW4zQI9TrsgoypXJnbzI-GtisDxrszx19pE=.882e27cd-1b83-4223-9001-d3533f254d0c@github.com>
 <Y5Hb5U8gpJq2zNsvS9P2IytvnQhqEuf_SIO1pidYirU=.807d157b-a943-4c4c-8e66-6ee671da53d6@github.com>
 <O-OmjOUIK-kIlWNvPJlmELKfxQCwcOrzEQdj_3S10i4=.5976d73a-599c-4be5-96c2-35c54c53d88a@github.com>
 <lMU4CmV9RLKTe6WGxTH3Gwq2Qff0p8q7vdJF7AzZbDA=.584ccf05-be0e-4933-a19b-f88dec771118@github.com>
 <kEcDoawSPu6W5TMBXMcjhhwHWDdYjoaYJahRCySSs9E=.4111eada-1ef0-4183-92cc-fb17ab60bce2@github.com>
Message-ID: <EyOSVALfmNhRf93TufYKRwteCZIMRF6ugR6FlXYIhFA=.9ab87aa9-ec41-46bd-aaf3-65b634b1aa51@github.com>

On Thu, 7 Nov 2024 00:38:57 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> the call to java_lang_Thread::set_is_in_VTMS_transition()is not needed in JvmtiUnmountBeginMark
>>>
>> Why is not needed? I guess you meant to say we should use `JvmtiVTMSTransitionDisabler::set_is_in_VTMS_transition()` which does both?
>
>> the function is_vthread_safe_to_preempt() does not need the vthread parameter
>> 
> Removed.

Thank you for the update! It looks okay to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833168776

From sspitsyn at openjdk.org  Thu Nov  7 18:33:14 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:33:14 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <KNNb7KhND4tZMWszIkbfg4rp85tUCTvgr2uJbyg2N6k=.7060edbb-9877-41cd-8dab-3d1a1fef340e@github.com>
 <aD_QQx3vxn1PLlv1UV7mZHqwnWEaFGqA42CbeXOr0gI=.fd1b98c5-1ced-4046-8a9f-5eb971cc73f9@github.com>
 <Tm80aafeRBpMXDRrpLC4lC5aNpDIOnwsl6mcQNyiaJM=.bdaea9f0-032e-46c0-aa7a-80fc087cbe21@github.com>
 <IodEreNrG3hhE_q2TV0ZJ5lzDo2R_Cn853SYCNaupcU=.1f6b1c5b-f8c3-46c4-a57b-b3d238fb4ce9@github.com>
 <TJkuhNXYTZOYJhOgcCCFoRmk94jGe6_6-CU0-fWIPNc=.9384ada1-978f-4955-8216-82dcebdddb9c@github.com>
 <5ZFkpNRHw-d5qP3ggPI41D6Z5Em7HyjLy-0kt3JX_u8=.7ffe4080-8792-43ba-a67b-b43098417019@github.com>
Message-ID: <8fsvkr2uAamrF-VvR5mNHGF4NF_FJkgMDzxLeVh1wNs=.54597efe-cc91-426d-ae86-f13d20a1f889@github.com>

On Thu, 7 Nov 2024 00:40:26 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>>> So at some point I think we need to figure out how to make them go away  ...
>> 
>> Yes, the 2 extension events (`VirtualThreadMount` and `VirtualThreadUnmount`) were added for testing purposes. We wanted to get rid of them at some point but the Graal team was using them for some purposes.
>> 
>>> It's posted before. We post the mount event at the end of thaw only if we are able to acquire the monitor...
>> 
>> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior needs to be considered as a bug. My understanding is that it is not easy to fix. We most likely, we have no tests to fail because of this though.
>> 
>>> That's the path a virtual thread will take if pinned. 
>> 
>> Got it, thanks. I realize it is because we do not thaw and freeze the VM frames. It is not easy to comprehend.
>
>> The two extension events were designed to be posted when the current thread identity is virtual, so this behavior > needs to be considered as a bug. My understanding is that it is not easy to fix.
>>
> If we want to post the mount/unmount events here is actually simple if we also use `JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount`. I included it in the last commit.

Thank you for the explanations and update. The update looks okay.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833171024

From vaivanov at openjdk.org  Thu Nov  7 18:33:47 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 7 Nov 2024 18:33:47 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v3]
In-Reply-To: <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
 <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
Message-ID: <kcuX2SPYLS8HHPGJaGZ7Ds8bmWE_zssZIJ1eH9X-IfM=.24399277-2028-4e81-ba5f-b63c9ce7d6e5@github.com>

On Thu, 7 Nov 2024 18:30:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
>> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
>> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
>> Unit tests was not affected:
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp                                     516   516     0     0
>>    jtreg:test/jdk/javax/xml                             70    70     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> The tier1 is OK too.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317542: Specjvm::xml have scalability issue for high vCPU numbers

Test is OK (tier1/jaxp/jdk/javax/xml). Scores for xml.validation are:
original: 1thread - 415.06; 16 - 5744.1; 32 - 10491.05; 112 - 17391.39 ops/m
patched: 1 thread - 413.08; 16 - 5844.66; 32 - 10788.12;112 - 21480.43 ops/m
Runs for xml.transform started.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2462950503

From schernyshev at openjdk.org  Thu Nov  7 18:35:01 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 7 Nov 2024 18:35:01 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v2]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <c9ears00mDgdw6ZVG4Y28ihDRyWFBM7ufs55gbOR9jU=.7dfe22f7-1c32-4528-b527-956bdf8237d1@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with two additional commits since the last revision:

 - patch reimplemented
 - fix the logic that skips duplicate controller's mount points

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/c1c75896..6a761ca2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=00-01

  Stats: 125 lines in 10 files changed: 3 ins; 75 del; 47 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From sgehwolf at openjdk.org  Thu Nov  7 18:35:01 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 7 Nov 2024 18:35:01 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <oWCDSLAltHOV8n0QmPtEyeeZHBvN12-DZrqeKhzBql8=.e8c63755-19f1-4c2f-96d3-2df71b6676b2@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <oWCDSLAltHOV8n0QmPtEyeeZHBvN12-DZrqeKhzBql8=.e8c63755-19f1-4c2f-96d3-2df71b6676b2@github.com>
Message-ID: <vzBgYigOjSloZvvTAgXDxNZB9Ui_xPxCergSv--Tu1c=.90a64179-44c1-47c4-984c-41c517f2d315@github.com>

On Fri, 1 Nov 2024 13:13:07 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> As they're in fact mounting read-write, the logic picked up `rw` mount option and falsely detected "host mode". Also the `--privileged` creates `rw` mounts, so the entire approach needs correction.

Yes. See https://bugs.openjdk.org/browse/JDK-8261242 for details. This patch shouldn't change it and the logic of `OSContainer::is_containerized()` shouldn't change semantically in all scenarios.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2454229684

From schernyshev at openjdk.org  Thu Nov  7 18:35:01 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 7 Nov 2024 18:35:01 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <fAhfiQBSc7J2VaTEK1tu8_Il0EOCaxp9-fCV_36f9Co=.6dcb0be9-55d6-4520-b8aa-40b768591a99@github.com>

On Thu, 31 Oct 2024 15:00:25 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Here's an updated version of the patch. The long standing behavior was to leave `_path` uninitialized when `_root` is not "`/`" and not equal to `cgroup_path`. The issue can be reproduced as follows.

Create a new cgroup for memory

sudo mkdir -p /sys/fs/cgroup/memory/test


Run the following script

docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \
    sh -c "sleep 10 ; /jdk/bin/java -Xlog:os+container=trace -version" | grep Memory\ Limit &
sleep 10
HOSTPID=$(sudo ps -ef | awk '/container=trace/ && !/docker/ && !/awk/ { print $2 }')
echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs
sleep 10

In the above script, a containerized process (`/bin/sh`) is moved to cgroup `/test` before `/jdk/bin/java` gets executed. Java inherits cgroup `/test` from its parent process, its `_root` will be `/docker/<CONTAINER_ID>`, `cgroup_path` will be `/test`.


The result would be ($JAVA_HOME points to JDK before fix)

9804
[0.001s][trace][os,container] Memory Limit failed: -2
[0.001s][trace][os,container] Memory Limit failed: -2
[0.002s][trace][os,container] Memory Limit failed: -2
[0.043s][trace][os,container] Memory Limit failed: -2


JDK updated version:

10001
[0.001s][trace  ][os,container] Memory Limit is: 419430400
[0.001s][trace  ][os,container] Memory Limit is: 419430400
[0.002s][trace  ][os,container] Memory Limit is: 419430400
[0.035s][trace  ][os,container] Memory Limit is: 419430400

The updated version falls back to the mount point (only when `_root` is other than `"/"`).

**Testing**

- Standard tiers (1-3)
- jtreg:test/jdk/jdk/internal/platform
- jtreg:test/hotspot/jtreg/containers
- gtest:cgroupTest

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2462243544

From sspitsyn at openjdk.org  Thu Nov  7 18:38:07 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Thu, 7 Nov 2024 18:38:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
Message-ID: <uGEajP0tBBwAauSp584HWlT9pphV9N1NhLR3cvw1XIo=.cf2e196f-abf0-42e9-a396-83d3b23acd65@github.com>

On Thu, 7 Nov 2024 00:38:18 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount

src/hotspot/share/prims/jvmtiThreadState.cpp line 2:

> 1: /*
> 2:  * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved.

Nit: No need in the copyright update anymore.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833174843

From kbarrett at openjdk.org  Thu Nov  7 18:42:02 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Thu, 7 Nov 2024 18:42:02 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <3Rg6yosMIl2HdD2FNR-dPM8dSWZiIS3irKW0uOxNnh8=.91ba8741-d3fb-4ecd-9651-325d4f06f9ca@github.com>

On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

> @shipilev Sure, I can revert the `_stdcall` changes from here and put them in a a separate PR. Kim also expressed a similar wish.

To be clear, I wished it had been done as a separate followup, but reviewed it here all the same, in the interest of
limiting review and testing churn.  If you back it out, that will be more churn that I don't think is particularly
beneficial.  I'll go along with whatever @magicus and @shipilev and @tstuefe decide to do about it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2462963330

From joe.darcy at oracle.com  Thu Nov  7 18:46:21 2024
From: joe.darcy at oracle.com (Joseph D. Darcy)
Date: Thu, 7 Nov 2024 10:46:21 -0800
Subject: RFD: "equal" vs "equivalent" in Float.NaN, Double.NaN
In-Reply-To: <CA+pBWht9w+eLn2Heeqp1fPPNn_tNiFEh6n=Ytaa+7u4Oyno5Fw@mail.gmail.com>
References: <CA+pBWhsBx5_h0mfu_Q8ZMf35L6hQyvcHseYc-c38h7ra_ZtSSA@mail.gmail.com>
 <a7abef5e-43d4-4f8d-a807-56190d481457@oracle.com>
 <CA+pBWht9w+eLn2Heeqp1fPPNn_tNiFEh6n=Ytaa+7u4Oyno5Fw@mail.gmail.com>
Message-ID: <8252b030-b8ec-47a4-bbc8-3d1a49e69129@oracle.com>


On 11/1/2024 1:19 PM, Eirik Bj?rsn?s wrote:
> On Fri, Nov 1, 2024 at 8:42?PM Joseph D. Darcy <joe.darcy at oracle.com> 
> wrote:
>
>     A few releases back, a discussion of "quality, equivalence, and
>     comparison of floating-point values" was added to java.lang.Double:
>
>     https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/Double.html#equivalenceRelation
>
>     That note discusses the topics in question.
>
> Thanks Joe, that's exactly what I was missing. Saying "equivalent to" 
> without defining the equivalence relation seems to leave room for 
> confusion.
>
> I see the API note of Float/Double::equals link to this note. Do you 
> think it would be useful / worthwhile to add a?@linkplain from the NaN 
> descriptions as well, like this?
>
> ? ? ?/**
> ? ? ? * A constant holding a Not-a-Number (NaN) value of type
> - ? ? * {@code float}.? It is equivalent to the value returned by
> - ? ? * {@code Float.intBitsToFloat(0x7fc00000)}.
> + ? ? * {@code float}.? It is {@linkplain Double##equivalenceRelation 
> equivalent}
> + ? ? * to the value returned by {@code Float.intBitsToFloat(0x7fc00000)}.
> ? ? ? */
> ? ? ?public static final float NaN = 0.0f / 0.0f;
>
> Cheers,
> Eirik.

That would be a reasonable enhancement to the docs; thanks,

-Joe

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241107/4da63c58/attachment-0001.htm>

From mullan at openjdk.org  Thu Nov  7 18:50:52 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 7 Nov 2024 18:50:52 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v11]
In-Reply-To: <e9XneE4CQS0xlG3zIFZbOCt6j-gz0kRRUTLh45Pjxbs=.6f4cf332-68e1-4546-a859-435a72669094@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <e9XneE4CQS0xlG3zIFZbOCt6j-gz0kRRUTLh45Pjxbs=.6f4cf332-68e1-4546-a859-435a72669094@github.com>
Message-ID: <XTQ-TYPeAhQwhk7O73SJY1WycSkshAZgVhrhImCFSaI=.7b10a7ca-42c2-49c7-bd6a-4374e80e90e8@github.com>

On Thu, 7 Nov 2024 04:44:25 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> Using SharedSecrets, I attempted to expose FileInputStream::path information. After implementing the fix, I validated the startup performance tests. Observed no consistent pattern of performance drops or gains, can disregard the occasional performance drop observed in 1 or 2 runs.
>
> Prasadrao Koppula has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge master
>  - initialized storeName with empty string
>  - Replaced Paths.get with Path.of
>  - Removed unnecessary code
>  - Removed unnecessary code
>  - Handled nested wrappers around FileInputStream
>  - Handled BIS case as well
>  - JDK-8329251
>  - JDK-8329251
>  - JDK-8329251
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2316f68...c90b4f30

Some initial comments, still reviewing.

src/java.base/share/classes/java/security/KeyStore.java line 216:

> 214:     private static final String KEYSTORE_TYPE = "keystore.type";
> 215: 
> 216:     //The keystore full path

Nit, add space after `//`

src/java.base/share/classes/java/security/KeyStore.java line 217:

> 215: 
> 216:     //The keystore full path
> 217:     private static String keystorePath = null;

No need to initialize to null.

src/java.base/share/classes/java/security/KeyStore.java line 811:

> 809:     }
> 810: 
> 811:     // Set up JavaIOInputStreamAccess in SharedSecrets

s/JavaIOInputStreamAccess/JavaSecurityKeyStoreAccess/

src/java.base/share/classes/java/security/KeyStore.java line 1515:

> 1513:         throws IOException, NoSuchAlgorithmException, CertificateException
> 1514:     {
> 1515:         if (kdebug != null) {

See my other comment in `TrustStoreManagerFactory`.

src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 1:

> 1: /*

Update copyright date.

src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 283:

> 281:         if (ks != null && SSLLogger.isOn && SSLLogger.isOn("trustmanager")) {
> 282:             String keystorePath = SharedSecrets
> 283:                     .getJavaSecurityKeyStoreAccess()

This code only works if `java.security.debug=keystore` is also enabled, otherwise it will always return `null`. I think that dependency is not intuitive, and will be hard for users to remember. I think you should change `KeyStore.java` to always cache the filename, whether debug is on or not.

src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 286:

> 284:                     .getPath(ks);
> 285:             if (keystorePath != null) {
> 286:                 SSLLogger.fine(provider.getName() + ": using \"" + Path.of(

Suggest rewording as "Initializing with keystore: keystore.p12 in PKCS12 format from SUN provider"

Do you really need to log the provider name?

src/java.base/share/classes/sun/security/pkcs12/PKCS12KeyStore.java line 1962:

> 1960:         macAlgorithm = null;
> 1961:         macIterationCount = -1;
> 1962:         String storeName = "";

I think it is cleaner to not initialize this (leave it as null) and check for null inside debug statements. Same comment in `PKCS12KeyStore.java`.

src/java.base/share/classes/sun/security/provider/JavaKeyStore.java line 1:

> 1: /*

Update copyright date.

src/java.base/share/classes/sun/security/ssl/TrustStoreManager.java line 1:

> 1: /*

Update copyright date.

src/java.base/share/classes/sun/security/util/KeyStoreDelegator.java line 1:

> 1: /*

Update copyright date.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20414#pullrequestreview-2421303647
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833180471
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833180807
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833192049
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833192647
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833125524
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833191501
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833129736
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833138466
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1833135436
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1832866804
PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1832873896

From pchilanomate at openjdk.org  Thu Nov  7 19:15:50 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 19:15:50 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <e6nIhZ3j_26lGB_UfufAxV9innkqFcrAYLBY-u4KqG8=.1d5b20a9-d1d9-41d7-b379-944b463ae872@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits:

 - Use get_method_name + copyright revert in jvmtiThreadState.cpp
 - Merge branch 'master' into JDK-8338383
 - Add @requires vm.continuations to CancelTimerWithContention.java
 - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
 - Use is_top_frame boolean in FreezeBase::check_valid_fast_path()
 - Move load of _lock_id in C2_MacroAssembler::fast_lock
 - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java
 - Update comment for _cont_fastpath
 - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt
 - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()
 - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a

-------------

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02
  Stats: 9939 lines in 247 files changed: 7131 ins; 1629 del; 1179 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pminborg at openjdk.org  Thu Nov  7 19:17:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 7 Nov 2024 19:17:59 GMT
Subject: RFR: 8343771: Some FFM benchmarks are broken
Message-ID: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>

This PR fixes some regressions in the FFM benchmarks introduced by https://bugs.openjdk.org/browse/JDK-8332744.

-------------

Commit messages:
 - Add imports to FFM benchmarks

Changes: https://git.openjdk.org/jdk/pull/21963/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21963&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343771
  Stats: 61 lines in 21 files changed: 25 ins; 0 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/21963.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21963/head:pull/21963

PR: https://git.openjdk.org/jdk/pull/21963

From pchilanomate at openjdk.org  Thu Nov  7 19:20:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 19:20:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v2]
In-Reply-To: <uGEajP0tBBwAauSp584HWlT9pphV9N1NhLR3cvw1XIo=.cf2e196f-abf0-42e9-a396-83d3b23acd65@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <6A4aLBG_SIiuHVpwYnhjQh6NBVwfzqmHfvl3eTLFguk=.75bcd7f3-ccac-4b14-b243-6cca0b0194d4@github.com>
 <uGEajP0tBBwAauSp584HWlT9pphV9N1NhLR3cvw1XIo=.cf2e196f-abf0-42e9-a396-83d3b23acd65@github.com>
Message-ID: <HOfgPDSBY_Ezl9zJTecCVtg4yoCx4rC7XIyKo-4mXgM=.54f4a11a-39b8-4e8a-9ee5-d31778fce314@github.com>

On Thu, 7 Nov 2024 18:32:14 GMT, Serguei Spitsyn <sspitsyn at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>
> src/hotspot/share/prims/jvmtiThreadState.cpp line 2:
> 
>> 1: /*
>> 2:  * Copyright (c) 2003, 2024, Oracle and/or its affiliates. All rights reserved.
> 
> Nit: No need in the copyright update anymore.

Fixed.

> test/hotspot/jtreg/serviceability/jvmti/vthread/VThreadEventTest/libVThreadEventTest.cpp line 104:
> 
>> 102: 
>> 103:     err = jvmti->GetMethodName(frameInfo[idx].method, &methodName, nullptr, nullptr);
>> 104:     check_jvmti_status(jni, err, "event handler: error in JVMTI GetMethodName call");
> 
> Nit: There is the test library function `get_method_name()` in `jvmti_common.hpp` that can be used here.
> Also, the `methodName` is better to deallocate with the `deallocate() function.
> The same is in the `VirtualThreadMount` callback.

Updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833226416
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1833225816

From pchilanomate at openjdk.org  Thu Nov  7 19:24:07 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Thu, 7 Nov 2024 19:24:07 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <r8XCEJ4Jpzk5Smhog-1RFYzPpOW4UcUij-JOIZqPjho=.6c9e743c-2aa1-45f0-bf27-cc5a23b49536@github.com>
 <ypRIT7VzGMvzZaNYQA47d13tQ9U0RwxNGMEeZICjvh0=.23e38c35-2152-4181-8dfe-6764b9f112c7@github.com>
 <04lJ9Fw4vDQWjvQkCuYmVoaMN3t7Gq4pjg32puxcahQ=.3795a7ae-13d1-4cdb-b27d-db50ff53b59b@github.com>
 <7trSDsagiP_ARB6Fi8hffBxAn1tYxAMRxV1sV-GL0qw=.4899e993-c276-48ca-a6a6-ea5e1e56ac55@github.com>
Message-ID: <uEhEIQqZZyIk7CeXTIfcnQbT5W8Lwg_PDk0x3QGa-vo=.af020b96-7245-4800-91bf-12a3380ab85e@github.com>

On Thu, 7 Nov 2024 09:45:40 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> > I think we can add @requires vm.continuations to this test. It's not useful to run with the alternative virtual thread implementation.
> 
> Sure, that sounds ok. Thanks.
>
Added `@requires vm.continuations` to the test.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2463035166

From vaivanov at openjdk.org  Thu Nov  7 19:44:44 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 7 Nov 2024 19:44:44 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v3]
In-Reply-To: <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
 <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
Message-ID: <GfcaobDqBuxbvy_SFr1_1iEquWaMLVaoDti9MjTJ0OM=.ce64613a-7eb0-4ad4-b3cf-9eb73c5f26c5@github.com>

On Thu, 7 Nov 2024 18:30:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
>> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
>> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
>> Unit tests was not affected:
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp                                     516   516     0     0
>>    jtreg:test/jdk/javax/xml                             70    70     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> The tier1 is OK too.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317542: Specjvm::xml have scalability issue for high vCPU numbers

Scores for the xml.transform
original: 1 thread - 151.26; 16 - 2432.3; 32 - 4795.66; 112 - 7889.39 ops/m
patched: 1 thread - 152.35; 16 - 2445.44; 32 - 4807.34; 112 - 13418.68 ops/m

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2463070168

From jvernee at openjdk.org  Thu Nov  7 20:36:29 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 7 Nov 2024 20:36:29 GMT
Subject: RFR: 8343771: Some FFM benchmarks are broken
In-Reply-To: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
References: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
Message-ID: <MUeYEOGMOCgKhedIfr0QabBkGUEWzvv1U1n53Zve0_s=.2a25d934-b434-4ba7-aecf-e4b170bb199e@github.com>

On Thu, 7 Nov 2024 19:09:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes some regressions in the FFM benchmarks introduced by https://bugs.openjdk.org/browse/JDK-8332744.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21963#pullrequestreview-2422075408

From almatvee at openjdk.org  Thu Nov  7 21:11:45 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Thu, 7 Nov 2024 21:11:45 GMT
Subject: RFR: 8343396: Use OperatingSystem, Architecture,
 and OSVersion in jpackage tests
In-Reply-To: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
References: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
Message-ID: <ekCOshYNBoz7bTfK2pD8NGNB8rhI_rCl_UkPce_Cl-4=.b694521e-5a2b-4036-9b9b-4d1d7d32683d@github.com>

On Wed, 6 Nov 2024 21:42:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use internal jdk API instead of parsing JVM properties where appropriate in jpackage tests

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21940#pullrequestreview-2422157873

From henryjen at openjdk.org  Thu Nov  7 22:13:02 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Thu, 7 Nov 2024 22:13:02 GMT
Subject: RFR: 8342035: jlink plugins for setting java.vendor,
 java.vm.vendor and java.vendor.url
Message-ID: <0Ic5OQ8ME3gwmLWiavfeT2RIqaZ9Nl4QOpUAEfoEIos=.c696040e-223d-4295-b735-fba6b4d6401e@github.com>

Add jlink plugins to allow branding change for java.vendor, java.vm.vendor and java.vendor.url.

The jlink plugin will change the value in java.lang.VersionProps, which will set those property values. The `java.vm.vendor` was initialized by VM with value set at build time, and then later be replaced with value from VersionProps.

To keep current behavior, we treat 'N/A' value as no-op to mimic current build behavior. Perhaps we don't really need this, as proper value should be set with `branding.conf` in official build.

-------------

Commit messages:
 - Avoid N/A used as java.vm.vendor value as currently build behavior
 - 8342035: jlink plugins for setting java.vendor, java.vm.vendor and java.vendor.url

Changes: https://git.openjdk.org/jdk/pull/21964/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21964&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342035
  Stats: 224 lines in 14 files changed: 213 ins; 5 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21964.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21964/head:pull/21964

PR: https://git.openjdk.org/jdk/pull/21964

From mdoerr at openjdk.org  Thu Nov  7 22:13:26 2024
From: mdoerr at openjdk.org (Martin Doerr)
Date: Thu, 7 Nov 2024 22:13:26 GMT
Subject: RFR: 8343771: Some FFM benchmarks are broken
In-Reply-To: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
References: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
Message-ID: <NtsTEADxwWW_0aLm15XapYY6zYCz5GeBALyZms9xHV0=.54d7ed19-531b-4e6f-8e1f-c726be01a8c0@github.com>

On Thu, 7 Nov 2024 19:09:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes some regressions in the FFM benchmarks introduced by https://bugs.openjdk.org/browse/JDK-8332744.

LGTM.

-------------

Marked as reviewed by mdoerr (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21963#pullrequestreview-2422245460

From asemenyuk at openjdk.org  Thu Nov  7 22:14:02 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 7 Nov 2024 22:14:02 GMT
Subject: Integrated: 8343396: Use OperatingSystem, Architecture,
 and OSVersion in jpackage tests
In-Reply-To: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
References: <e9jNtS6OE8oJo5grgfC9OXwOiHt8TJ8_kSedszwjkrA=.b2b54003-476b-4cbf-8d8c-f85fc8f009d4@github.com>
Message-ID: <EapTplwwUwXUe-0tDK9F6Do6r-2XXsH65vZp-cwJpjo=.7c83f5c6-aeb7-4ddb-a010-68c4a295bfa6@github.com>

On Wed, 6 Nov 2024 21:42:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Use internal jdk API instead of parsing JVM properties where appropriate in jpackage tests

This pull request has now been integrated.

Changeset: a63f501b
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a63f501b9238c6aae81c2e39fcc1852652116780
Stats:     8 lines in 2 files changed: 2 ins; 2 del; 4 mod

8343396: Use OperatingSystem, Architecture, and OSVersion in jpackage tests

Reviewed-by: rriggs, almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/21940

From ihse at openjdk.org  Thu Nov  7 22:18:51 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 7 Nov 2024 22:18:51 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
Message-ID: <AmLjSeWVILSwTC9k3gOfw7yYPrI2nNuBjs6u4-6d5gs=.3d32aa83-2b12-4b46-9416-67526f46e3b8@github.com>

On Thu, 7 Nov 2024 13:27:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Mandy's feedback
>  - Remove "jlink.runtime.linkable" property from VMProps
>    
>    It's no longer used in any tests.
>  - Fix JLinkDedupTestBatchSizeOne.java
>  - Fix plugins/IncludeLocalesPluginTest.java
>    
>    Similar to GenerateJLIClassesPluginTest.java, the default module path
>    doesn't need to be explicitly specified.
>  - Fix plugins/GenerateJLIClassesPluginTest.java test
>    
>    The test doesn't need the default module path and default jmods
>    generated from the helper. Using this approach makes it work for
>    linkable run-time images as well.
>  - Simplify runtimeImage tests

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2422274159

From schernyshev at openjdk.org  Thu Nov  7 22:31:21 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Thu, 7 Nov 2024 22:31:21 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8343191
 - patch reimplemented
 - fix the logic that skips duplicate controller's mount points
 - 8343191: Cgroup v1 subsystem fails to set subsystem path

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/6a761ca2..3bb779af

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=01-02

  Stats: 137767 lines in 847 files changed: 107448 ins; 10821 del; 19498 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From naoto at openjdk.org  Thu Nov  7 23:41:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 7 Nov 2024 23:41:52 GMT
Subject: RFR: 8343804: Show the default time zone with -XshowSettings option
Message-ID: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>

A small enhancement in the Java launcher. For diagnostic purposes, display the default time zone ID with the `-XshowSettings` option.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/21965/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21965&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343804
  Stats: 9 lines in 2 files changed: 7 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21965.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21965/head:pull/21965

PR: https://git.openjdk.org/jdk/pull/21965

From iris at openjdk.org  Fri Nov  8 00:57:48 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 8 Nov 2024 00:57:48 GMT
Subject: RFR: 8343804: Show the default time zone with -XshowSettings
 option
In-Reply-To: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
References: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
Message-ID: <bIouo4ReKZyXA2ca_6nittMwF_O2K3orZnwpjP6nrMw=.517f62b6-3f0e-4caa-bf4c-d5084b3fafbe@github.com>

On Thu, 7 Nov 2024 23:36:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A small enhancement in the Java launcher. For diagnostic purposes, display the default time zone ID with the `-XshowSettings` option.

Nice RFE.

-------------

Marked as reviewed by iris (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21965#pullrequestreview-2422465179

From qamai at openjdk.org  Fri Nov  8 01:53:49 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Nov 2024 01:53:49 GMT
Subject: RFR: 8343770: Build fails due to use of sun.misc.Unsafe in
 LoopOverRandom
In-Reply-To: <u9UMXf_RcfgLBYD5DqDQl0gGIPSHmdImGaJHCUfedG8=.7cbb990e-fb2b-42d3-896a-2301536abe69@github.com>
References: <u9UMXf_RcfgLBYD5DqDQl0gGIPSHmdImGaJHCUfedG8=.7cbb990e-fb2b-42d3-896a-2301536abe69@github.com>
Message-ID: <bCJdBN19JzXaUR7eJSwzKzSYR_fjjfBgmuLSlQPCeMQ=.1ca06465-ad88-4fd6-b47d-b83ade453f5a@github.com>

On Thu, 7 Nov 2024 15:12:01 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> This small PR fixes a build failure due to usage of sun.misc.Unsafe in a new benchmark.
> 
> FFM benchmarks appear to be broken -- because of JDK-8332744 -- but we will fix that separately.

@mcimadamore Sorry for the failure and thanks a lot for the speedy fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21958#issuecomment-2463596465

From dholmes at openjdk.org  Fri Nov  8 02:16:02 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 02:16:02 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>

On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FIXME

Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:

https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170

I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463619091

From amenkov at openjdk.org  Fri Nov  8 02:38:17 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Nov 2024 02:38:17 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
Message-ID: <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>

On Fri, 8 Nov 2024 02:13:09 GMT, David Holmes <dholmes at openjdk.org> wrote:

> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
> 
> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
> 
> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.

In the page you mentioned:

 Format of a C decorated name
The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463636430

From sspitsyn at openjdk.org  Fri Nov  8 03:05:13 2024
From: sspitsyn at openjdk.org (Serguei Spitsyn)
Date: Fri, 8 Nov 2024 03:05:13 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v3]
In-Reply-To: <e6nIhZ3j_26lGB_UfufAxV9innkqFcrAYLBY-u4KqG8=.1d5b20a9-d1d9-41d7-b379-944b463ae872@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <e6nIhZ3j_26lGB_UfufAxV9innkqFcrAYLBY-u4KqG8=.1d5b20a9-d1d9-41d7-b379-944b463ae872@github.com>
Message-ID: <-R7NADC_veb_n80hbfTME54iuMOvSj38dfBrT0KJQOw=.9345dfb0-58bd-4485-b92a-8c79b9114d25@github.com>

On Thu, 7 Nov 2024 19:15:50 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 84 commits:
> 
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - Use is_top_frame boolean in FreezeBase::check_valid_fast_path()
>  - Move load of _lock_id in C2_MacroAssembler::fast_lock
>  - Add --enable-native-access=ALL-UNNAMED to SynchronizedNative.java
>  - Update comment for _cont_fastpath
>  - Add ReflectionCallerCacheTest.java to test/jdk/ProblemList-Xcomp.txt
>  - Use ThreadIdentifier::initial() in ObjectMonitor::owner_from()
>  - ... and 74 more: https://git.openjdk.org/jdk/compare/d3c042f9...62b16c6a

Marked as reviewed by sspitsyn (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2422590696

From iklam at openjdk.org  Fri Nov  8 03:31:51 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 8 Nov 2024 03:31:51 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v9]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <XYYW1fN34ZzkD4ifP4E-vFCkWsn4QJyX_42eT2qA12s=.b8d64cfd-4ba8-4c0e-8f98-ba947479ba1a@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 175 commits:

 - fixed merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline
 - @DanHeidinga comment -- exit VM when runtimeSetup() fails
 - fixed merge
 - Merge branch 'master' into jep-483-candidate
 - 8343493: Perform module checks during MetaspaceShared::map_archives()
 - reverted changes in modules.cpp to make it easy to merge with mainline
 - Fixed whitespace; fixed minimal build
 - Fixed 8343245: AOT cache creation crashes with "assert(HeapShared::is_archivable_hidden_klass(ik)) failed: sanity"
 - fixed comments
 - ... and 165 more: https://git.openjdk.org/jdk/compare/f621f26c...7b06b7c7

-------------

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=08
  Stats: 7184 lines in 107 files changed: 6349 ins; 513 del; 322 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From jpai at openjdk.org  Fri Nov  8 04:08:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Nov 2024 04:08:52 GMT
Subject: RFR: 8343293: Remove the check for <apphome>/jre/lib/libjava.dylib
 from the launcher's java_md_macosx.m [v2]
In-Reply-To: <jimrIPiksROK_-goTNbNi0HmPC2qGhiUmzRv6wfsmbI=.859344ce-f50a-420c-a7c6-bb1168a20ab2@github.com>
References: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
 <jimrIPiksROK_-goTNbNi0HmPC2qGhiUmzRv6wfsmbI=.859344ce-f50a-420c-a7c6-bb1168a20ab2@github.com>
Message-ID: <DWp8TWxgeaHiG-fAY4XqDE4jJw7jXsRyuzrmON_7Mgk=.3d12aa50-8482-4169-b3d4-c1f13cd0c7bf@github.com>

On Fri, 1 Nov 2024 14:51:49 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which cleans up a leftover code from the launcher's java_md_macosx.m file?
>> 
>> In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the launcher code to remove checks for  `<apphome>/jre/lib/` when determining the JDK installation root. Those changes were done in the Unix and Windows files and the macosx one got left out, likely due to an oversight.
>> 
>> The commit in this PR removes that leftover code. No new tests have been added and existing tier1, tier2, tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Roger's suggestion - introduce log message to match unix/windows

Thank you Roger and Brian for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21789#issuecomment-2463712048

From jpai at openjdk.org  Fri Nov  8 04:08:52 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Nov 2024 04:08:52 GMT
Subject: Integrated: 8343293: Remove the check for
 <apphome>/jre/lib/libjava.dylib from the launcher's java_md_macosx.m
In-Reply-To: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
References: <MSqoxrJu4mec9PWiViVKtmljyQr_EPC8xoUx-HFLzik=.e6c8e8cb-d5a0-4f57-be4c-fdccaa1ab427@github.com>
Message-ID: <LwFvMd40KY6Q7vMiUWoPSXClLzU5hUgW8itk4ADa43k=.fc4de894-57db-4850-978d-d1e5608f8cea@github.com>

On Wed, 30 Oct 2024 14:27:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which cleans up a leftover code from the launcher's java_md_macosx.m file?
> 
> In https://bugs.openjdk.org/browse/JDK-8329862 changes were done in the launcher code to remove checks for  `<apphome>/jre/lib/` when determining the JDK installation root. Those changes were done in the Unix and Windows files and the macosx one got left out, likely due to an oversight.
> 
> The commit in this PR removes that leftover code. No new tests have been added and existing tier1, tier2, tier3 tests continue to pass.

This pull request has now been integrated.

Changeset: 068f4ce8
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/068f4ce8bc0fb43417c6493597160b49554221d3
Stats:     14 lines in 1 file changed: 2 ins; 12 del; 0 mod

8343293: Remove the check for <apphome>/jre/lib/libjava.dylib from the launcher's java_md_macosx.m

Reviewed-by: bpb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/21789

From jpai at openjdk.org  Fri Nov  8 04:43:21 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Nov 2024 04:43:21 GMT
Subject: RFR: 8343804: Show the default time zone with -XshowSettings
 option
In-Reply-To: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
References: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
Message-ID: <j_12hylBtkrFJuhf1F10IVUmXmQiPeZbbeijQyV5rKw=.dcd79a91-acfc-4a4e-9c5c-da50cbb89b7a@github.com>

On Thu, 7 Nov 2024 23:36:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A small enhancement in the Java launcher. For diagnostic purposes, display the default time zone ID with the `-XshowSettings` option.

Hello Naoto, this looks good to me. The test itself could assert that the printed timezone is indeed the default timezone, but if you prefer it in its current form, that's fine too.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21965#pullrequestreview-2422672395

From jwaters at openjdk.org  Fri Nov  8 05:34:19 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Nov 2024 05:34:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
Message-ID: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com>

On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
> 
> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
> 
> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.

https://godbolt.org/z/xve7cbG1e

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463794511

From dholmes at openjdk.org  Fri Nov  8 05:34:19 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 05:34:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
Message-ID: <GEHOzUX9CUxLMV0pdxtSpxvykkcCX-K9Y4Zmh3zSpuQ=.b2456647-f690-4a76-8409-70a09255dde1@github.com>

On Fri, 8 Nov 2024 02:32:42 GMT, Alex Menkov <amenkov at openjdk.org> wrote:

> In the page you mentioned:

@alexmenkov  that is for C functions, not C++.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463796536

From dholmes at openjdk.org  Fri Nov  8 05:46:58 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 05:46:58 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
 <5MiMXHq-N3d78GScK19QTQAg0t9eyJUo3XznZE-7VJg=.4121e038-b666-4770-a497-5a5522c51027@github.com>
Message-ID: <v52apX6P8vmous8o3RCQbeeoklOyCD8jjp1vwhw9zwY=.c7267189-58dd-484c-afed-9227686e44f3@github.com>

On Fri, 8 Nov 2024 05:26:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>>> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
>>> 
>>> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
>>> 
>>> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.
>> 
>> In the page you mentioned:
>> 
>>  Format of a C decorated name
>> The form of decoration for a C function depends on the calling convention used in its declaration, as shown in the following table. It's also the decoration format that's used when C++ code is declared to have extern "C" linkage. The default calling convention is __cdecl. **In a 64-bit environment, C or extern "C" functions are only decorated when using the __vectorcall calling convention**.
>
>> Can someone confirm that use of `__stdcall` has no affect on name decorations, as there is no mention here about anything being ignored:
>> 
>> https://learn.microsoft.com/en-us/cpp/build/reference/decorated-names?view=msvc-170
>> 
>> I would have expected that if argument passing needs to use the stack then the decorated name would still need to encode that somehow.
> 
> Not __stdcall: https://godbolt.org/z/nvjTP5WPc
> __stdcall: https://godbolt.org/z/1KejW44vY

Thanks @TheShermanTanker . I see the arguments do affect the encoding but the `__stdcall` makes no difference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2463816359

From dholmes at openjdk.org  Fri Nov  8 05:51:28 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 8 Nov 2024 05:51:28 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <1D5bn5rgr4DaceNVvTisKsP3eAm-2R4D9DcZJ6gp1bk=.6add3137-d50a-488d-89e8-dd503d524e5c@github.com>

On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FIXME

Clearing my "changes requested" status

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2422752388

From pminborg at openjdk.org  Fri Nov  8 06:36:13 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Nov 2024 06:36:13 GMT
Subject: Integrated: 8343771: Some FFM benchmarks are broken
In-Reply-To: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
References: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
Message-ID: <kMrKgv4hZr0yJiysh8UbLwC3k_g_URSZz-u27vryim0=.0e9dcf52-0b9f-4b0c-a351-c2d7ce470d0c@github.com>

On Thu, 7 Nov 2024 19:09:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes some regressions in the FFM benchmarks introduced by https://bugs.openjdk.org/browse/JDK-8332744.

This pull request has now been integrated.

Changeset: d0077eec
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0077eece0531bbfef72d25628ec23ba3a799f18
Stats:     61 lines in 21 files changed: 25 ins; 0 del; 36 mod

8343771: Some FFM benchmarks are broken

Reviewed-by: jvernee, mdoerr

-------------

PR: https://git.openjdk.org/jdk/pull/21963

From jbhateja at openjdk.org  Fri Nov  8 08:15:32 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Fri, 8 Nov 2024 08:15:32 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Creating specialized IR to shield pattern from subsequent transforms in optimization pipeline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21244/files
  - new: https://git.openjdk.org/jdk/pull/21244/files/43320063..613f491b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=00-01

  Stats: 69 lines in 7 files changed: 57 ins; 3 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21244/head:pull/21244

PR: https://git.openjdk.org/jdk/pull/21244

From jpai at openjdk.org  Fri Nov  8 08:57:43 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Nov 2024 08:57:43 GMT
Subject: RFR: 8211033: Clean up the processing -classpath argument not to set
 LM_CLASS
Message-ID: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>

Can I please get a review of this change which addresses https://bugs.openjdk.org/browse/JDK-8211033?

As noted in that issue, this is a clean up of the code which determines the "mode" through with the `java` application is being launched. In its current form the presence of `--classpath` (or its equivalent arguments) was unnecessary updating the mode to `LM_CLASS`. The commit in this PR removes that part to allow for the mode to be detected based merely on the presence (or absence) of `-m`, `-jar`, `--source` options. If neither is specified, the file extension is checked to determine the launch mode. 

Given the nature of this clean up, no new tests have been introduced. Existing tests in tier1, tier2, tier3 continue to pass with this change.

-------------

Commit messages:
 - 8211033: Clean up the processing -classpath argument not to set LM_CLASS

Changes: https://git.openjdk.org/jdk/pull/21971/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21971&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8211033
  Stats: 8 lines in 1 file changed: 3 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21971.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21971/head:pull/21971

PR: https://git.openjdk.org/jdk/pull/21971

From alanb at openjdk.org  Fri Nov  8 09:22:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 09:22:54 GMT
Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fourth
 Preview)
Message-ID: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>

Changes for [JEP draft: Structured Concurrency (Fourth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:

- A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
- In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
- The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
- Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
- joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
 
The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

-------------

Commit messages:
 - Sync up from loom repo
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342486
  Stats: 4114 lines in 15 files changed: 1888 ins; 1519 del; 707 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From alanb at openjdk.org  Fri Nov  8 09:22:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 09:22:55 GMT
Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fourth
 Preview)
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <UxC6_V4ucqcmpAb91H0L8mEwE0YE-VWVP-FPDatW10Y=.5e4a1157-24c3-4866-aa05-80b473ac6ec7@github.com>

On Wed, 6 Nov 2024 15:47:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Changes for [JEP draft: Structured Concurrency (Fourth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 122:

> 120:  * {@link #close() close} method always waits for threads executing subtasks to finish,
> 121:  * even if the scope is cancelled, so execution cannot continue beyond the {@code close}
> 122:  * method until the interrupted threads finish.

Viktor has suggested that we move this paragraph up or at least make it more prominent.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 337:

> 335:  * <a href="{@docRoot}/java.base/java/util/concurrent/package-summary.html#MemoryVisibility">
> 336:  * <i>happen-before</i></a> any actions taken by that subtask, which in turn
> 337:  * <i>happen-before</i> the subtask result is {@linkplain Subtask#get() retrieved}.

Chen has suggested that this be expanded to specify a HB between onComplete and join. Viktor and I have discussed extending the existing text to deal with subtask outcome that "contributes" to the scope result but did not agree wording (note that this is a pre-existing short-coming in the spec, not a new issue).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r1832464575
PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r1832468226

From alanb at openjdk.org  Fri Nov  8 09:31:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 09:31:41 GMT
Subject: RFR: 8211033: Clean up the processing -classpath argument not to
 set LM_CLASS
In-Reply-To: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
References: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
Message-ID: <siCq441pFO0umihFAPBNX7UJcjfx6ogLaDA67eZcIhc=.99bf4233-f63f-4c57-9646-024eb8273ff8@github.com>

On Fri, 8 Nov 2024 08:51:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.org/browse/JDK-8211033?
> 
> As noted in that issue, this is a clean up of the code which determines the "mode" through with the `java` application is being launched. In its current form the presence of `--classpath` (or its equivalent arguments) was unnecessary updating the mode to `LM_CLASS`. The commit in this PR removes that part to allow for the mode to be detected based merely on the presence (or absence) of `-m`, `-jar`, `--source` options. If neither is specified, the file extension is checked to determine the launch mode. 
> 
> Given the nature of this clean up, no new tests have been introduced. Existing tests in tier1, tier2, tier3 continue to pass with this change.

On the surface this looks okay but just to double check: this has no impact on `java -cp <classpath> -jar app.jar`. The class path in that case is `app.jar`, the class path specified to -cp is ignored.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21971#issuecomment-2464224551

From ihse at openjdk.org  Fri Nov  8 09:35:26 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 09:35:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <uDshibe97YJEl86SlFE0UfYWTPOLQbc3qOylYvoM6DI=.32f63129-fc1e-4ffa-8719-231182471044@github.com>

On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

@shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here..

As I said, I think they are just as safe as any other changes -- the only difference is that it is perhaps not as well-known in the community that they only affect x86.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464232813

From alanb at openjdk.org  Fri Nov  8 09:39:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 09:39:09 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
Message-ID: <Yo4R252ZE_XRWkfGOgN_p-60lzlsJw-p8_w-mz5Fi1U=.10e9edce-224c-4332-97fb-baace7fac287@github.com>

On Thu, 7 Nov 2024 13:27:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Mandy's feedback
>  - Remove "jlink.runtime.linkable" property from VMProps
>    
>    It's no longer used in any tests.
>  - Fix JLinkDedupTestBatchSizeOne.java
>  - Fix plugins/IncludeLocalesPluginTest.java
>    
>    Similar to GenerateJLIClassesPluginTest.java, the default module path
>    doesn't need to be explicitly specified.
>  - Fix plugins/GenerateJLIClassesPluginTest.java test
>    
>    The test doesn't need the default module path and default jmods
>    generated from the helper. Using this approach makes it work for
>    linkable run-time images as well.
>  - Simplify runtimeImage tests

test/langtools/tools/javac/plugin/AutostartPlugins.java line 33:

> 31:  *           jdk.jlink
> 32:  *  @build toolbox.ToolBox toolbox.JavacTask toolbox.JarTask
> 33:  *  @run main/othervm AutostartPlugins

Why do the two javac plugin tests changed to /othervm? I assume they fail with a JDK built with --generate-linkable-runtime but I can't immediately see why.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834017867

From amenkov at openjdk.org  Fri Nov  8 09:41:54 2024
From: amenkov at openjdk.org (Alex Menkov)
Date: Fri, 8 Nov 2024 09:41:54 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <GEHOzUX9CUxLMV0pdxtSpxvykkcCX-K9Y4Zmh3zSpuQ=.b2456647-f690-4a76-8409-70a09255dde1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <vh3o--qlhEfW57TB0dtAx4Rq-H0bKn8V0-R6NrAWu5I=.1dce67c5-4436-4357-bd9f-e9b2daf7775a@github.com>
 <r9a7mkUOid6fY3Z3ms9Sk2S2PGLLo-7pNfxvek41si0=.c26e1920-01a2-41b7-9666-f6607b66c552@github.com>
 <GEHOzUX9CUxLMV0pdxtSpxvykkcCX-K9Y4Zmh3zSpuQ=.b2456647-f690-4a76-8409-70a09255dde1@github.com>
Message-ID: <f8lYbWXchszFEUOQpQX1ZjcjJ5CIrCItloYsd_wpdoE=.e72ca656-58e2-4719-9409-44a2c343d607@github.com>

On Fri, 8 Nov 2024 05:29:05 GMT, David Holmes <dholmes at openjdk.org> wrote:

> > In the page you mentioned:
> 
> @alexmenkov that is for C functions, not C++.

And also for `extern "C"` (AFAIU we export all C++ functions as extern "C")

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464243142

From jwaters at openjdk.org  Fri Nov  8 09:44:22 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Nov 2024 09:44:22 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v4]
In-Reply-To: <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
Message-ID: <9T3uwY8Yh-aRhSC-jxbbJDpYXUh4RAQH_U_wsmMpc7c=.a3e21c96-1606-46a8-a392-b22e15f3325d@github.com>

On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove global memHandle, would've liked to keep it as a comment :(

Bumping, awaiting jpackage review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2464249727

From alanb at openjdk.org  Fri Nov  8 09:47:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 09:47:59 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
Message-ID: <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>

On Thu, 7 Nov 2024 13:27:41 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with six additional commits since the last revision:
> 
>  - Mandy's feedback
>  - Remove "jlink.runtime.linkable" property from VMProps
>    
>    It's no longer used in any tests.
>  - Fix JLinkDedupTestBatchSizeOne.java
>  - Fix plugins/IncludeLocalesPluginTest.java
>    
>    Similar to GenerateJLIClassesPluginTest.java, the default module path
>    doesn't need to be explicitly specified.
>  - Fix plugins/GenerateJLIClassesPluginTest.java test
>    
>    The test doesn't need the default module path and default jmods
>    generated from the helper. Using this approach makes it work for
>    linkable run-time images as well.
>  - Simplify runtimeImage tests

test/jtreg-ext/requires/VMProps.java line 28:

> 26: import java.lang.module.ModuleFinder;
> 27: import java.lang.module.ModuleReader;
> 28: import java.lang.module.ModuleReference;

I assume they aren't needed now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834029491

From nbenalla at openjdk.org  Fri Nov  8 09:56:45 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 8 Nov 2024 09:56:45 GMT
Subject: Integrated: 8341399: Add since checker tests to the langtools modules
In-Reply-To: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
References: <ikgCpajRwWsRwD-i_RjntitRP_Lv19EUf9GRGqMTVQs=.f2af03ae-a45e-44b8-a606-63ec3c0b66ed@github.com>
Message-ID: <5iZbg1dFV5meKMJ3NAPm1vDLPGijejGYf7dl81TRZVg=.93c706a0-5dcc-4ce5-b6f8-311c96657764@github.com>

On Wed, 16 Oct 2024 16:23:41 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this patch that adds `@since` checker tests to the following modules: java.compiler, jdk.compiler, jdk.javadoc and jdk.jdeps. The initial test for `java.base` has been integrated in [JDK-8331051](https://bugs.openjdk.org/browse/JDK-8331051). 
> 
> The jtreg comments are almost the same as the ones for the `java.base` test, only the Bug ID and the module name being passed to the test are different.
> 
> I've made a small change to `test/jdk/TEST.groups` to include the new tests.
> 
> Here are the emails  [[1](https://mail.openjdk.org/pipermail/jdk-dev/2024-June/009160.html)] [[2](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html)] in `jdk-dev` describing how the tests work and how to run them.
> 
> TIA

This pull request has now been integrated.

Changeset: 2e58ede1
Author:    Nizar Benalla <nbenalla at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2e58ede18c7cfe7364a8d6a630989b0ff2ea6447
Stats:     219 lines in 9 files changed: 184 ins; 34 del; 1 mod

8341399: Add since checker tests to the langtools modules

Reviewed-by: vromero

-------------

PR: https://git.openjdk.org/jdk/pull/21542

From sgehwolf at openjdk.org  Fri Nov  8 10:02:49 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 10:02:49 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
 <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>
Message-ID: <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>

On Fri, 8 Nov 2024 09:44:01 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Severin Gehwolf has updated the pull request incrementally with six additional commits since the last revision:
>> 
>>  - Mandy's feedback
>>  - Remove "jlink.runtime.linkable" property from VMProps
>>    
>>    It's no longer used in any tests.
>>  - Fix JLinkDedupTestBatchSizeOne.java
>>  - Fix plugins/IncludeLocalesPluginTest.java
>>    
>>    Similar to GenerateJLIClassesPluginTest.java, the default module path
>>    doesn't need to be explicitly specified.
>>  - Fix plugins/GenerateJLIClassesPluginTest.java test
>>    
>>    The test doesn't need the default module path and default jmods
>>    generated from the helper. Using this approach makes it work for
>>    linkable run-time images as well.
>>  - Simplify runtimeImage tests
>
> test/jtreg-ext/requires/VMProps.java line 28:
> 
>> 26: import java.lang.module.ModuleFinder;
>> 27: import java.lang.module.ModuleReader;
>> 28: import java.lang.module.ModuleReference;
> 
> I assume they aren't needed now.

True.

> test/langtools/tools/javac/plugin/AutostartPlugins.java line 33:
> 
>> 31:  *           jdk.jlink
>> 32:  *  @build toolbox.ToolBox toolbox.JavacTask toolbox.JarTask
>> 33:  *  @run main/othervm AutostartPlugins
> 
> Why do the two javac plugin tests changed to /othervm? I assume they fail with a JDK built with --generate-linkable-runtime but I can't immediately see why.

jtreg patches the `java.base` module and those langtools tests *link* from the run-time image (in such a config). Having a patched JDK module is not supported (and I don't think we ever should). Running in a separate JVM doesn't have this problem. See https://github.com/openjdk/jdk/pull/14787/commits/d8e1e834508589725adb8d70acb862a1270678ca. Does that make sense?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834057484
PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834056602

From shade at openjdk.org  Fri Nov  8 10:09:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Nov 2024 10:09:26 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
 <4k1ryyYmwMf65MzhhnNLSBtumKR5eoy4BEypEoiTO9k=.f487b012-563c-4c08-9420-b5be5b63a7a3@github.com>
Message-ID: <PG-hSNCegArTGhR1uGessvPoJk1Hx2O-tIya-B1fk6c=.6e5c5762-4c4f-46cf-b1b4-95f10627b183@github.com>

On Thu, 7 Nov 2024 12:16:23 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove FIXME
>
> I really wish we did not mess with `_stdcall` and `_cdecl` in this PR. A future me chasing a bug would be surprised if we broke 64-bit Windows with this "cleanup" PR. I think the PR like this should only carry the changes that are provably, uncontroversially, visibly safe. Everything else that has any chance to do semantic changes, should be done in follow-up PRs, IMO.

> @shipilev Could you consider accepting the existing `__stdcall` changes in this PR? That seems like the easiest way out of satisfying everyones opinions here..

Sure, fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21744#issuecomment-2464299781

From jlahoda at openjdk.org  Fri Nov  8 10:11:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Fri, 8 Nov 2024 10:11:06 GMT
Subject: RFR: 8335989: JEP 494: Implement Module Import Declarations
 (Second Preview) [v6]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <hHSAfrSwZTRpGqvuXq7Nu0ZSx4fztfYG57vTS9rqEhc=.5aadc7fb-289b-49ff-9a34-eefa2d90758c@github.com>

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 20 commits:

 - Merge branch 'master' into JDK-8335989
 - Moving operators to the beginning of line, as suggested.
 - Updating PreviewFeature metadata
 - Cleanup.
 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - Fixing tests
 - ... and 10 more: https://git.openjdk.org/jdk/compare/a10b1ccd...21c835ca

-------------

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=05
  Stats: 762 lines in 28 files changed: 580 ins; 46 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/21431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21431/head:pull/21431

PR: https://git.openjdk.org/jdk/pull/21431

From shade at openjdk.org  Fri Nov  8 10:17:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 8 Nov 2024 10:17:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v31]
In-Reply-To: <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <lTYHAWOG-YbSIt7hOG1WnTFO8GsRhA7yCnl2Ef925o8=.47e90df6-48c9-4706-8400-6120580f55c1@github.com>
Message-ID: <l0-oBnOTlMFRQ9am7L0fCeHbR_HaqQHPpit55a-8oWY=.5b45329e-d763-4f5d-9dd1-f4ee74c5291c@github.com>

On Wed, 6 Nov 2024 15:21:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove FIXME

Marked as reviewed by shade (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2423300933

From sgehwolf at openjdk.org  Fri Nov  8 10:26:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 10:26:30 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
Message-ID: <xy9aPzs8lD8m3XFlSfbhYmwA0i0laXFzHBSY7WFfMpU=.2851a8d1-86bc-4bda-9a5b-758f22fe6d9b@github.com>

On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343191
>  - patch reimplemented
>  - fix the logic that skips duplicate controller's mount points
>  - 8343191: Cgroup v1 subsystem fails to set subsystem path

Have you checked on cg v2? Is this a problem there as well?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2464339096

From alanb at openjdk.org  Fri Nov  8 10:29:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 10:29:02 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
 <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>
 <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>
Message-ID: <jn2BQPpc-gQAfNF2I3TQy2EIRD-M27td6BmFmf0y088=.8148de4f-07c7-4eb7-a5ab-121044d9d6e3@github.com>

On Fri, 8 Nov 2024 09:58:13 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/langtools/tools/javac/plugin/AutostartPlugins.java line 33:
>> 
>>> 31:  *           jdk.jlink
>>> 32:  *  @build toolbox.ToolBox toolbox.JavacTask toolbox.JarTask
>>> 33:  *  @run main/othervm AutostartPlugins
>> 
>> Why do the two javac plugin tests changed to /othervm? I assume they fail with a JDK built with --generate-linkable-runtime but I can't immediately see why.
>
> jtreg patches the `java.base` module and those langtools tests *link* from the run-time image (in such a config). Having a patched JDK module is not supported (and I don't think we ever should). Running in a separate JVM doesn't have this problem. See https://github.com/openjdk/jdk/pull/14787/commits/d8e1e834508589725adb8d70acb862a1270678ca. Does that make sense?

That's okay, I wasn't initially sure why they were changed.  I'm looking at JRTArchiveFile.toEntry and wondering there should be a follow-up issue (not this PR) to fail early if running on a patched run-time even though it would be an odd configuration to attempt to do that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834095994

From sgehwolf at openjdk.org  Fri Nov  8 10:42:15 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 10:42:15 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v47]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused imports from VMProps

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/f55bb853..0bf4843d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=46
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=45-46

  Stats: 5 lines in 1 file changed: 0 ins; 5 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From sgehwolf at openjdk.org  Fri Nov  8 10:42:16 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 10:42:16 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
 <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>
 <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>
Message-ID: <ULu9FErFxamD-SAhTKeXWFmdL2FqyxoKt9Ban_Ke6m0=.5d0c6c97-3e04-448d-b4a0-bdadb3f839c2@github.com>

On Fri, 8 Nov 2024 09:58:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> test/jtreg-ext/requires/VMProps.java line 28:
>> 
>>> 26: import java.lang.module.ModuleFinder;
>>> 27: import java.lang.module.ModuleReader;
>>> 28: import java.lang.module.ModuleReference;
>> 
>> I assume they aren't needed now.
>
> True.

fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834118546

From sgehwolf at openjdk.org  Fri Nov  8 10:42:16 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 10:42:16 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <jn2BQPpc-gQAfNF2I3TQy2EIRD-M27td6BmFmf0y088=.8148de4f-07c7-4eb7-a5ab-121044d9d6e3@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
 <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>
 <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>
 <jn2BQPpc-gQAfNF2I3TQy2EIRD-M27td6BmFmf0y088=.8148de4f-07c7-4eb7-a5ab-121044d9d6e3@github.com>
Message-ID: <rSQvUkjDXEZei6Dgr-BhOYCLr3Fo_1QNdBDzfjyo4kI=.1e436131-dd1e-4747-92d6-476095113c68@github.com>

On Fri, 8 Nov 2024 10:26:36 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> jtreg patches the `java.base` module and those langtools tests *link* from the run-time image (in such a config). Having a patched JDK module is not supported (and I don't think we ever should). Running in a separate JVM doesn't have this problem. See https://github.com/openjdk/jdk/pull/14787/commits/d8e1e834508589725adb8d70acb862a1270678ca. Does that make sense?
>
> That's okay, I wasn't initially sure why they were changed.  I'm looking at JRTArchiveFile.toEntry and wondering there should be a follow-up issue (not this PR) to fail early if running on a patched run-time even though it would be an odd configuration to attempt to do that.

There already is. See:
https://github.com/openjdk/jdk/pull/14787/files#diff-b6b47eacb6060eb0a583a253f322f5d274063e082a12a72e8628a6e1ba6cdd3eR466-R471

It's also tested with [PatchedJDKModuleJlinkTest.java](https://github.com/openjdk/jdk/pull/14787/files#diff-11b8a26307346fd7ca016a349243cabd3b982964aaf4335298e28e956b3968eb). Do we need more?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834114823

From jpai at openjdk.org  Fri Nov  8 10:45:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 8 Nov 2024 10:45:30 GMT
Subject: RFR: 8211033: Clean up the processing -classpath argument not to
 set LM_CLASS
In-Reply-To: <siCq441pFO0umihFAPBNX7UJcjfx6ogLaDA67eZcIhc=.99bf4233-f63f-4c57-9646-024eb8273ff8@github.com>
References: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
 <siCq441pFO0umihFAPBNX7UJcjfx6ogLaDA67eZcIhc=.99bf4233-f63f-4c57-9646-024eb8273ff8@github.com>
Message-ID: <8gCivItwwwgnHuJQsszc-1QbJozlj1ehMyq_62UbgT8=.3b0ceda7-a643-417c-8e8b-81353e88c024@github.com>

On Fri, 8 Nov 2024 09:28:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> On the surface this looks okay but just to double check: this has no impact on `java -cp <classpath> -jar app.jar`. The class path in that case is `app.jar`, the class path specified to -cp is ignored.

That's right - the launcher explicitly overrides the classpath in that case here https://github.com/openjdk/jdk/blob/master/src/java.base/share/native/libjli/java.c#L313:


/* Override class path if -jar flag was specified */
if (mode == LM_JAR) {
    SetClassPath(what);     /* Override class path */
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21971#issuecomment-2464377538

From azafari at openjdk.org  Fri Nov  8 10:51:27 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:27 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
Message-ID: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>

- `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
 -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
 -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
 - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
 - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
 - Adding a runtime flag for selecting the old or new version can be added later.
 - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

-------------

Commit messages:
 - added some descriptions of how VMT works.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - fixes after merge with use_tag_inplace
 - fixed merged glitches.
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - Merge remote-tracking branch 'origin/master' into _8337217_nmt_VMT_with_tree
 - snaphot thread stack updated and tested.
 - removed unnecessary line from visit committed region function.
 - fixed hpp gaurd of vmtCommon.
 - Johan's feedback.
 - ... and 33 more: https://git.openjdk.org/jdk/compare/ac82a8f8...1e4fbf21

Changes: https://git.openjdk.org/jdk/pull/20425/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20425&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8337217
  Stats: 3294 lines in 55 files changed: 1520 ins; 1525 del; 249 mod
  Patch: https://git.openjdk.org/jdk/pull/20425.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20425/head:pull/20425

PR: https://git.openjdk.org/jdk/pull/20425

From jsjolen at openjdk.org  Fri Nov  8 10:51:33 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:51:33 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>

On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Hi,

Great work! I'm slowly working through the code, let's take our time with this. My PR got too stressful for everyone involved :-/.

I've reviewed some of the code. Could you go a bit more in-depth on what the results of this work was? Did it improve performance, for example?

>All tier1 tests pass except one that expects a 50% increase in committed memory *but it does not happen*.

~~I don't understand what this means, could you expand on this?~~ Edit: Re-read it again now and I get it, which test is this?

Thanks!

Changes requested by jsjolen (Reviewer).

Changes requested by jsjolen (Reviewer).

This code generally over-uses pointers. Please have a go through this code and change to references when applicable.

Another round of review comments :).

What is the consensus on having two implementations alive at the same time? I'd like to see us delete the old VirtualMemoryTracker and only have the tree implementation left as part of this PR. What is the status of our testing? Is the tree version equivalent now and passes all tests?

I'd also like to see the tty printing code to either be deleted or if it's useful for mainline be adjusted so that it is using UL instead.

Some more reviews here along with some questions. I see that you've merged in my PR 8340103. That's good, let's wait until that PR is integrated before this is integrated.

> Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find
> 
> ```c++
>     while ((committed_rgn = itr.next()) != nullptr) {
>       print_committed_rgn(committed_rgn);
>     }
> ```
> 
> simpler and more compact, hence easier to understand, than
> 
> ```c++
>     CommittedMemoryRegion cmr;
>     VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) {
>       print_committed_rgn(crgn);
>       return true;
>     });
> ```

Hi Gerard, I'm the one who prefers passing in a lambda and introduced that style, sorry :-).

First off, I think the lambda code should be simplified, it should be:

```c++
VMWT::tree().visit_committed_regions_of(*reserved_rgn, [](const CommittedMemoryRegion& crgn) {
  print_committed_region(crgn));
  return true;
});


I don't think that's too bad, right? The `return true` is a bit unfortunate. It's for being able to stop early, which I agree that regular iterators do better by just performing a `break;`.

I'll go ahead and say one nice thing too: If the body of the lambda is a bit more complicated, then we can look at the capture list (the `[]` above) to see what the lambda can alter in the outside scope. With a while-loop, you really have to read the whole thing.

**The reason** that I write these kinds of iterators is that they're much simpler to implement and maintain and, *to me*, STL-style iterators aren't easier to read, it's about the same level of complexity.

I'll admit that your style of iterators (which are *not* STL) is about the same complexity, though I find it unfortunate that we have to write an entire class for each iterator.

With the simplifications I made, is this style of iterator acceptable?

It seems like there's a bug with the virtual memory walker. Essentially, the thread stack walker extends the reserved memory region that's passed in, but we don't save the results of that addition. This is missed because the `SnapshotThreadStackWalker` casts away the `const` of the `const ReservedMemoryRegion*`.

```c++
// All code is in vmtCommon.cpp
void VirtualMemoryTracker::Instance::snapshot_thread_stacks() {
  SnapshotThreadStackWalker walker;
  walk_virtual_memory(&walker);
}
// ...
       while (itr.next_committed(committed_start, committed_size)) {
        assert(committed_start != nullptr, "Should not be null");
        assert(committed_size > 0, "Should not be 0");
        // unaligned stack_size case: correct the region to fit the actual stack_size
        if (stack_bottom + stack_size < committed_start + committed_size) {
          committed_size = stack_bottom + stack_size - committed_start;
        }
        region->add_committed_region(committed_start, committed_size, ncs); // <-- LOST!
        DEBUG_ONLY(found_stack = true;)
      }


This particular walker should probably be re-written to only use the `VMATree` facilities. Note that we can't do the insertion in the iteration loop, as our iterator will be invalidated. They must be accumulated first, and then inserted all at once.

Is this part of the code under-tested as we didn't receive a test failure regarding this?

src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 262:

> 260:     vm_exit_out_of_memory(word_size * BytesPerWord, OOM_MMAP_ERROR, "Failed to reserve memory for metaspace");
> 261:   }
> 262:   assert(rs.size() == word_size * BytesPerWord, " must be");

" must be" -> "must be"

src/hotspot/share/nmt/memReporter.cpp line 442:

> 440:   if (all_committed) {
> 441:     bool reserved_and_committed = false;
> 442:     VirtualMemoryTracker::Instance::tree()->visit_committed_regions(*reserved_rgn,

Change the signature of `visit_committed_regions` to taking `(position start, size size)` instead of the `ReservedMemoryRegion`.

src/hotspot/share/nmt/memReporter.cpp line 458:

> 456:   }
> 457: 
> 458:   auto print_committed_rgn = [&](CommittedMemoryRegion* crgn) {

`crgn` can be const reference instead of pointer.

src/hotspot/share/nmt/memTracker.hpp line 291:

> 289:   // Query lock
> 290:   static Mutex*           _query_lock;
> 291: 

Remove

src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 93:

> 91: 
> 92:   const inline NativeCallStack& get(StackIndex si) {
> 93:     if (is_invalid(si) || si >= _stacks.length()) {

I don't think this should be here?

src/hotspot/share/nmt/regionsTree.cpp line 33:

> 31:         log_debug(nmt)("trc base: " INTPTR_FORMAT " , trc end: " INTPTR_FORMAT,
> 32:                       p2i(region_in_tree.base()), p2i(region_in_tree.end()));
> 33:       }

Remove `with_trace` and improve the logging message. This should log unconditionally, probably under a `(nmt,vmtracker)` tagset.

src/hotspot/share/nmt/regionsTree.cpp line 50:

> 48:   ReservedMemoryRegion rgn = find_reserved_region(addr);
> 49:   return reserve_mapping((VMATree::position)addr, size, make_region_data(NativeCallStack::empty_stack(), rgn.mem_tag()));
> 50: }

Can now be fixed.

src/hotspot/share/nmt/regionsTree.cpp line 52:

> 50:     rgn = find_reserved_region(addr, true);
> 51:     ShouldNotReachHere();
> 52:   }

TODO: Remove this when 8335091 is merged

src/hotspot/share/nmt/regionsTree.cpp line 54:

> 52:   }
> 53:   return commit_mapping((VMATree::position)addr, size, make_region_data(stack, rgn.flag()));
> 54: 

Style: Extra space

src/hotspot/share/nmt/regionsTree.cpp line 64:

> 62:     rgn = find_reserved_region(addr, true);
> 63:     ShouldNotReachHere();
> 64:   }

TODO: Remove this when https://github.com/openjdk/jdk/commit/8335091a5dd9a0654d9a616addcfdcc1863747ca is merged

src/hotspot/share/nmt/regionsTree.hpp line 31:

> 29: #include "nmt/vmatree.hpp"
> 30: 
> 31: class RegionsTree : public VMATree {

Is it necessary for this to be a superclass? Seems like this class contains utilities for working with a `VMATree`. Could it instead be `AllStatic` and take a tree as its first argument? I'd like to avoid inheritance unless necessary (typically for the usage of virtual functions).

src/hotspot/share/nmt/regionsTree.hpp line 33:

> 31: class RegionsTree : public VMATree {
> 32:  private:
> 33:   NativeCallStackStorage* _ncs_storage;

No need for this to be a pointer.

src/hotspot/share/nmt/regionsTree.hpp line 38:

> 36:  public:
> 37:   RegionsTree(bool with_storage) : VMATree() , _ncs_storage(with_storage) { }
> 38: 

Whitespace

src/hotspot/share/nmt/regionsTree.hpp line 46:

> 44:   using Node = VMATree::TreapNode;
> 45: 
> 46:   class NodeHelper : public Node {

This shouldn't inherit from `Node` and then have each instance be cast into `NodeHelper`. Make into `class Utils : public AllStatic`.

src/hotspot/share/nmt/regionsTree.hpp line 47:

> 45: 
> 46:   class NodeHelper {
> 47:       Node *_node;

Style: `*` should hug type, not name.

src/hotspot/share/nmt/regionsTree.hpp line 50:

> 48:       inline bool is_before(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) < 0; }
> 49:       inline bool is_after(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) > 0; }
> 50:       inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); }

Not used?

src/hotspot/share/nmt/regionsTree.hpp line 52:

> 50:       inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); }
> 51:       inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); }
> 52:       inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); }

Only used for debugging?

src/hotspot/share/nmt/regionsTree.hpp line 53:

> 51:       inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); }
> 52:       inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); }
> 53:       inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); }

Only used for debugging?

src/hotspot/share/nmt/regionsTree.hpp line 58:

> 56:       // inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); }
> 57:       // inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); }
> 58:       // inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); }

No commented out code like this please.

src/hotspot/share/nmt/regionsTree.hpp line 61:

> 59:       inline VMATree::StateType out_state() { return val().out.type(); }
> 60:       inline size_t distance_from(NodeHelper* other) { return key() - other->key(); }
> 61:       inline const NativeCallStack& stack(NativeCallStackStorage* ncss) { return ncss->get(val().in.stack()); }

Remove this

src/hotspot/share/nmt/regionsTree.hpp line 66:

> 64:       inline VMATree::StateType out_state() { return _node->val().out.type(); }
> 65:       inline size_t distance_from(NodeHelper& other) { return position() - other.position(); }
> 66:       inline const NativeCallStackStorage::StackIndex out_stack_index() { return _node->val().out.stack(); }

Unnecessary const in return type.

src/hotspot/share/nmt/regionsTree.hpp line 71:

> 69:       inline void set_in_flag(MEMFLAGS flag) { _node->val().in.set_flag(flag); }
> 70:       inline void set_out_flag(MEMFLAGS flag) { _node->val().out.set_flag(flag); }
> 71:       inline void dump(outputStream* st) {

`dump` is typically called `print_on` in HotSpot.

src/hotspot/share/nmt/regionsTree.hpp line 91:

> 89: 
> 90:   template<typename F> // F == bool(*)(CommittedMemoryRegion*)
> 91:   void visit_committed_regions(const ReservedMemoryRegion* rgn, CommittedMemoryRegion* cmr, F func) {

Why does it take the `ReservedMemoryRegion` as a pointer instead of a reference? There's no need to take a pointer to the `CommittedMemoryRegion`, just construct it in the function and pass it to `f`.

src/hotspot/share/nmt/regionsTree.hpp line 91:

> 89:   template<typename F> // F == bool(*)(CommittedMemoryRegion&)
> 90:   void visit_committed_regions(position start, size_t size, F func) {
> 91:     size_t end = start + size + 1;

It's not clear to me why `+ 1` is needed. If we have a range `[start, size+start)`, will it be missed by `visit_range_in_order`?

src/hotspot/share/nmt/regionsTree.hpp line 95:

> 93:     size_t end = (size_t)rgn->end();
> 94:     size_t comm_size = 0;
> 95:     size_t base = (size_t)rgn->base();

Why casting these?

src/hotspot/share/nmt/regionsTree.hpp line 108:

> 106:             CommittedMemoryRegion cmr((address)base, comm_size, st);
> 107:             comm_size = 0;
> 108:             prev.clear_node();

This is unneeded.

src/hotspot/share/nmt/regionsTree.hpp line 140:

> 138:         if (r_size != rgn_size) {
> 139:           log_debug(nmt)("----------------- size differ, distance: " SIZE_FORMAT " size: " SIZE_FORMAT, r_size, rgn_size);
> 140:         }

Not needed anymore?

src/hotspot/share/nmt/regionsTree.hpp line 143:

> 141:     visit_in_order([&](Node* node) {
> 142:       NodeHelper* curr = (NodeHelper*)node;
> 143:       /*

Delete

src/hotspot/share/nmt/regionsTree.hpp line 172:

> 170:   inline const NativeCallStack stack(NodeHelper& node) {
> 171:     NativeCallStackStorage::StackIndex si = node.out_stack_index();
> 172:     if (!si.is_invalid()) {

Change check to `NativeCallStackStorage::is_invalid`.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 101:

> 99: }
> 100: 
> 101: void VirtualMemoryTrackerWithTree::apply_summary_diff(VMATree::SummaryDiff diff) {

Applying a summary diff in the MemoryFileTracker is this:

```c++
  for (int i = 0; i < mt_number_of_types; i++) {
    VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_flag(i));
    summary->reserve_memory(diff.flag[i].commit);
    summary->commit_memory(diff.flag[i].commit);
  }


This is much simpler and doesn't require looking at signs and so on.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 109:

> 107:       return true;
> 108:     });
> 109: }

TODO: This should be replaced with the implementation in 8340103

Will happen when that PR has been reviewed and integrated.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 115:

> 113:                       " vms-committed: " SIZE_FORMAT,
> 114:                       str, NMTUtil::flag_to_name(flag), r, c, reserved, committed);
> 115:     };

Move this up to before the loop.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 34:

> 32: #include "utilities/ostream.hpp"
> 33: 
> 34: class VirtualMemoryTrackerWithTree : AllStatic {

Can this class be redone to use the same pattern as `MemoryFileTracker` with an outer class that's not static and an inner class that's stack, storing an instance of the outer class? That makes testing the class by creating an instance of it possible, unlike our old tests.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 41:

> 39:   VirtualMemoryTrackerWithTree(bool is_detailed_mode) : _tree(is_detailed_mode) { }
> 40: 
> 41:   bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone);

Style: Align open paren with other functions.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 64:

> 62:   void apply_summary_diff(VMATree::SummaryDiff diff);
> 63:   RegionsTree* tree() { return &_tree; }
> 64:   class Instance : public AllStatic {

Style: Newline to separate the new class to the getter above.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 67:

> 65:     friend class VirtualMemoryTrackerTest;
> 66:     friend class CommittedVirtualMemoryTest;
> 67:     friend class ReservedMemoryRegion;

Why is this necessary?

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69:

> 67: 
> 68:  private:
> 69:   static RegionsTree* _tree;

If you do the instance/static pattern then you can switch this into a regular member, no pointer necessary.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69:

> 67:     friend class ReservedMemoryRegion;
> 68: 
> 69:    private:

Unnecessary, remove.

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 70:

> 68:  private:
> 69:   static RegionsTree* _tree;
> 70:   static NativeCallStackStorage* _ncs_storage;

Doesn't seem like this is ever initialized?

src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 77:

> 75: 
> 76:     static bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone);
> 77: 

Style: Extra space

src/hotspot/share/nmt/vmatree.cpp line 33:

> 31: 
> 32: const char* VMATree::statetype_strings[4] = {
> 33:   "released","reserved", "'only-committed", "committed",

Extra quote in `"only-committed"`. Why is this new state required by the way?

src/hotspot/share/nmt/vmatree.cpp line 36:

> 34: };
> 35: 
> 36: void VMATree::put_if_absent(position A, position B, StateType state, const RegionData& region_data) {

Unused.

src/hotspot/share/nmt/vmatree.hpp line 40:

> 38: // or from committed memory of a certain MEMFLAGS to committed memory of a different MEMFLAGS.
> 39: // The set of points is stored in a balanced binary tree for efficient querying and updating.
> 40: class VMATree : public AnyObj {

Why is it AnyObj now?

src/hotspot/share/nmt/vmatree.hpp line 41:

> 39: // or from committed memory of a certain MemTag to committed memory of a different MemTag.
> 40: // The set of points is stored in a balanced binary tree for efficient querying and updating.
> 41: class VMATree : public CHeapObj<mtNMT> {

Is this still needed?

src/hotspot/share/nmt/vmatree.hpp line 57:

> 55:   };
> 56: 
> 57:   enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 3 };

Why not the following?

```c++
  enum class StateType : uint8_t { Released, Reserved, Committed, COUNT };


If this particular ordering is necessary then it should be documented why.

src/hotspot/share/nmt/vmatree.hpp line 59:

> 57:   // Bit fields view: bit 0 for Reserved, bit 1 for Committed.
> 58:   // Setting a region as Committed preserves the Reserved state.
> 59:   enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 4 };

Why do we now consider `StateType` to be a bit field?

src/hotspot/share/nmt/vmatree.hpp line 234:

> 232:   }
> 233: 
> 234:   void put_if_absent(position A, position B, StateType state, const RegionData& region_data);

Not used.

src/hotspot/share/nmt/vmtCommon.cpp line 1:

> 1: /*

Is this all of the code that is still required by the reporter to be able to function?

src/hotspot/share/nmt/vmtCommon.hpp line 40:

> 38: 
> 39: 
> 40: 

A lot of excessive spaces.

src/java.base/share/classes/java/lang/String.java line 2990:

> 2988:             return this;
> 2989:         }
> 2990:         return StringConcatHelper.doConcat(this, str == null ? "null" : str);

Remove

test/hotspot/gtest/nmt/test_nmt_treap.cpp line 168:

> 166:     tty->print_cr("d1: %lf, d2: %lf, d2/d1: %lf", d1, d2, d2 / d1);
> 167:     EXPECT_LT((int)(d2 / d1), N2 / N1);
> 168:   }

1000 and 10_000 elements are both quite small, isn't one measurement prone to being slower than expected due to unforeseen circumstances? For example, if `malloc` performs a heavy allocation (by mapping in a few new  pages) during the 10_000 elements insertion then that may stall enough that the `EXPECT_LT` fails. We are also bound to only performing the test once.

Is your thinking that these perf tests should be kept in, or should they be removed before integrating?

test/hotspot/gtest/nmt/test_vmatree.cpp line 368:

> 366: }
> 367: 
> 368: TEST_VM_F(NMTVMATreeTest, SummaryAccounting_dup) {

Better name for the test, please avoid underscores in test names. I know, we have underscores in places in Hotspot, but it's a good rule for GTest naming.

test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java line 123:

> 121:             checkCommitted(output, addrC, commitSize, "128KB");
> 122:             checkCommitted(output, addrE, commitSize, "128KB");
> 123:             System.out.println(output.getStdout());

Shouldn't be here?

-------------

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2214987478
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2216996817
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2218354564
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2229844713
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2309488897
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2330835910
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2363917957
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2277599150
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410656300
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1776822998
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797708571
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797709609
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797709829
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1776830627
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710529
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1802524769
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763180620
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763179219
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763181328
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702620226
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702613618
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710838
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711201076
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763121326
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711202054
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711202833
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711203437
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763122189
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711204473
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763087825
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763114280
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711194217
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1803020903
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711195818
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710967
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711165
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711102998
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763084724
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701512262
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763130736
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701507820
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702621499
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763078198
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763079618
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763080836
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703756244
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763081303
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1702615789
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763078450
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711711
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711641
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701493261
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711401
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703759119
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1763128004
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797711940
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797712152
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797712349
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701486398
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701503355
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1701513351
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797712911

From azafari at openjdk.org  Fri Nov  8 10:51:33 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:33 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>

On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Thanks for your comments. They are replied or applied.

More fixes and questions.

Review comments applied.

The comments are applied.

Performance test runs insert/remove operations for SortedLinkList (SLL in the code) and Treap and expects that Treap be faster. Both tests pass with a factor of 70+ faster for 10000 elements.

Dear reviewers in recent commit the following can be considered: 
### Changes made to the code
- Instance/Static implemented.
- Using of Reference instead of pointers, as much as possible.
- Removed extra un-needed args from functions
- `NodeHelper` is implemented using composition approach.
- Non-used methods are removed from `NodeHelper`

### Still open conversations from previous reviews
- Two alternatives for implementing `apply_summary_diff`
- Is readability improved after latest changes?
- Are `lambda` usages acceptable now? Any improvement suggestion?
- Which pointers still remained to be replaced by references?

GHA failures are for some tests that have already a related JBS issue, not for this PR.

> ```c++
> region->add_committed_region(committed_start, committed_size, ncs); // <-- LOST!
> ```

The `region` is not a VMATree::node, it is a `ReservedMemoryRegion*`.

Dear @tstuefe, this PR has been reviewed couple of rounds. Would you please, give your feedback? 
Thanks.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2217791061
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2219547262
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2333278135
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2365877947
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2273208292
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2283953888
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2380017488
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410734124
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2462154991

From gziemski at openjdk.org  Fri Nov  8 10:51:37 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 8 Nov 2024 10:51:37 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
Message-ID: <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>

On Thu, 1 Aug 2024 15:44:32 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>  - Adding a runtime flag for selecting the old or new version can be added later.
>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.

Changes requested by gziemski (Reviewer).

Changes requested by gziemski (Reviewer).

More review feedback...

Changes requested by gziemski (Reviewer).

Are we keeping both the linked list based and VMATree based implementations just for the review process, and we will drop the linked list one, once we are done with the review, or are they both going to be checked in?

Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find 


    while ((committed_rgn = itr.next()) != nullptr) {
      print_committed_rgn(committed_rgn);
    }


simpler and more compact, hence easier to understand, than


    CommittedMemoryRegion cmr;
    VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) {
      print_committed_rgn(crgn);
      return true;
    });

Same here:


    if (MemTracker::is_using_tree()) {
      CommittedMemoryRegion cmr;
      bool reserved_and_committed = false;
      VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn,
                                                                    &cmr,
                                                                    [&](CommittedMemoryRegion* committed_rgn) {
        if (committed_rgn->size() == reserved_rgn->size() && committed_rgn->call_stack()->equals(*stack)) {
          // One region spanning the entire reserved region, with the same stack trace.
          // Don't print this regions because the "reserved and committed" line above
          // already indicates that the region is committed.
          reserved_and_committed = true;
          return false;
        }
        return true;
      });

      if (reserved_and_committed)
        return;
    }
  }


We are setting `reserved_and_committed` inside lambda, then we need to check it outside. It's messy and harder to follow which `return` belongs to which context.

> > Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find
> > ```c++
> >     while ((committed_rgn = itr.next()) != nullptr) {
> >       print_committed_rgn(committed_rgn);
> >     }
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > simpler and more compact, hence easier to understand, than
> > ```c++
> >     CommittedMemoryRegion cmr;
> >     VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) {
> >       print_committed_rgn(crgn);
> >       return true;
> >     });
> > ```
> 
> Hi Gerard, I'm the one who prefers passing in a lambda and introduced that style, sorry :-).
> 
> First off, I think the lambda code should be simplified, it should be:
> 
> ```c++
> VMWT::tree().visit_committed_regions_of(*reserved_rgn, [](const CommittedMemoryRegion& crgn) {
>   print_committed_region(crgn));
>   return true;
> });
> ```
> 
> I don't think that's too bad, right? The `return true` is a bit unfortunate. It's for being able to stop early, which I agree that regular iterators do better by just performing a `break;`.
> 
> I'll go ahead and say one nice thing too: If the body of the lambda is a bit more complicated, then we can look at the capture list (the `[]` above) to see what the lambda can alter in the outside scope. With a while-loop, you really have to read the whole thing.
> 
> **The reason** that I write these kinds of iterators is that they're much simpler to implement and maintain and, _to me_, STL-style iterators aren't easier to read, it's about the same level of complexity.
> 
> I'll admit that your style of iterators (which are _not_ STL) is about the same complexity, though I find it unfortunate that we have to write an entire class for each iterator.
> 
> With the simplifications I made, is this style of iterator acceptable?

hi Johan,

Yes, this does look better. I looked at https://www.geeksforgeeks.org/when-to-use-lambda-expressions-instead-of-functions-in-cpp to see when one should consider using lambda and I like one particular scenario - improving readability by implementing the code locally, so one can see exactly what is going on without having to look inside a function. I think this is our use case scenario here.

If only we didn't need all those `return` statements, I'd have clearly preferred lambda here in fact.

Is the plan to check-in the fix with both paths? Or are we going to remove the linked-list based one after the review?

Did you consider using the single lambda in `report_virtual_memory_region()` as I suggested?


outputStream* out = output();
const char* scale = current_scale();
auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack, 
                     MEMFLAGS mem_type = MEMFLAGS::mtNone,
                     const char* region_type = "committed",
                     bool committed = true) {
  // Don't report if size is too small
  if (amount_in_current_scale(rgn->size()) == 0) return;
  out->cr();
  INDENT_BY(committed?8:0,
            print_virtual_memory_region(region_type, rgn->base(), rgn->size());
            if (stack->is_empty()) {
    out->cr(); } else {
      if (!committed) {
        out->print(" for %s", NMTUtil::flag_to_name(mem_type));
      } out->print_cr(" from ");
      INDENT_BY(4, _stackprinter.print_stack(stack);)
    }
  )
};



and then:


bool all_committed = reserved_rgn->size() == reserved_rgn->committed_size();
const char* region_type = (all_committed ? "reserved and committed" : "reserved");
print_rgn(reserved_rgn, reserved_rgn->call_stack(), reserved_rgn->flag(), region_type, false);



and


if (MemTracker::is_using_sorted_link_list()) {
  CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions();
  CommittedMemoryRegion* crgn;
  while ((crgn = itr.next()) != nullptr) {
    print_rgn(crgn, crgn->call_stack());
  }
}
if (MemTracker::is_using_tree()) {
  VirtualMemoryTrackerWithTree::Instance::tree()->visit_committed_regions(*reserved_rgn, [&](CommittedMemoryRegion& crgn) {
    print_rgn(&crgn, crgn.call_stack()); 
    return true;
  });
}

I honestly do not think we should be checking in 2 implementations, unless they are nicely hidden away. I do not like the way we manage them right now with 2 explicit `if` checks, each and every time we need to do something.

If you could push the 2 implementations into a factory class, so that instead of:


   if (is_using_sorted_link_list())
       VirtualMemoryTracker::snapshot_thread_stacks();
     if (is_using_tree())
       VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks();


we have just:

`  VirtualMemoryTracker::snapshot_thread_stacks();
`
and 


  VirtualMemoryTracker::VirtualMemoryTracker(bool useLinkedList) {
    if (useLinkedList) {
      instance = new VirtualMemoryTrackerWithLinkedList()
    } else {
      instance = new VirtualMemoryTrackerWithLinkedList()
    }
  }
  
  VirtualMemoryTracker::snapshot_thread_stacks() {
    instance.snapshot_thread_stacks();
  }

I still haven't run the benchmarks to verify the speed increase promise. Ideally, I would like to do this with my mechanism, but will only do it, if I can manage it without getting sucked into working on the mechanism itself.

I will definitively want to run the provided microbenchmarks though.

src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 279:

> 277:                                 "Cannot commit verification bitmap memory");
> 278:     }
> 279:     MemTracker::record_virtual_memory_type(verify_bitmap.base(), verify_bitmap..size(), mtGC);

Does this even compile?

src/hotspot/share/nmt/memReporter.cpp line 440:

> 438:   if (all_committed) {
> 439:     if (MemTracker::is_using_sorted_link_list()) {
> 440:     CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions();

Indentation.

src/hotspot/share/nmt/memReporter.cpp line 467:

> 465: 
> 466:       if (reserved_and_committed)
> 467:         return;

This looks better, but now that I got more comfortable with anonymous local functions using lambda, I think we can do better. We can write a single `print_rgn` lambda function that we can use in both "reserved" and "committed" cases:


  outputStream* out = output();
  const char* scale = current_scale();
  auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack,
                       MEMFLAGS mem_type = MEMFLAGS::mtNone,
                       const char* region_type = "committed",
                       bool committed = true) {
    // Don't report if size is too small
    if (amount_in_current_scale(rgn->size()) == 0) return;
    out->cr();
    INDENT_BY(committed?8:0,
      print_virtual_memory_region(region_type, rgn->base(), rgn->size());
      if (stack->is_empty()) {
        out->cr();
      } else {
        if (!committed) {
          out->print(" for %s", NMTUtil::flag_to_name(mem_type));
        }
        out->print_cr(" from ");
        INDENT_BY(4, _stackprinter.print_stack(stack);)
      }
    )
  };

src/hotspot/share/nmt/memReporter.cpp line 478:

> 476:     stack = committed_rgn->call_stack();
> 477:     out->cr();
> 478:     INDENT_BY(8,

This entire section looks messy and in need of some cleanup. We have lines that are only relevant to one implementation not the other, used in both. We share `committed_rgn` name between common path and old impl, then use `crgn` in the new impl.

May I suggest something like:


  auto print_committed_rgn = [&](CommittedMemoryRegion* crgn) {
    // Don't report if size is too small
    if (amount_in_current_scale(crgn->size()) == 0) return;
    stack = crgn->call_stack();
    out->cr();
    INDENT_BY(8,
      print_virtual_memory_region("committed", crgn->base(), crgn->size());
      if (stack->is_empty()) {
        out->cr();
      } else {
        out->print_cr(" from");
        INDENT_BY(4, stack->print_on(out);)
      }
    )
  };
  if (MemTracker::is_using_sorted_link_list()) {
    CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions();
    CommittedMemoryRegion* crgn;
    while ((crgn = itr.next()) != nullptr) {
      print_committed_rgn(crgn);
    }
  }
  if (MemTracker::is_using_tree()) {
    CommittedMemoryRegion cmr;
    VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) {
      print_committed_rgn(crgn);
      return true;
    });
  }

src/hotspot/share/nmt/memReporter.cpp line 482:

> 480:       } else {
> 481:         out->print_cr(" from");
> 482:         INDENT_BY(4, stack->print_on(out);)

Why aren't we using `_stackprinter` here to print, like in all the other places? 

`    INDENT_BY(4, _stackprinter.print_stack(stack);)
`

src/hotspot/share/nmt/memTracker.hpp line 67:

> 65:     if (is_using_tree())
> 66:       VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks();
> 67:   }

I'd prefer to see just:


  static void snapshot_thread_stacks() {
       VirtualMemoryTracker::snapshot_thread_stacks();
   }


and:


  static void VirtualMemoryTracker::snapshot_thread_stacks() {
     if (is_using_sorted_link_list())
       VirtualMemoryTrackerWithLinkedList::Instance::snapshot_thread_stacks();
     if (is_using_tree())
       VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks();
   }


Basically hide the two implementations and then we don't need to expose them. All the APIs such as `is_using_tree()` would not need to be public, but just implementation detail.

If we wanted to go one step further, we could create an instance of either one at the init time, then keep using that instance, instead of checking each time we want to do something.

src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 94:

> 92:     if (si._stack_index < 0 || si._stack_index >= _stacks.length()) {
> 93:       return _fake_stack;
> 94:     }

Is that a leftover from debugging?

Shouldn't this be an `assert` in final code?

src/hotspot/share/nmt/nmtTreap.hpp line 219:

> 217:       }
> 218:       last_seen = node;
> 219:       return true;

Why are we returning a `bool` value in `void` function?

src/hotspot/share/nmt/nmtTreap.hpp line 320:

> 318:       }
> 319:       head = to_visit.pop();
> 320:       if(!f(head))

Needs space `if (!f(head))`

src/hotspot/share/nmt/nmtTreap.hpp line 348:

> 346:       const int cmp_to = COMPARATOR::cmp(head->key(), to);
> 347:       if (cmp_from >= 0 && cmp_to < 0) {
> 348:         if(!f(head))

Needs space `if (!f(head))`

src/hotspot/share/nmt/nmtTreap.hpp line 356:

> 354:         head = nullptr;
> 355:       }
> 356: 

Remove.

-------------

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2228842744
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2236512021
Changes requested by gziemski (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2246166901
PR Review: https://git.openjdk.org/jdk/pull/20425#pullrequestreview-2331868978
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2276641131
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2276654335
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2276656880
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2278278886
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2307806504
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2316185120
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2377524395
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2377532616
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1777443492
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1710280816
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1717432884
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1710318264
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1715887989
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722171034
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722186507
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1777449328
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722187617
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722188013
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722188713

From azafari at openjdk.org  Fri Nov  8 10:51:38 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:38 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
Message-ID: <hc6rePUj72SsUJ5TcO7IxHIvPNXKNFTCDsAcHf9_tAQ=.d8201b02-9076-4598-bec9-a630d57d2d8c@github.com>

On Fri, 23 Aug 2024 21:02:25 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Is the plan to check-in the fix with both paths? Or are we going to remove the linked-list based one after the review?

The plan is to have both versions available at run-time. In this plan, we will add JVM options to let the user to select either of them. This can be used for: 1?? stepping back if new version fails in some use-cases, and also for 2?? running benchmarks and comparing the results of both.

> I still haven't run the benchmarks to verify the speed increase promise. Ideally, I would like to do this with my mechanism, but will only do it, if I can manage it without getting sucked into working on the mechanism itself.
> 
> I will definitively want to run the provided microbenchmarks though.

In `test_vmt_with_tree.cpp`, two versions are compared. One of the tests (`PerformanceComparison`) is comparing the time they take for the same operation. This test is skipped for now, because its expectation of time-improvement fails. Until the time we still did not merge all other related changes (like the `copy_flag` or `use_tag_inplace`, [#20330](https://github.com/openjdk/jdk/pull/20330)) to this PR we cannot expect the time to be improved.

> src/hotspot/share/gc/shenandoah/shenandoahHeap.cpp line 279:
> 
>> 277:                                 "Cannot commit verification bitmap memory");
>> 278:     }
>> 279:     MemTracker::record_virtual_memory_type(verify_bitmap.base(), verify_bitmap..size(), mtGC);
> 
> Does this even compile?

No it doesn't, you're right. Shenandoah is not in the main build.
I thought that GHA builds do this but seems not.
Fixed. Thanks.

> src/hotspot/share/nmt/memReporter.cpp line 440:
> 
>> 438:   if (all_committed) {
>> 439:     if (MemTracker::is_using_sorted_link_list()) {
>> 440:     CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions();
> 
> Indentation.

Done.

> src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 94:
> 
>> 92:     if (si._stack_index < 0 || si._stack_index >= _stacks.length()) {
>> 93:       return _fake_stack;
>> 94:     }
> 
> Is that a leftover from debugging?
> 
> Shouldn't this be an `assert` in final code?

You are right. Since the next lines check the `-1` as special case; this check should be either an `assert` or logged. I wait for @jdksjolen, as this is his code.

> src/hotspot/share/nmt/nmtTreap.hpp line 219:
> 
>> 217:       }
>> 218:       last_seen = node;
>> 219:       return true;
> 
> Why are we returning a `bool` value in `void` function?

That is returning from the lambda function.
In `visit_in_order(F func)`, when function `func` (in our case the lambda) returns `false` it means the iteration should stop. Otherwise, if it returns `true` it means to continue iterating.

> src/hotspot/share/nmt/nmtTreap.hpp line 320:
> 
>> 318:       }
>> 319:       head = to_visit.pop();
>> 320:       if(!f(head))
> 
> Needs space `if (!f(head))`

Fixed.

> src/hotspot/share/nmt/nmtTreap.hpp line 348:
> 
>> 346:       const int cmp_to = COMPARATOR::cmp(head->key(), to);
>> 347:       if (cmp_from >= 0 && cmp_to < 0) {
>> 348:         if(!f(head))
> 
> Needs space `if (!f(head))`

Done.

> src/hotspot/share/nmt/nmtTreap.hpp line 356:
> 
>> 354:         head = nullptr;
>> 355:       }
>> 356: 
> 
> Remove.

Done

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2309507439
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378923225
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778342931
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713348422
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722829439
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778361486
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722821927
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722822141
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1722822343

From jsjolen at openjdk.org  Fri Nov  8 10:51:39 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:51:39 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
Message-ID: <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com>

On Fri, 9 Aug 2024 16:05:00 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> > > Is there a concrete advantage here for using lambda expression when iterating committed regions? I'm asking because personally I find
> > > ```c++
> > >     while ((committed_rgn = itr.next()) != nullptr) {
> > >       print_committed_rgn(committed_rgn);
> > >     }
> > > ```
> > > 
> > > 
> > >     
> > >       
> > >     
> > > 
> > >       
> > >     
> > > 
> > >     
> > >   
> > > simpler and more compact, hence easier to understand, than
> > > ```c++
> > >     CommittedMemoryRegion cmr;
> > >     VirtualMemoryTrackerWithTree::tree()->visit_committed_regions(reserved_rgn, &cmr, [&](CommittedMemoryRegion* crgn) {
> > >       print_committed_rgn(crgn);
> > >       return true;
> > >     });
> > > ```
> > 
> > 
> > Hi Gerard, I'm the one who prefers passing in a lambda and introduced that style, sorry :-).
> > First off, I think the lambda code should be simplified, it should be:
> > ```c++
> > VMWT::tree().visit_committed_regions_of(*reserved_rgn, [](const CommittedMemoryRegion& crgn) {
> >   print_committed_region(crgn));
> >   return true;
> > });
> > ```
> > 
> > 
> >     
> >       
> >     
> > 
> >       
> >     
> > 
> >     
> >   
> > I don't think that's too bad, right? The `return true` is a bit unfortunate. It's for being able to stop early, which I agree that regular iterators do better by just performing a `break;`.
> > I'll go ahead and say one nice thing too: If the body of the lambda is a bit more complicated, then we can look at the capture list (the `[]` above) to see what the lambda can alter in the outside scope. With a while-loop, you really have to read the whole thing.
> > **The reason** that I write these kinds of iterators is that they're much simpler to implement and maintain and, _to me_, STL-style iterators aren't easier to read, it's about the same level of complexity.
> > I'll admit that your style of iterators (which are _not_ STL) is about the same complexity, though I find it unfortunate that we have to write an entire class for each iterator.
> > With the simplifications I made, is this style of iterator acceptable?
> 
> hi Johan,
> 
> Yes, this does look better. I looked at https://www.geeksforgeeks.org/when-to-use-lambda-expressions-instead-of-functions-in-cpp to see when one should consider using lambda and I like one particular scenario - improving readability by implementing the code locally, so one can see exactly what is going on without having to look inside a function. I think this is our use case scenario here.
> 
> If only we didn't need all those `return` statements, I'd have clearly preferred lambda here in fact.

It's tedious to have to write `return true;` if you never `return false;` in the function. I looked into fixing this with some metaprogramming, and I found two C++14 solutions and one C++17 one. Here's the Godbolt: https://godbolt.org/z/xGzoGYhf8

And here's the code, reproduced for posterity:

```c++
#include <iostream>
#include <vector>

// C++14 solution
// Here we take extra runtime cost for the void returning function
#define ENABLE_IF(...) \
  std::enable_if_t<bool(__VA_ARGS__), int> = 0


template <typename F,
          ENABLE_IF(std::is_same<bool, typename std::result_of<F(int &)>::type>::value)>
void iterate(std::vector<int>& arr, F fun) {
  for (int i = 0; i < arr.size(); i++) {
      if (!fun(arr[i])) {
        return;
      }
  }
}

template<typename F,
         ENABLE_IF(std::is_void<typename std::result_of<F(int&)>::type>::value)>
void iterate(std::vector<int>& arr, F fun) {
  iterate(arr, [&fun](int& i) {
    fun(i);
    return true;
  });
}


// C++17 solution, notice that this compiles two functions: one for when early_return is true and when for when it's not.
/*
template<typename F>
void iterate(std::vector<int>& arr, F fun) {
  using ret_type = decltype(fun(arr[0])); // This doesn't actually execute fun(arr[0]);
  constexpr bool early_return = std::is_same<ret_type, bool>::value;
  for (int i = 0; i < arr.size(); i++) {
    if constexpr (early_return) {
      if (!fun(arr[i])) {
        return;
      }
    } else {
      fun(arr[i]);
    }
  }
}
*/

// C++14 solution
// Here we have to make the two implementations ourselves.
/*
#define ENABLE_IF(...) \
  std::enable_if_t<bool(__VA_ARGS__), int> = 0


template <typename F,
          ENABLE_IF(std::is_same<bool, typename std::result_of<F(int &)>::type>::value)>
void iterate(std::vector<int>& arr, F fun) {
  for (int i = 0; i < arr.size(); i++) {
      if (!fun(arr[i])) {
        return;
      }
  }
}

template<typename F,
         ENABLE_IF(std::is_void<typename std::result_of<F(int&)>::type>::value)>
void iterate(std::vector<int>& arr, F fun) {
  for (int i = 0; i < arr.size(); i++) {
    fun(arr[i]);
  }
}
*/

int main() {
  std::vector<int> my_array{0,1,2,3};

  auto no_early = [](int& x) {
    std::cout << x << " ";
  };
  auto early = [](int &x) {
    if (x == 2) return false;
    std::cout << x << " ";
    return true;
  };
  iterate(my_array, no_early);
  std::cout << std::endl;
  iterate(my_array, early);
  std::cout << std::endl;
}

> I honestly do not think we should be checking in 2 implementations, unless they are nicely hidden away. I do not like the way we manage them right now with 2 explicit `if` checks, each and every time we need to do something.
> 
> If you could push the 2 implementations into a factory class, so that instead of:
> 
> ```
>    if (is_using_sorted_link_list())
>        VirtualMemoryTracker::snapshot_thread_stacks();
>      if (is_using_tree())
>        VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks();
> ```
> 
> we have just:
> 
> ` VirtualMemoryTracker::snapshot_thread_stacks();` and
> 
> ```
>   VirtualMemoryTracker::VirtualMemoryTracker(bool useLinkedList) {
>     if (useLinkedList) {
>       instance = new VirtualMemoryTrackerWithLinkedList()
>     } else {
>       instance = new VirtualMemoryTrackerWithLinkedList()
>     }
>   }
>   
>   VirtualMemoryTracker::snapshot_thread_stacks() {
>     instance.snapshot_thread_stacks();
>   }
> ```

>From reading the code, this might be a bit harder to do than preferred. We'd need some wrapping for the iterators, since they use two different styles. Wrapping the "old" iterators inside of the "new" style is possible of course.

The fork for JDK-24 is on December 5th. That means that we have at most 8 weeks in the testing system to find and fix any bugs that we might have missed after integration. To me, that feels a bit short. Either we wait after the fork to integrate, or we integrate with two implementations and a `java` option for choosing implementation. I'm open to other opinions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2309938825
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378890343

From gziemski at openjdk.org  Fri Nov  8 10:51:40 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 8 Nov 2024 10:51:40 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <hc6rePUj72SsUJ5TcO7IxHIvPNXKNFTCDsAcHf9_tAQ=.d8201b02-9076-4598-bec9-a630d57d2d8c@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <hc6rePUj72SsUJ5TcO7IxHIvPNXKNFTCDsAcHf9_tAQ=.d8201b02-9076-4598-bec9-a630d57d2d8c@github.com>
Message-ID: <6HDJgDRPF7OvsR5vV3FZQWph4M2wHd4mtueXuy1ldYw=.e34b1f2f-f1fe-44d9-9970-5ed8c9224aee@github.com>

On Mon, 26 Aug 2024 07:16:39 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > Is the plan to check-in the fix with both paths? Or are we going to remove the linked-list based one after the review?
> 
> The plan is to have both versions available at run-time. In this plan, we will add JVM options to let the user to select either of them. This can be used for: 1?? stepping back if new version fails in some use-cases, and also for 2?? running benchmarks and comparing the results of both.

If we are going to keep the 2 versions for a while, then I would really, really like to see the two implementations as instances of `VirtualMemoryTrackerWithLinkedList` and `VirtualMemoryTrackerWithTree`, and have `VirtualMemoryTracker` be the single class we have the external code deal with, i.e. I think we can do better that:

 ```
 static void snapshot_thread_stacks() {
    if (is_using_sorted_link_list())
      VirtualMemoryTracker::snapshot_thread_stacks();
    if (is_using_tree())
      VirtualMemoryTrackerWithTree::Instance::snapshot_thread_stacks();
  }

> > I still haven't run the benchmarks to verify the speed increase promise. Ideally, I would like to do this with my mechanism, but will only do it, if I can manage it without getting sucked into working on the mechanism itself.
> > I will definitively want to run the provided microbenchmarks though.
> 
> In `test_vmt_with_tree.cpp`, two versions are compared. One of the tests (`PerformanceComparison`) is comparing the time they take for the same operation. This test is skipped for now, because its expectation of time-improvement fails. Until the time we still did not merge all other related changes (like the `copy_flag` or `use_tag_inplace`, [#20330](https://github.com/openjdk/jdk/pull/20330)) to this PR we cannot expect the time to be improved.

Should we say then, that this is blocked by those 2 issues? Is it OK then if I wait till those get checked in before verifying the performance benefits if the new implementation? The performance was the main motivation here, correct?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2316167719
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379647798

From gziemski at openjdk.org  Fri Nov  8 10:51:40 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 8 Nov 2024 10:51:40 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com>
Message-ID: <w4DcskEFzo7nZYMys6eXGaUVMGxA7XdFPFvwLeZIJPQ=.e5c1098d-d983-4bf4-bdd7-430a8d5d2779@github.com>

On Mon, 26 Aug 2024 11:03:25 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> It's tedious to have to write return true; if you never return false; in the function. I looked into fixing this with some metaprogramming, and I found two C++14 solutions and one C++17 one. Here's the Godbolt

I'd like the lambdas without `return true` if possible, pretty please.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2316187388

From azafari at openjdk.org  Fri Nov  8 10:51:42 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:42 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
Message-ID: <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>

On Thu, 26 Sep 2024 10:58:31 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> What is the consensus on having two implementations alive at the same time? I'd like to see us delete the old VirtualMemoryTracker and only have the tree implementation left as part of this PR. What is the status of our testing? Is the tree version equivalent now and passes all tests?
> 

I have already told that the main reason to have 2 versions is to be able to switch back from new to old version at customer site at runtime. This is what Thomas has requested.
During the implementation, it is much beneficial to have access to the old version to compare the results and debug problems when they occur.
Until the whole port to VMATree is not done, we need this 2 versions side-by-side feature.

> That's good, let's wait until that PR is integrated before this is integrated.

Sure, I do.

> Is this part of the code under-tested as we didn't receive a test failure regarding this?

All JTREG runtime/NMT tests and all tier1 tests have been passed on this code.

> Note that we can't do the insertion in the iteration loop, as our iterator will be invalidated.

I meant that the iterator is not going through the nodes in VMATree. And the `add_committeed_region` is called on a local `ReservedMemoryRegion*`.

Anyway, I agree to rewrite this for many more reasons than above, but not sure how. The required change was deferred for a later time when we started new VMT. Should think about it.

> src/hotspot/share/memory/metaspace/virtualSpaceNode.cpp line 262:
> 
>> 260:     vm_exit_out_of_memory(word_size * BytesPerWord, OOM_MMAP_ERROR, "Failed to reserve memory for metaspace");
>> 261:   }
>> 262:   assert(rs.size() == word_size * BytesPerWord, " must be");
> 
> " must be" -> "must be"

Done

> src/hotspot/share/nmt/memReporter.cpp line 442:
> 
>> 440:   if (all_committed) {
>> 441:     bool reserved_and_committed = false;
>> 442:     VirtualMemoryTracker::Instance::tree()->visit_committed_regions(*reserved_rgn,
> 
> Change the signature of `visit_committed_regions` to taking `(position start, size size)` instead of the `ReservedMemoryRegion`.

Done.

> src/hotspot/share/nmt/memReporter.cpp line 458:
> 
>> 456:   }
>> 457: 
>> 458:   auto print_committed_rgn = [&](CommittedMemoryRegion* crgn) {
> 
> `crgn` can be const reference instead of pointer.

Done.

> src/hotspot/share/nmt/memTracker.hpp line 291:
> 
>> 289:   // Query lock
>> 290:   static Mutex*           _query_lock;
>> 291: 
> 
> Remove

Done.

> src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 93:
> 
>> 91: 
>> 92:   const inline NativeCallStack& get(StackIndex si) {
>> 93:     if (is_invalid(si) || si >= _stacks.length()) {
> 
> I don't think this should be here?

Removed.

> src/hotspot/share/nmt/regionsTree.cpp line 33:
> 
>> 31:         log_debug(nmt)("trc base: " INTPTR_FORMAT " , trc end: " INTPTR_FORMAT,
>> 32:                       p2i(region_in_tree.base()), p2i(region_in_tree.end()));
>> 33:       }
> 
> Remove `with_trace` and improve the logging message. This should log unconditionally, probably under a `(nmt,vmtracker)` tagset.

Done.

> src/hotspot/share/nmt/regionsTree.cpp line 50:
> 
>> 48:   ReservedMemoryRegion rgn = find_reserved_region(addr);
>> 49:   return reserve_mapping((VMATree::position)addr, size, make_region_data(NativeCallStack::empty_stack(), rgn.mem_tag()));
>> 50: }
> 
> Can now be fixed.

Done.

> src/hotspot/share/nmt/regionsTree.cpp line 52:
> 
>> 50:     rgn = find_reserved_region(addr, true);
>> 51:     ShouldNotReachHere();
>> 52:   }
> 
> TODO: Remove this when 8335091 is merged

Added a TODO comment to remind it.

> src/hotspot/share/nmt/regionsTree.cpp line 54:
> 
>> 52:   }
>> 53:   return commit_mapping((VMATree::position)addr, size, make_region_data(stack, rgn.flag()));
>> 54: 
> 
> Style: Extra space

Fixed.

> src/hotspot/share/nmt/regionsTree.cpp line 64:
> 
>> 62:     rgn = find_reserved_region(addr, true);
>> 63:     ShouldNotReachHere();
>> 64:   }
> 
> TODO: Remove this when https://github.com/openjdk/jdk/commit/8335091a5dd9a0654d9a616addcfdcc1863747ca is merged

Added a TODO comment to remind this.

> src/hotspot/share/nmt/regionsTree.hpp line 31:
> 
>> 29: #include "nmt/vmatree.hpp"
>> 30: 
>> 31: class RegionsTree : public VMATree {
> 
> Is it necessary for this to be a superclass? Seems like this class contains utilities for working with a `VMATree`. Could it instead be `AllStatic` and take a tree as its first argument? I'd like to avoid inheritance unless necessary (typically for the usage of virtual functions).

It is inherited because it is not a new type. I think that `_tree->visit_reserved_region(par1, par2)` is more readable than `VMATree::visit_reserved_region(_tree, par1, par2)`
I could not find any *virtual functions* in these classes, what do you mean by that?

> src/hotspot/share/nmt/regionsTree.hpp line 33:
> 
>> 31: class RegionsTree : public VMATree {
>> 32:  private:
>> 33:   NativeCallStackStorage* _ncs_storage;
> 
> No need for this to be a pointer.

How to use the ctor with a `bool` arg, then?

> src/hotspot/share/nmt/regionsTree.hpp line 38:
> 
>> 36:  public:
>> 37:   RegionsTree(bool with_storage) : VMATree() , _ncs_storage(with_storage) { }
>> 38: 
> 
> Whitespace

Done.

> src/hotspot/share/nmt/regionsTree.hpp line 47:
> 
>> 45: 
>> 46:   class NodeHelper {
>> 47:       Node *_node;
> 
> Style: `*` should hug type, not name.

Fixed.

> src/hotspot/share/nmt/regionsTree.hpp line 50:
> 
>> 48:       inline bool is_before(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) < 0; }
>> 49:       inline bool is_after(VMATree::position addr) { return VMATree::PositionComparator::cmp(key(), addr) > 0; }
>> 50:       inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); }
> 
> Not used?

Removed non-used methods.

> src/hotspot/share/nmt/regionsTree.hpp line 52:
> 
>> 50:       inline bool is_region_begin() { return is_reserved_begin()|| is_committed_begin(); }
>> 51:       inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); }
>> 52:       inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); }
> 
> Only used for debugging?

Done.

> src/hotspot/share/nmt/regionsTree.hpp line 53:
> 
>> 51:       inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); }
>> 52:       inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); }
>> 53:       inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); }
> 
> Only used for debugging?

Not anymore. Removed.

> src/hotspot/share/nmt/regionsTree.hpp line 58:
> 
>> 56:       // inline bool is_region_end(NodeHelper* node) { return is_released_begin() || (node != nullptr && node->out_flag() != out_flag()); }
>> 57:       // inline bool is_end_only(NodeHelper* node) { return !is_region_begin() && is_region_end(node); }
>> 58:       // inline bool is_joint(NodeHelper* node) { return is_region_begin() && is_region_end(node); }
> 
> No commented out code like this please.

OK. Fixed.

> src/hotspot/share/nmt/regionsTree.hpp line 61:
> 
>> 59:       inline VMATree::StateType out_state() { return val().out.type(); }
>> 60:       inline size_t distance_from(NodeHelper* other) { return key() - other->key(); }
>> 61:       inline const NativeCallStack& stack(NativeCallStackStorage* ncss) { return ncss->get(val().in.stack()); }
> 
> Remove this

Changed to return StackIndex.

> src/hotspot/share/nmt/regionsTree.hpp line 66:
> 
>> 64:       inline VMATree::StateType out_state() { return _node->val().out.type(); }
>> 65:       inline size_t distance_from(NodeHelper& other) { return position() - other.position(); }
>> 66:       inline const NativeCallStackStorage::StackIndex out_stack_index() { return _node->val().out.stack(); }
> 
> Unnecessary const in return type.

Fixed.

> src/hotspot/share/nmt/regionsTree.hpp line 71:
> 
>> 69:       inline void set_in_flag(MEMFLAGS flag) { _node->val().in.set_flag(flag); }
>> 70:       inline void set_out_flag(MEMFLAGS flag) { _node->val().out.set_flag(flag); }
>> 71:       inline void dump(outputStream* st) {
> 
> `dump` is typically called `print_on` in HotSpot.

`print_on` is used.

> src/hotspot/share/nmt/regionsTree.hpp line 91:
> 
>> 89: 
>> 90:   template<typename F> // F == bool(*)(CommittedMemoryRegion*)
>> 91:   void visit_committed_regions(const ReservedMemoryRegion* rgn, CommittedMemoryRegion* cmr, F func) {
> 
> Why does it take the `ReservedMemoryRegion` as a pointer instead of a reference? There's no need to take a pointer to the `CommittedMemoryRegion`, just construct it in the function and pass it to `f`.

Fixed.

> src/hotspot/share/nmt/regionsTree.hpp line 91:
> 
>> 89:   template<typename F> // F == bool(*)(CommittedMemoryRegion&)
>> 90:   void visit_committed_regions(position start, size_t size, F func) {
>> 91:     size_t end = start + size + 1;
> 
> It's not clear to me why `+ 1` is needed. If we have a range `[start, size+start)`, will it be missed by `visit_range_in_order`?

Yes it is missed.
In the `visit_range_in_order` code, the variable `cmp_to` is never checked against `0` (`cmp_to == 0`).

> src/hotspot/share/nmt/regionsTree.hpp line 95:
> 
>> 93:     size_t end = (size_t)rgn->end();
>> 94:     size_t comm_size = 0;
>> 95:     size_t base = (size_t)rgn->base();
> 
> Why casting these?

Because the args to `visit_range_in_order` are of type `position` which is `size_t`. Otherwise, compiler complains about conversion from `address` to `size_t`.

> src/hotspot/share/nmt/regionsTree.hpp line 108:
> 
>> 106:             CommittedMemoryRegion cmr((address)base, comm_size, st);
>> 107:             comm_size = 0;
>> 108:             prev.clear_node();
> 
> This is unneeded.

Which part? Why?
`clear_node()` is the same as `prev = nullptr` if pointers were used.
`is_valid()` is the same as `prev == nullptr` if pointers were used.

> src/hotspot/share/nmt/regionsTree.hpp line 140:
> 
>> 138:         if (r_size != rgn_size) {
>> 139:           log_debug(nmt)("----------------- size differ, distance: " SIZE_FORMAT " size: " SIZE_FORMAT, r_size, rgn_size);
>> 140:         }
> 
> Not needed anymore?

Removed.

> src/hotspot/share/nmt/regionsTree.hpp line 143:
> 
>> 141:     visit_in_order([&](Node* node) {
>> 142:       NodeHelper* curr = (NodeHelper*)node;
>> 143:       /*
> 
> Delete

Done.

> src/hotspot/share/nmt/regionsTree.hpp line 172:
> 
>> 170:   inline const NativeCallStack stack(NodeHelper& node) {
>> 171:     NativeCallStackStorage::StackIndex si = node.out_stack_index();
>> 172:     if (!si.is_invalid()) {
> 
> Change check to `NativeCallStackStorage::is_invalid`.

Done.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 101:
> 
>> 99: }
>> 100: 
>> 101: void VirtualMemoryTrackerWithTree::apply_summary_diff(VMATree::SummaryDiff diff) {
> 
> Applying a summary diff in the MemoryFileTracker is this:
> 
> ```c++
>   for (int i = 0; i < mt_number_of_types; i++) {
>     VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_flag(i));
>     summary->reserve_memory(diff.flag[i].commit);
>     summary->commit_memory(diff.flag[i].commit);
>   }
> 
> 
> This is much simpler and doesn't require looking at signs and so on.

In `MemoryFileTracker`, the changes in commit/reserve are applied to a local `VirtualMemorySnapshot`. Here we have to apply them to the global `VirtualMemorySummary`.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 109:
> 
>> 107:       return true;
>> 108:     });
>> 109: }
> 
> TODO: This should be replaced with the implementation in 8340103
> 
> Will happen when that PR has been reviewed and integrated.

Replaced.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 115:
> 
>> 113:                       " vms-committed: " SIZE_FORMAT,
>> 114:                       str, NMTUtil::flag_to_name(flag), r, c, reserved, committed);
>> 115:     };
> 
> Move this up to before the loop.

Done.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 34:
> 
>> 32: #include "utilities/ostream.hpp"
>> 33: 
>> 34: class VirtualMemoryTrackerWithTree : AllStatic {
> 
> Can this class be redone to use the same pattern as `MemoryFileTracker` with an outer class that's not static and an inner class that's stack, storing an instance of the outer class? That makes testing the class by creating an instance of it possible, unlike our old tests.

Can we do this change as a separate RFE? It impacts the code a lot.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 41:
> 
>> 39:   VirtualMemoryTrackerWithTree(bool is_detailed_mode) : _tree(is_detailed_mode) { }
>> 40: 
>> 41:   bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone);
> 
> Style: Align open paren with other functions.

Done.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 64:
> 
>> 62:   void apply_summary_diff(VMATree::SummaryDiff diff);
>> 63:   RegionsTree* tree() { return &_tree; }
>> 64:   class Instance : public AllStatic {
> 
> Style: Newline to separate the new class to the getter above.

Done.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 67:
> 
>> 65:     friend class VirtualMemoryTrackerTest;
>> 66:     friend class CommittedVirtualMemoryTest;
>> 67:     friend class ReservedMemoryRegion;
> 
> Why is this necessary?

Not anymore. Left over from initial tests. 
Removed.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69:
> 
>> 67: 
>> 68:  private:
>> 69:   static RegionsTree* _tree;
> 
> If you do the instance/static pattern then you can switch this into a regular member, no pointer necessary.

The `_tree` ctor to be called in `initialize` with a `bool` depending the `NMT_Level`. Existing VMT also uses a pointer to a `SortedLinkList`.
I am not sure yet: What is the advantage of not-a-pointer member? How the instance/static helps this?

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 69:
> 
>> 67:     friend class ReservedMemoryRegion;
>> 68: 
>> 69:    private:
> 
> Unnecessary, remove.

Done.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 70:
> 
>> 68:  private:
>> 69:   static RegionsTree* _tree;
>> 70:   static NativeCallStackStorage* _ncs_storage;
> 
> Doesn't seem like this is ever initialized?

Removed.

> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 77:
> 
>> 75: 
>> 76:     static bool add_reserved_region (address base_addr, size_t size, const NativeCallStack& stack, MEMFLAGS flag = mtNone);
>> 77: 
> 
> Style: Extra space

The open paren should've been aligned with other functions.
It is aligned now.

> src/hotspot/share/nmt/vmatree.cpp line 33:
> 
>> 31: 
>> 32: const char* VMATree::statetype_strings[4] = {
>> 33:   "released","reserved", "'only-committed", "committed",
> 
> Extra quote in `"only-committed"`. Why is this new state required by the way?

Removed the extra quote.
Do you remember the new bit flags for state? 
0 = Released, 1 = Reserved, 2= Committed(but not Reserved),
 3= both Reserved and Committed

> src/hotspot/share/nmt/vmatree.cpp line 36:
> 
>> 34: };
>> 35: 
>> 36: void VMATree::put_if_absent(position A, position B, StateType state, const RegionData& region_data) {
> 
> Unused.

Removed.

> src/hotspot/share/nmt/vmatree.hpp line 40:
> 
>> 38: // or from committed memory of a certain MEMFLAGS to committed memory of a different MEMFLAGS.
>> 39: // The set of points is stored in a balanced binary tree for efficient querying and updating.
>> 40: class VMATree : public AnyObj {
> 
> Why is it AnyObj now?

Mainly to be able to use `new operator`. Changed to `CheapObj<mtNMT>`.

> src/hotspot/share/nmt/vmatree.hpp line 41:
> 
>> 39: // or from committed memory of a certain MemTag to committed memory of a different MemTag.
>> 40: // The set of points is stored in a balanced binary tree for efficient querying and updating.
>> 41: class VMATree : public CHeapObj<mtNMT> {
> 
> Is this still needed?

Not anymore. Removed.

> src/hotspot/share/nmt/vmatree.hpp line 57:
> 
>> 55:   };
>> 56: 
>> 57:   enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 3 };
> 
> Why not the following?
> 
> ```c++
>   enum class StateType : uint8_t { Released, Reserved, Committed, COUNT };
> 
> 
> If this particular ordering is necessary then it should be documented why.

Done.

> src/hotspot/share/nmt/vmatree.hpp line 59:
> 
>> 57:   // Bit fields view: bit 0 for Reserved, bit 1 for Committed.
>> 58:   // Setting a region as Committed preserves the Reserved state.
>> 59:   enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 4 };
> 
> Why do we now consider `StateType` to be a bit field?

As the comments above it says, and we already had a discussion on it: The 'Committed' state now means 'Reserved and Committed'. So, when we visit nodes and check for Reserved ones, the committed nodes are also considered as Reserved. Otherwise, we would ignore the Committed nodes and continue looking for Reserved nodes.

> src/hotspot/share/nmt/vmatree.hpp line 234:
> 
>> 232:   }
>> 233: 
>> 234:   void put_if_absent(position A, position B, StateType state, const RegionData& region_data);
> 
> Not used.

Removed.

> src/hotspot/share/nmt/vmtCommon.cpp line 1:
> 
>> 1: /*
> 
> Is this all of the code that is still required by the reporter to be able to function?

Actually, it is the old `virtualMemoryTracker.hpp` that now is renamed and refined to have only common stuff for the NMT. This is included in 13 files, not only the reporter.

> src/hotspot/share/nmt/vmtCommon.hpp line 40:
> 
>> 38: 
>> 39: 
>> 40: 
> 
> A lot of excessive spaces.

Removed.

> src/java.base/share/classes/java/lang/String.java line 2990:
> 
>> 2988:             return this;
>> 2989:         }
>> 2990:         return StringConcatHelper.doConcat(this, str == null ? "null" : str);
> 
> Remove

Done. It was a merge glitch.

> test/hotspot/gtest/nmt/test_nmt_treap.cpp line 168:
> 
>> 166:     tty->print_cr("d1: %lf, d2: %lf, d2/d1: %lf", d1, d2, d2 / d1);
>> 167:     EXPECT_LT((int)(d2 / d1), N2 / N1);
>> 168:   }
> 
> 1000 and 10_000 elements are both quite small, isn't one measurement prone to being slower than expected due to unforeseen circumstances? For example, if `malloc` performs a heavy allocation (by mapping in a few new  pages) during the 10_000 elements insertion then that may stall enough that the `EXPECT_LT` fails. We are also bound to only performing the test once.
> 
> Is your thinking that these perf tests should be kept in, or should they be removed before integrating?

Generally, I think it is necessary to have performance tests to verify if any future changes do not degrade the performance.
The approach of stress testing can be agreed between us, but the tests have to exist.
In this approach, the input size is scaled N times and we expect the execution time grows as O(log(N)) which is much less than N.
This test fails and we need to have a justification for it. If approach is invalid or not correct implemented, we fix it. But the expectations remains the same.

> test/hotspot/gtest/nmt/test_vmatree.cpp line 368:
> 
>> 366: }
>> 367: 
>> 368: TEST_VM_F(NMTVMATreeTest, SummaryAccounting_dup) {
> 
> Better name for the test, please avoid underscores in test names. I know, we have underscores in places in Hotspot, but it's a good rule for GTest naming.

Done.

> test/hotspot/jtreg/runtime/NMT/VirtualAllocCommitMerge.java line 123:
> 
>> 121:             checkCommitted(output, addrC, commitSize, "128KB");
>> 122:             checkCommitted(output, addrE, commitSize, "128KB");
>> 123:             System.out.println(output.getStdout());
> 
> Shouldn't be here?

Removed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378894979
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410539689
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2410730815
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2411241108
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778343343
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799016774
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799017291
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799018897
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778343610
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799027228
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1803165698
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770961200
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770961642
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770962435
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703291746
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703292159
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799028731
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770964698
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713717938
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713466616
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713467548
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770965082
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713469220
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770966862
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770967338
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713563471
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1803163360
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713537731
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799031692
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799031982
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713721268
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770975913
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703295371
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770978952
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703295725
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703296483
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770981600
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770982361
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770986444
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704419039
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770987209
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713454670
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770988800
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799036588
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799036836
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703314202
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799037302
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704419263
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1770973856
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799038284
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799059723
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799038564
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703298094
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703300827
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703303785
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799038857

From jsjolen at openjdk.org  Fri Nov  8 10:51:43 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:51:43 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
Message-ID: <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>

On Fri, 27 Sep 2024 09:52:07 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > What is the consensus on having two implementations alive at the same time? I'd like to see us delete the old VirtualMemoryTracker and only have the tree implementation left as part of this PR. What is the status of our testing? Is the tree version equivalent now and passes all tests?
> 
> I have already told that the main reason to have 2 versions is to be able to switch back from new to old version at customer site at runtime. This is what Thomas has requested.

The issue with having two implementations is that it requires adding a new `java` option, and deprecating and removing those take 3 releases. That's 18 months of us being required to have the old version in the codebase, and being required to maintain it. I don't think that's a negligible promise to make.

Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea?

> During the implementation, it is much beneficial to have access to the old version to compare the results and debug problems when they occur. Until the whole port to VMATree is not done, we need this 2 versions side-by-side feature.

Sure, I can understand that it's nice to have both versions present during development. Right now it seems like we have a broken build, do you have any plans on having a functioning and fully featured build soon?

>> src/hotspot/share/nmt/regionsTree.hpp line 31:
>> 
>>> 29: #include "nmt/vmatree.hpp"
>>> 30: 
>>> 31: class RegionsTree : public VMATree {
>> 
>> Is it necessary for this to be a superclass? Seems like this class contains utilities for working with a `VMATree`. Could it instead be `AllStatic` and take a tree as its first argument? I'd like to avoid inheritance unless necessary (typically for the usage of virtual functions).
>
> It is inherited because it is not a new type. I think that `_tree->visit_reserved_region(par1, par2)` is more readable than `VMATree::visit_reserved_region(_tree, par1, par2)`
> I could not find any *virtual functions* in these classes, what do you mean by that?

I'm saying that inheritance is mostly useful when we have virtual functions which we can specialize, and that `VMATree` has none.

>> src/hotspot/share/nmt/regionsTree.hpp line 33:
>> 
>>> 31: class RegionsTree : public VMATree {
>>> 32:  private:
>>> 33:   NativeCallStackStorage* _ncs_storage;
>> 
>> No need for this to be a pointer.
>
> How to use the ctor with a `bool` arg, then?

The bool argument is just passed along.

```c++
  RegionsTree(bool with_storage) : VMATree(), _ncs_storage(with_storage) {
  }

>> src/hotspot/share/nmt/regionsTree.hpp line 108:
>> 
>>> 106:             CommittedMemoryRegion cmr((address)base, comm_size, st);
>>> 107:             comm_size = 0;
>>> 108:             prev.clear_node();
>> 
>> This is unneeded.
>
> Which part? Why?
> `clear_node()` is the same as `prev = nullptr` if pointers were used.
> `is_valid()` is the same as `prev == nullptr` if pointers were used.

Because you immediately reassign `prev` to `curr` in L114 it's not necessary to first call `clear_node`.

>> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.cpp line 101:
>> 
>>> 99: }
>>> 100: 
>>> 101: void VirtualMemoryTrackerWithTree::apply_summary_diff(VMATree::SummaryDiff diff) {
>> 
>> Applying a summary diff in the MemoryFileTracker is this:
>> 
>> ```c++
>>   for (int i = 0; i < mt_number_of_types; i++) {
>>     VirtualMemory* summary = file->_summary.by_type(NMTUtil::index_to_flag(i));
>>     summary->reserve_memory(diff.flag[i].commit);
>>     summary->commit_memory(diff.flag[i].commit);
>>   }
>> 
>> 
>> This is much simpler and doesn't require looking at signs and so on.
>
> In `MemoryFileTracker`, the changes in commit/reserve are applied to a local `VirtualMemorySnapshot`. Here we have to apply them to the global `VirtualMemorySummary`.

Yeah, that doesn't seem like a problem.

```c++
  for (int i = 0; i < mt_number_of_types; i++) {
    r = diff.flag[i].reserve;
    c = diff.flag[i].commit;
    flag = NMTUtil::index_to_flag(i);
    VirtualMemory* mem = VirtualMemorySummary::as_snapshot()->by_type(flag);
    reserved = mem->reserved();
    committed = mem->committed();
    mem->reserve_memory(r);
    mem->commit_memory(c);
    if ((size_t)-r > reserved) {
      print_err("release");
    }
    if ((size_t)-c > reserved || (size_t)c > committed) {
      print_err("uncommit");
    }
  }

>> src/hotspot/share/nmt/virtualMemoryTrackerWithTree.hpp line 34:
>> 
>>> 32: #include "utilities/ostream.hpp"
>>> 33: 
>>> 34: class VirtualMemoryTrackerWithTree : AllStatic {
>> 
>> Can this class be redone to use the same pattern as `MemoryFileTracker` with an outer class that's not static and an inner class that's stack, storing an instance of the outer class? That makes testing the class by creating an instance of it possible, unlike our old tests.
>
> Can we do this change as a separate RFE? It impacts the code a lot.

Then just invert it: Have the outer class be static and the inner class be an instance. We can change the `MemoryFileTracker` to be that, as it's not as large of a change.

>> src/hotspot/share/nmt/vmatree.hpp line 59:
>> 
>>> 57:   // Bit fields view: bit 0 for Reserved, bit 1 for Committed.
>>> 58:   // Setting a region as Committed preserves the Reserved state.
>>> 59:   enum class StateType : uint8_t { Reserved = 1, Committed = 3, Released = 0, COUNT = 4 };
>> 
>> Why do we now consider `StateType` to be a bit field?
>
> As the comments above it says, and we already had a discussion on it: The 'Committed' state now means 'Reserved and Committed'. So, when we visit nodes and check for Reserved ones, the committed nodes are also considered as Reserved. Otherwise, we would ignore the Committed nodes and continue looking for Reserved nodes.

Right, I don't remember the discussion on this being a bit field. I agree, though, Committed also means Reserved, but it's not necessary to express that as a bit field. Regardless, I leave it up to you how we express this.

>> test/hotspot/gtest/nmt/test_nmt_treap.cpp line 168:
>> 
>>> 166:     tty->print_cr("d1: %lf, d2: %lf, d2/d1: %lf", d1, d2, d2 / d1);
>>> 167:     EXPECT_LT((int)(d2 / d1), N2 / N1);
>>> 168:   }
>> 
>> 1000 and 10_000 elements are both quite small, isn't one measurement prone to being slower than expected due to unforeseen circumstances? For example, if `malloc` performs a heavy allocation (by mapping in a few new  pages) during the 10_000 elements insertion then that may stall enough that the `EXPECT_LT` fails. We are also bound to only performing the test once.
>> 
>> Is your thinking that these perf tests should be kept in, or should they be removed before integrating?
>
> Generally, I think it is necessary to have performance tests to verify if any future changes do not degrade the performance.
> The approach of stress testing can be agreed between us, but the tests have to exist.
> In this approach, the input size is scaled N times and we expect the execution time grows as O(log(N)) which is much less than N.
> This test fails and we need to have a justification for it. If approach is invalid or not correct implemented, we fix it. But the expectations remains the same.

Why would the execution time grow logarithmically when we do linearly more work? When we run this with `N2` we will perform `10_000 * log(10_000, 2)` units of work, and for `N1` we will perform `1_000 * log(1_000, 2)` units of work, approximately. A closer approximation is `O(log(1)) + O(log(2)) + ... + O(log(n))` for `n = N2` or `n = N1`.

Let's calculate that:


>>> import math
>>> def time_it(n):
...     t = 0
...     for i in range(1, n):
...             t  = t + math.log(i)
...     return [t, 3*t] # Approximate best and worst case
... 
>>> time_it(1000)
[5905.220423209189, 17715.661269627566]
>>> time_it(10_000)
[82099.71749644217, 246299.15248932652]
>>> def compare(a, b):
...     ab, aw = a
...     bb, bw = b
...     return [ bb / ab, bw / aw ]
... 
>>> compare(time_it(1000), time_it(10_000))
[13.902904821938064, 13.902904821938066]
>>> # Ouch, that's outside of our linear bound!


What I said previously also applies, especially the performance of `malloc` will impact this I suspect.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378929190
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711105506
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703735921
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799085027
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703751887
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703739805
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1776820787
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703877183

From azafari at openjdk.org  Fri Nov  8 10:51:44 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:44 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com>
Message-ID: <CHlJRaR_gnOLqCH570S05jfd2IRY7l8APflh2aBRMiI=.3e7a7dfe-9d31-4854-8216-833c77f04adb@github.com>

On Fri, 27 Sep 2024 09:49:37 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> The fork for JDK-24 is on December 5th. That means that we have at most 8 weeks in the testing system to find and fix any bugs that we might have missed after integration. To me, that feels a bit short. Either we wait after the fork to integrate, or we integrate with two implementations and a `java` option for choosing implementation. I'm open to other opinions.

Yes, time is tight. The chance of catching up the December 5th is not high.
Anyway, we have already decided to add a new JVM option to enable/disable this new VMATree ( default = disabled).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2378951599

From jsjolen at openjdk.org  Fri Nov  8 10:51:45 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:51:45 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <CHlJRaR_gnOLqCH570S05jfd2IRY7l8APflh2aBRMiI=.3e7a7dfe-9d31-4854-8216-833c77f04adb@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com>
 <CHlJRaR_gnOLqCH570S05jfd2IRY7l8APflh2aBRMiI=.3e7a7dfe-9d31-4854-8216-833c77f04adb@github.com>
Message-ID: <eRLysHyyhg-HEmBZakjLs8AHM1FOtmuQ2QfJDEK3Kwo=.64d73874-95aa-4c3d-8b90-eb19a8892513@github.com>

On Fri, 27 Sep 2024 10:22:57 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > The fork for JDK-24 is on December 5th. That means that we have at most 8 weeks in the testing system to find and fix any bugs that we might have missed after integration. To me, that feels a bit short. Either we wait after the fork to integrate, or we integrate with two implementations and a `java` option for choosing implementation. I'm open to other opinions.
> 
> Yes, time is tight. The chance of catching up the December 5th is not high. Anyway, we have already decided to add a new JVM option to enable/disable this new VMATree ( default = disabled).

I don't believe that we have decided that already. Both me and, I believe, Gerard have been negative towards the proposal to keep both implementations. I'd like to use this as an opportunity to discuss the pros and cons of different approaches, which is why I asked for your opinion on my alternative. I believe that it is very important that we all agree on the approach taken, as we will all have to deal with the consequences of that approach.

>  ( default = disabled).

Why should the default be disabled? That requires customers to explicitly pick the new tree to be used, which they are very unlikely to do. As I understand it, and correct me if I am wrong, the main goal of having two implementations is the ability to revert back in case we have bugs in the new one. If the default is to have the new implementation be disabled, then how are we ever going to find any real use bugs?

Cheers,
Johan

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379082883

From azafari at openjdk.org  Fri Nov  8 10:51:46 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:46 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
Message-ID: <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>

On Fri, 27 Sep 2024 10:10:37 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Sure, I can understand that it's nice to have both versions present during development. Right now it seems like we have a broken build, do you have any plans on having a functioning and fully featured build soon?

The new commit is pushed. I will monitor the build results.

> Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea?

No objection. We can do this way.

>> It is inherited because it is not a new type. I think that `_tree->visit_reserved_region(par1, par2)` is more readable than `VMATree::visit_reserved_region(_tree, par1, par2)`
>> I could not find any *virtual functions* in these classes, what do you mean by that?
>
> I'm saying that inheritance is mostly useful when we have virtual functions which we can specialize, and that `VMATree` has none.

Done.
I used inheritance for extending a class.

>> How to use the ctor with a `bool` arg, then?
>
> The bool argument is just passed along.
> 
> ```c++
>   RegionsTree(bool with_storage) : VMATree(), _ncs_storage(with_storage) {
>   }

Done.
For my curiosity, what is the advantage?

>> Can we do this change as a separate RFE? It impacts the code a lot.
>
> Then just invert it: Have the outer class be static and the inner class be an instance. We can change the `MemoryFileTracker` to be that, as it's not as large of a change.

It is still a big change. Why not another RFE?

>> Generally, I think it is necessary to have performance tests to verify if any future changes do not degrade the performance.
>> The approach of stress testing can be agreed between us, but the tests have to exist.
>> In this approach, the input size is scaled N times and we expect the execution time grows as O(log(N)) which is much less than N.
>> This test fails and we need to have a justification for it. If approach is invalid or not correct implemented, we fix it. But the expectations remains the same.
>
> Why would the execution time grow logarithmically when we do linearly more work? When we run this with `N2` we will perform `10_000 * log(10_000, 2)` units of work, and for `N1` we will perform `1_000 * log(1_000, 2)` units of work, approximately. A closer approximation is `O(log(1)) + O(log(2)) + ... + O(log(n))` for `n = N2` or `n = N1`.
> 
> Let's calculate that:
> 
> 
>>>> import math
>>>> def time_it(n):
> ...     t = 0
> ...     for i in range(1, n):
> ...             t  = t + math.log(i)
> ...     return [t, 3*t] # Approximate best and worst case
> ... 
>>>> time_it(1000)
> [5905.220423209189, 17715.661269627566]
>>>> time_it(10_000)
> [82099.71749644217, 246299.15248932652]
>>>> def compare(a, b):
> ...     ab, aw = a
> ...     bb, bw = b
> ...     return [ bb / ab, bw / aw ]
> ... 
>>>> compare(time_it(1000), time_it(10_000))
> [13.902904821938064, 13.902904821938066]
>>>> # Ouch, that's outside of our linear bound!
> 
> 
> What I said previously also applies, especially the performance of `malloc` will impact this I suspect.

It is considered that `malloc` or other external events are the same for two cases. If we know that there might be some noise for one or another, we should check and disable them. This is the approach I have talked. How can we avoid noise from `malloc` side?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379615290
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379618102
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713461169
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704394160
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704401031
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704424029

From azafari at openjdk.org  Fri Nov  8 10:51:46 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:46 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <eRLysHyyhg-HEmBZakjLs8AHM1FOtmuQ2QfJDEK3Kwo=.64d73874-95aa-4c3d-8b90-eb19a8892513@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <4mRy8kaaZMfKM3Tat40w_WxxjqLAoH5hJO_T0fZ5UTw=.d9c9ffc2-4d8a-496a-a9aa-ef8abe9412d4@github.com>
 <CHlJRaR_gnOLqCH570S05jfd2IRY7l8APflh2aBRMiI=.3e7a7dfe-9d31-4854-8216-833c77f04adb@github.com>
 <eRLysHyyhg-HEmBZakjLs8AHM1FOtmuQ2QfJDEK3Kwo=.64d73874-95aa-4c3d-8b90-eb19a8892513@github.com>
Message-ID: <Zv-oWZnyNEGNnQRmr0I38MH7a4kqvq0pTSLS-a51Xp4=.c8bb12cb-cef2-45d4-80cf-df7f85731497@github.com>

On Fri, 27 Sep 2024 11:43:19 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Why should the default be disabled? That requires customers to explicitly pick the new tree to be used, which they are very unlikely to do. As I understand it, and correct me if I am wrong, the main goal of having two implementations is the ability to revert back in case we have bugs in the new one. If the default is to have the new implementation be disabled, then how are we ever going to find any real use bugs?

You are right. This should be defualt = enabled. Anyway, we are not going to have two versions.

> I don't believe that we have decided that already. Both me and, I believe, Gerard have been negative towards the proposal to keep both implementations. I'd like to use this as an opportunity to discuss the pros and cons of different approaches, which is why I asked for your opinion on my alternative. I believe that it is very important that we all agree on the approach taken, as we will all have to deal with the consequences of that approach.

Sorry for misunderstanding. We go for 1 version only.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379619838
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379622866

From gziemski at openjdk.org  Fri Nov  8 10:51:48 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 8 Nov 2024 10:51:48 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
Message-ID: <JOWsK6MKTPqVf6qtAb4tg3Jf68EDW-ebhrY-rZT-FtA=.8120cb46-c095-4e31-894c-81a4b07ede3a@github.com>

On Fri, 27 Sep 2024 16:05:33 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea?
> 
> No objection. We can do this way.

Thank you Afshin for agreeing and thank you Johan for clearly stating the arguments.

I was trying to think of a precedent where we shipped JDK with 2 small implementation details that were exposed via runtime flags, but nothing comes to mind...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379627354

From jsjolen at openjdk.org  Fri Nov  8 10:51:49 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:51:49 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <JOWsK6MKTPqVf6qtAb4tg3Jf68EDW-ebhrY-rZT-FtA=.8120cb46-c095-4e31-894c-81a4b07ede3a@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
 <JOWsK6MKTPqVf6qtAb4tg3Jf68EDW-ebhrY-rZT-FtA=.8120cb46-c095-4e31-894c-81a4b07ede3a@github.com>
Message-ID: <CDby60IjSpxwMsPsO-Xf-Bxes84-FmNoKVNFcQoLimM=.891d6afb-db91-414e-9a16-8a89d31c9d57@github.com>

On Fri, 27 Sep 2024 16:10:59 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> > > Rather than having 2 implementations, I'd like to see us aiming for integration for JDK-25 after forking 24, so integration in December. That would give us 6 months of ensuring stability of the new implementation before it reaches any customers. During those 6 months it will go through all of our testing multiple times over, and be used by OpenJDK developers. What do you think of this idea?
> > 
> > 
> > No objection. We can do this way.
> 
> Thank you Afshin for agreeing and thank you Johan for clearly stating the arguments.
> 
> I was trying to think of a precedent where we shipped JDK with 2 small implementation details that were exposed via runtime flags, but nothing comes to mind...

Yes, thank you Afshin for reconsidering. I do sympathise with the goal of ensuring that no user receives a faulty build.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379664905

From azafari at openjdk.org  Fri Nov  8 10:51:50 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:50 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <6HDJgDRPF7OvsR5vV3FZQWph4M2wHd4mtueXuy1ldYw=.e34b1f2f-f1fe-44d9-9970-5ed8c9224aee@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <hc6rePUj72SsUJ5TcO7IxHIvPNXKNFTCDsAcHf9_tAQ=.d8201b02-9076-4598-bec9-a630d57d2d8c@github.com>
 <6HDJgDRPF7OvsR5vV3FZQWph4M2wHd4mtueXuy1ldYw=.e34b1f2f-f1fe-44d9-9970-5ed8c9224aee@github.com>
Message-ID: <7jle3GZrJMPxgMd4AUjyDrf-jPazyOhn-2rxP9JkvqE=.e327b819-1117-4339-a069-8565fc4fd7f3@github.com>

On Fri, 27 Sep 2024 16:23:29 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

> Should we say then, that this is blocked by those 2 issues? Is it OK then if I wait till those get checked in before verifying the performance benefits if the new implementation? The performance was the main motivation here, correct?

It is not blocked, but until those 2 other PRs we cannot expect the full speed of the new VMT. There are some functions that are not efficient without those 2 PRs.
You can test VMT with your microbenchmarks but if it fails in competition give it another chance after those PRs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2379801032

From jsjolen at openjdk.org  Fri Nov  8 10:51:52 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:51:52 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>
Message-ID: <BrJxBrCGWoadK0YINpJWL5pfa2zI8i-bdps89UtAZI8=.453c979a-fd4b-49d5-a92b-4b9e37c498a0@github.com>

On Mon, 14 Oct 2024 10:24:54 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > ```c++
> > region->add_committed_region(committed_start, committed_size, ncs); // <-- LOST!
> > ```
> 
> The `region` is not a VMATree::node, it is a `ReservedMemoryRegion*`.

I don't understand what you're trying to say here. Do you see the bug that I'm talking about?

> > Is this part of the code under-tested as we didn't receive a test failure regarding this?
> 
> All JTREG runtime/NMT tests and all tier1 tests have been passed on this code.

Yes, but this code is incorrect. So we should have a test detecting this, but we do not, and so this is under-tested.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2411115944

From azafari at openjdk.org  Fri Nov  8 10:51:52 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:52 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <BrJxBrCGWoadK0YINpJWL5pfa2zI8i-bdps89UtAZI8=.453c979a-fd4b-49d5-a92b-4b9e37c498a0@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>
 <BrJxBrCGWoadK0YINpJWL5pfa2zI8i-bdps89UtAZI8=.453c979a-fd4b-49d5-a92b-4b9e37c498a0@github.com>
Message-ID: <kk9-NZlGjYnFXjciTKmsCtjRoQywj3VqZH_zRw2lRms=.953bb6c9-5ee0-4d91-9b44-5e741239aa8e@github.com>

On Mon, 14 Oct 2024 12:37:05 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> Yes, but this code is incorrect. So we should have a test detecting this, but we do not, and so this is under-tested.

This code finds committed regions within a Stack region if they are not accounted by NMT so far, IIUC.
By running this incorrect code, we may get some extra committed size in NMT reports. This is hard in NMT tests to catch. How can we expect a NMT test to measure X bytes of committed stack and not Y bytes? We need to know exactly the X and/or Y to test this code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2411263187

From jsjolen at openjdk.org  Fri Nov  8 10:51:53 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:51:53 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <kk9-NZlGjYnFXjciTKmsCtjRoQywj3VqZH_zRw2lRms=.953bb6c9-5ee0-4d91-9b44-5e741239aa8e@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>
 <BrJxBrCGWoadK0YINpJWL5pfa2zI8i-bdps89UtAZI8=.453c979a-fd4b-49d5-a92b-4b9e37c498a0@github.com>
 <kk9-NZlGjYnFXjciTKmsCtjRoQywj3VqZH_zRw2lRms=.953bb6c9-5ee0-4d91-9b44-5e741239aa8e@github.com>
Message-ID: <U4JW0DWSuWQhDEXlje6aPxWJ0fTIY6oM8XgQqRwI82o=.b28463a2-a7c7-4d41-a2b7-637b8de7c916@github.com>

On Mon, 14 Oct 2024 13:22:54 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

> > Yes, but this code is incorrect. So we should have a test detecting this, but we do not, and so this is under-tested.
> 
> This code finds committed regions within a Stack region if they are not accounted by NMT so far, IIUC. By running this incorrect code, we may get some extra committed size in NMT reports. This is hard in NMT tests to catch. How can we expect a NMT test to measure X bytes of committed stack and not Y bytes? We need to know exactly the X and/or Y to test this code.

I think it's actually the opposite: None of the committed regions will survive after this function.

This is one of those times when having the ability to create new instances of NMT makes things very nice for testing.

You simply do something like this (pseudo-code):

```c++
void test_it() {
  VMT vmt;
  size_t sz = 4096 * 16;
  void* mem = os::reserve_memory(sz, mtThreadStack);
  os::commit_memory(mem + 4096*2, 4096);
  vmt.reserve(mem, sz, mtThreadStack);
  vmt.walk_thread_stacks();
  EXPECT_EQ(4096, sum_committed_of(vmt, mtThreadStack));
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2412008724

From azafari at openjdk.org  Fri Nov  8 10:51:54 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:51:54 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <U4JW0DWSuWQhDEXlje6aPxWJ0fTIY6oM8XgQqRwI82o=.b28463a2-a7c7-4d41-a2b7-637b8de7c916@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>
 <BrJxBrCGWoadK0YINpJWL5pfa2zI8i-bdps89UtAZI8=.453c979a-fd4b-49d5-a92b-4b9e37c498a0@github.com>
 <kk9-NZlGjYnFXjciTKmsCtjRoQywj3VqZH_zRw2lRms=.953bb6c9-5ee0-4d91-9b44-5e741239aa8e@github.com>
 <U4JW0DWSuWQhDEXlje6aPxWJ0fTIY6oM8XgQqRwI82o=.b28463a2-a7c7-4d41-a2b7-637b8de7c916@github.com>
Message-ID: <_-S6hRbiAOCHQMCAL-JEHmBaEdbX_-Rokt-nXOVgqTE=.2afbb2f6-b772-4b20-9785-dba1223bafc9@github.com>

On Mon, 14 Oct 2024 18:56:47 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

> I think it's actually the opposite: None of the committed regions will survive after this function.

You maybe missed my point when said " ... some extra committed size in NMT reports". I emphasize on the " the NMT reports", since the committed sizes in this function are added to the global VirtualMemorySummary which is used in reports. 
And yes, no committed regions that added here won't survive after this function.

> This is one of those times when having the ability to create new instances of NMT makes things very nice for testing.

I was talking about the existing tests and why they couldn't catch this bug.(why this is under-tested)

> You simply do something like this (pseudo-code):

Thanks for the pseudo-code, I will implement a test for this specific case. You will see it in one of the future commits here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2413222662
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2413225089
PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2413227952

From stuefe at openjdk.org  Fri Nov  8 10:51:56 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Fri, 8 Nov 2024 10:51:56 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <oa4DEix9WYNg_jQdN1m376iIuweMvUlgiV8tdL7EhLM=.a824d979-4ef5-4115-a924-ecac3753bc15@github.com>
Message-ID: <YhGvLkCpQpxBNFZYsbbxwUJYzumBzBoEDr8cwAtOuNg=.2bf49601-c807-4ff4-987f-cbe4c220c9bf@github.com>

On Thu, 7 Nov 2024 12:48:12 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>>  - Adding a runtime flag for selecting the old or new version can be added later.
>>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.
>
> Dear @tstuefe, this PR has been reviewed couple of rounds. Would you please, give your feedback? 
> Thanks.

Hi @afshin-zafari,

I'll take a look next week.

Could you please remove draft state, so that the discussions are public on the ML?

Could you also please, to make reviewing easier and for documentation, describe the desired behavior? You should also add this description (or reuse, could be the same text) to the header/start of the implementation.

Detailed questions are:
1. where does the data structure live? E.g. "Its a global data structure". Important here is the distinction to the ZGC file mapping tracker.
2. How is the data structure guarded? (locking question)
3. how are memory reservations realized (what tree operations?) E.g. "creates a VMATree memory section with state=reserved and the given tag/stack combination". 
3.1 Do we allow reservations to overlap with existing sections? If no, why? If yes, under which conditions, and what happens to the old sections?
4. how is memory commit realized?
4.2. What happens if I specify tag and stack? Any restrictions then?
4.1. What happens if I omit tag and stack on commit? What are the restrictions?
5. same for uncommit
6. How is release done? 
7. How do we find memory sections?
8. Do we allow modifying the tag? (See @jdksjolen set_tag PR)

Here is what I think how this should work: 

NMT should normally not put any restrictions on the use of mmap APIs. It should just faithfully track what we do. However, we may want a "paranoid" mode where we bail out/warn if something looks fishy.

3. reservations should create a new tree section with the given flag/stack
3.1 there should be no restrictions. If there are old sections in that range, they are replaced. However, with paranoid mode enabled, I would warn if we reserve over committed sections because that would replace the mapping in reality. Remapping just reserved but uncommitted sections should be fine, I think. I think we do this sometimes.
4. commit should work differently when giving tag+stack, or when tag and stack are omitted. 
  4.1 if tag+stack are given, commit just creates a single new section across the range with the given tag + stack. That should always work, regardless of whats there before (paranoid off). With paranoid=on, it should warn if we commit over already Committed sections, since that destroys those sections.
   4.2) committing when tag+stack are omitted. As in "please commit what I reserved before, and just with the same tag and stack". In that case, commit just changes the tag for the range. That may or may not cause sections to coalesce (if changing the tag causes neighboring sections to have the same set of properties) or be created (if you commit middle of an existing section, and the set of properties now differs). Restrictions: there should be a clear unconditional restriction that this only works if there are no Released sections in that range, since a Released section (address holes) has no tag+stack to copy from. 
5. Uncommit should never require tag+stack. It should change the state of the range to "Reserved" and leave tag+stack alone. Again, cannot work across address space holes. It can cause the splintering of existing sections, if we uncommit the middle of a committed section.
6. Releasing should just create a new section with State=Released, tag=mtNone and no stack.

WDYT. I think it is a must to have all of this clearly specified before starting to implement, because the code is complex and one needs to know this logic beforehand.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20425#issuecomment-2463896881

From gziemski at openjdk.org  Fri Nov  8 10:51:57 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 8 Nov 2024 10:51:57 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
Message-ID: <LJ89sfxe7S_gdiGA8avLxEIL3G7b5EIuUGmwYFjdWvo=.19373288-13f6-4781-ad93-86cf246a0a1b@github.com>

On Wed, 14 Aug 2024 19:11:58 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>>  - Adding a runtime flag for selecting the old or new version can be added later.
>>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.
>
> src/hotspot/share/nmt/memReporter.cpp line 467:
> 
>> 465: 
>> 466:       if (reserved_and_committed)
>> 467:         return;
> 
> This looks better, but now that I got more comfortable with anonymous local functions using lambda, I think we can do better. We can write a single `print_rgn` lambda function that we can use in both "reserved" and "committed" cases:
> 
> 
>   outputStream* out = output();
>   const char* scale = current_scale();
>   auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack,
>                        MEMFLAGS mem_type = MEMFLAGS::mtNone,
>                        const char* region_type = "committed",
>                        bool committed = true) {
>     // Don't report if size is too small
>     if (amount_in_current_scale(rgn->size()) == 0) return;
>     out->cr();
>     INDENT_BY(committed?8:0,
>       print_virtual_memory_region(region_type, rgn->base(), rgn->size());
>       if (stack->is_empty()) {
>         out->cr();
>       } else {
>         if (!committed) {
>           out->print(" for %s", NMTUtil::flag_to_name(mem_type));
>         }
>         out->print_cr(" from ");
>         INDENT_BY(4, _stackprinter.print_stack(stack);)
>       }
>     )
>   };

The whole method here then becomes:


void MemDetailReporter::report_virtual_memory_region(const ReservedMemoryRegion* reserved_rgn) {
  assert(reserved_rgn != nullptr, "null pointer");

  // We don't bother about reporting peaks here.
  // That is because peaks - in the context of virtual memory, peak of committed areas - make little sense
  // when we report *by region*, which are identified by their location in memory. There is a philosophical
  // question about identity here: e.g. a committed region that has been split into three regions by
  // uncommitting a middle section of it, should that still count as "having peaked" before the split? If
  // yes, which of the three new regions would be the spiritual successor? Rather than introducing more
  // complexity, we avoid printing peaks altogether. Note that peaks should still be printed when reporting
  // usage *by callsite*.

  if (reserved_rgn->flag() == mtTest) {
    log_debug(nmt)("report vmem, rgn base: " INTPTR_FORMAT " size: " SIZE_FORMAT "cur-scale: " SIZE_FORMAT,
      p2i(reserved_rgn->base()), reserved_rgn->size(),amount_in_current_scale(reserved_rgn->size()));
  }

  outputStream* out = output();
  const char* scale = current_scale();
  auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack,
                       MEMFLAGS mem_type = MEMFLAGS::mtNone,
                       const char* region_type = "committed",
                       bool committed = true) {
    // Don't report if size is too small
    if (amount_in_current_scale(rgn->size()) == 0) return;
    out->cr();
    INDENT_BY(committed?8:0,
      print_virtual_memory_region(region_type, rgn->base(), rgn->size());
      if (stack->is_empty()) {
        out->cr();
      } else {
        if (!committed) {
          out->print(" for %s", NMTUtil::flag_to_name(mem_type));
        }
        out->print_cr(" from ");
        INDENT_BY(4, _stackprinter.print_stack(stack);)
      }
    )
  };

  bool all_committed = reserved_rgn->size() == reserved_rgn->committed_size();
  const char* region_type = (all_committed ? "reserved and committed" : "reserved");
  print_rgn(reserved_rgn, reserved_rgn->call_stack(), reserved_rgn->flag(), region_type, false);

  if (all_committed) {
    if (MemTracker::is_using_sorted_link_list()) {
      CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions();
      const CommittedMemoryRegion* committed_rgn = itr.next();
      if (committed_rgn->size() == reserved_rgn->size() &&
          committed_rgn->call_stack()->equals(*reserved_rgn->call_stack())) {
        // One region spanning the entire reserved region, with the same stack trace.
        // Don't print this regions because the "reserved and committed" line above
        // already indicates that the region is committed.
        assert(itr.next() == nullptr, "Unexpectedly more than one regions");
        return;
      }
    }
    if (MemTracker::is_using_tree()) {
      bool reserved_and_committed = false;
      VirtualMemoryTrackerWithTree::Instance::tree()->visit_committed_regions(*reserved_rgn,
                                                                    [&](CommittedMemoryRegion& committed_rgn) {
        if (committed_rgn.size() == reserved_rgn->size() &&
            committed_rgn.call_stack()->equals(*reserved_rgn->call_stack())) {
          // One region spanning the entire reserved region, with the same stack trace.
          // Don't print this regions because the "reserved and committed" line above
          // already indicates that the region is committed.
          reserved_and_committed = true;
          return false;
        }
        return true;
      });

      if (reserved_and_committed)
        return;
    }
  }

  if (MemTracker::is_using_sorted_link_list()) {
    CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions();
    CommittedMemoryRegion* crgn;
    while ((crgn = itr.next()) != nullptr) {
      print_rgn(crgn, crgn->call_stack());
    }
  }
  if (MemTracker::is_using_tree()) {
    VirtualMemoryTrackerWithTree::Instance::tree()->visit_committed_regions(*reserved_rgn, [&](CommittedMemoryRegion& crgn) {
      print_rgn(&crgn, crgn.call_stack());
      return true;
    });
  }
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1717435317

From gziemski at openjdk.org  Fri Nov  8 10:52:00 2024
From: gziemski at openjdk.org (Gerard Ziemski)
Date: Fri, 8 Nov 2024 10:52:00 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <LJ89sfxe7S_gdiGA8avLxEIL3G7b5EIuUGmwYFjdWvo=.19373288-13f6-4781-ad93-86cf246a0a1b@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <LJ89sfxe7S_gdiGA8avLxEIL3G7b5EIuUGmwYFjdWvo=.19373288-13f6-4781-ad93-86cf246a0a1b@github.com>
Message-ID: <WdFXEcVA-ru19dwOs6LRSQ-6gjAtsp5QHmAVBXtPzmY=.f6fe864f-3793-4bcd-b362-0f6f47a7cc65@github.com>

On Wed, 14 Aug 2024 19:13:49 GMT, Gerard Ziemski <gziemski at openjdk.org> wrote:

>> src/hotspot/share/nmt/memReporter.cpp line 467:
>> 
>>> 465: 
>>> 466:       if (reserved_and_committed)
>>> 467:         return;
>> 
>> This looks better, but now that I got more comfortable with anonymous local functions using lambda, I think we can do better. We can write a single `print_rgn` lambda function that we can use in both "reserved" and "committed" cases:
>> 
>> 
>>   outputStream* out = output();
>>   const char* scale = current_scale();
>>   auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack,
>>                        MEMFLAGS mem_type = MEMFLAGS::mtNone,
>>                        const char* region_type = "committed",
>>                        bool committed = true) {
>>     // Don't report if size is too small
>>     if (amount_in_current_scale(rgn->size()) == 0) return;
>>     out->cr();
>>     INDENT_BY(committed?8:0,
>>       print_virtual_memory_region(region_type, rgn->base(), rgn->size());
>>       if (stack->is_empty()) {
>>         out->cr();
>>       } else {
>>         if (!committed) {
>>           out->print(" for %s", NMTUtil::flag_to_name(mem_type));
>>         }
>>         out->print_cr(" from ");
>>         INDENT_BY(4, _stackprinter.print_stack(stack);)
>>       }
>>     )
>>   };
>
> The whole method here then becomes:
> 
> 
> void MemDetailReporter::report_virtual_memory_region(const ReservedMemoryRegion* reserved_rgn) {
>   assert(reserved_rgn != nullptr, "null pointer");
> 
>   // We don't bother about reporting peaks here.
>   // That is because peaks - in the context of virtual memory, peak of committed areas - make little sense
>   // when we report *by region*, which are identified by their location in memory. There is a philosophical
>   // question about identity here: e.g. a committed region that has been split into three regions by
>   // uncommitting a middle section of it, should that still count as "having peaked" before the split? If
>   // yes, which of the three new regions would be the spiritual successor? Rather than introducing more
>   // complexity, we avoid printing peaks altogether. Note that peaks should still be printed when reporting
>   // usage *by callsite*.
> 
>   if (reserved_rgn->flag() == mtTest) {
>     log_debug(nmt)("report vmem, rgn base: " INTPTR_FORMAT " size: " SIZE_FORMAT "cur-scale: " SIZE_FORMAT,
>       p2i(reserved_rgn->base()), reserved_rgn->size(),amount_in_current_scale(reserved_rgn->size()));
>   }
> 
>   outputStream* out = output();
>   const char* scale = current_scale();
>   auto print_rgn = [&](const VirtualMemoryRegion* rgn, const NativeCallStack* stack,
>                        MEMFLAGS mem_type = MEMFLAGS::mtNone,
>                        const char* region_type = "committed",
>                        bool committed = true) {
>     // Don't report if size is too small
>     if (amount_in_current_scale(rgn->size()) == 0) return;
>     out->cr();
>     INDENT_BY(committed?8:0,
>       print_virtual_memory_region(region_type, rgn->base(), rgn->size());
>       if (stack->is_empty()) {
>         out->cr();
>       } else {
>         if (!committed) {
>           out->print(" for %s", NMTUtil::flag_to_name(mem_type));
>         }
>         out->print_cr(" from ");
>         INDENT_BY(4, _stackprinter.print_stack(stack);)
>       }
>     )
>   };
> 
>   bool all_committed = reserved_rgn->size() == reserved_rgn->committed_size();
>   const char* region_type = (all_committed ? "reserved and committed" : "reserved");
>   print_rgn(reserved_rgn, reserved_rgn->call_stack(), reserved_rgn->flag(), region_type, false);
> 
>   if (all_committed) {
>     if (MemTracker::is_using_sorted_link_list()) {
>       CommittedRegionIterator itr = reserved_rgn->iterate_committed_regions();
>       const CommittedMemoryRegion* committed_rgn = itr.next();
>       if (committed_rgn->size() == reserved_rgn->...

Notice that by changing:

`INDENT_BY(4, stack->print_on(out);)`

to

`INDENT_BY(4, _stackprinter.print_stack(stack);)`

we went from:


        [0x0000000600000000 - 0x0000000620000000] committed 536870912 from
            [0x000000010ce40dfe]ReservedSpace::reserve(unsigned long, unsigned long, unsigned long, char*, bool)+0x2da[0x000000010ce41214]ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long, unsigned long, char*)+0x60[0x000000010ce413ac]ReservedHeapSpace::try_reserve_range(char*, char*, unsigned long, char*, char*, unsigned long, unsigned long, unsigned long)+0xae[0x000000010ce41571]ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned long, unsigned long)+0x1b5


to


        [0x0000000600000000 - 0x0000000620000000] committed 536870912 from 
            [0x000000010be40d4e]ReservedSpace::reserve(unsigned long, unsigned long, unsigned long, char*, bool)+0x2da
            [0x000000010be41164]ReservedHeapSpace::try_reserve_heap(unsigned long, unsigned long, unsigned long, char*)+0x60
            [0x000000010be412fc]ReservedHeapSpace::try_reserve_range(char*, char*, unsigned long, char*, char*, unsigned long, unsigned long, unsigned long)+0xae
            [0x000000010be414c1]ReservedHeapSpace::initialize_compressed_heap(unsigned long, unsigned long, unsigned long)+0x1b5


which I think is now correct, and used to be wrong.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1717438580

From azafari at openjdk.org  Fri Nov  8 10:52:03 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:03 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
Message-ID: <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com>

On Fri, 27 Sep 2024 09:46:27 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 93:
>> 
>>> 91: 
>>> 92:   const inline NativeCallStack& get(StackIndex si) {
>>> 93:     if (is_invalid(si) || si >= _stacks.length()) {
>> 
>> I don't think this should be here?
>
> Removed.

No, returned back.
This assert is triggered:

#  Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1972883, tid=1972931
#  assert(0 <= i && i < _len) failed: illegal index 0 for length 0

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1778358195

From jsjolen at openjdk.org  Fri Nov  8 10:52:03 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:03 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com>
Message-ID: <EqBwHhhXGClg93QU8xyO8hcGe120C1_eQQkWNGI4UbY=.62582027-f3cc-47f0-afb0-46d39a2d63e8@github.com>

On Fri, 27 Sep 2024 09:57:35 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Removed.
>
> No, returned back.
> This assert is triggered:
> 
> #  Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1972883, tid=1972931
> #  assert(0 <= i && i < _len) failed: illegal index 0 for length 0

Why is this assert triggered? That sounds like a bug.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1797710083

From azafari at openjdk.org  Fri Nov  8 10:52:04 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:04 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <EqBwHhhXGClg93QU8xyO8hcGe120C1_eQQkWNGI4UbY=.62582027-f3cc-47f0-afb0-46d39a2d63e8@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com>
 <EqBwHhhXGClg93QU8xyO8hcGe120C1_eQQkWNGI4UbY=.62582027-f3cc-47f0-afb0-46d39a2d63e8@github.com>
Message-ID: <SL_3K1hX_LaE83mhektCB2uzm8_U1oNm0XTzoXqTPOI=.a8c0609f-bda5-4ba0-a985-1e66ffaa0c1e@github.com>

On Sat, 12 Oct 2024 14:24:15 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> No, returned back.
>> This assert is triggered:
>> 
>> #  Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1972883, tid=1972931
>> #  assert(0 <= i && i < _len) failed: illegal index 0 for length 0
>
> Why is this assert triggered? That sounds like a bug.

The assertion that happens during building jdk-image:

#
# A fatal error has been detected by the Java Runtime Environment:
#
#  Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1234272, tid=1234278
#  assert(0 <= i && i < _len) failed: illegal index 0 for length 0
#
# JRE version:  (24.0) (fastdebug build )
# Java VM: OpenJDK 64-Bit Server VM (fastdebug 24-internal-2024-09-30-0937351.afshin..., mixed mode, emulated-client, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
# Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/afshin/scratch/833XX_nmt_VMT_with_tree/make/core.1234272)
#
#

---------------  S U M M A R Y ------------

Command Line: -Denv.class.path= -Dapplication.home=/home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk -Xms8m -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Djdk.module.main=jdk.jlink jdk.jlink/jdk.tools.jmod.Main create --module-version 24-internal --target-platform linux-amd64 --module-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/images/jmods --libs /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_libs/jdk.sctp --class-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk/modules/jdk.sctp --legal-notices /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_legal/common --exclude **{_the.*,_*.marker*,*.diz,*.debuginfo,*.dSYM/**,*.dSYM} --compress zip-1 --date 2024-09-30T09:37:57Z /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/images/jmods/jdk.sctp.jmod

Host: afshin-Precision-7920-Tower, Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 40 cores, 62G, Ubuntu 20.04.6 LTS
Time: Mon Oct 14 10:52:34 2024 CEST elapsed time: 0.002402 seconds (0d 0h 0m 0s)

---------------  T H R E A D  ---------------

Current thread is native thread

Stack: [0x00007ffa5243a000,0x00007ffa5253b000],  sp=0x00007ffa52539390,  free space=1020k
Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
V  [libjvm.so+0x18df026]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x486  (growableArray.hpp:142)
V  [libjvm.so+0x18df870]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*, ...)+0x0  (vmError.cpp:1611)
V  [libjvm.so+0xac3a81]  report_vm_error(char const*, int, char const*, char const*, ...)+0xf1  (debug.cpp:193)
V  [libjvm.so+0x15f7851]  void Treap<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, TreapCHeapAllocator>::visit_in_order<RegionsTree::visit_reserved_regions<RegionsTree::find_reserved_region(unsigned char*)::{lambda(ReservedMemoryRegion&)#1}>(RegionsTree::find_reserved_region(unsigned char*)::{lambda(ReservedMemoryRegion&)#1})::{lambda(Treap<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, TreapCHeapAllocator>::TreapNode*)#1}>(RegionsTree::visit_reserved_regions<RegionsTree::find_reserved_region(unsigned char*)::{lambda(ReservedMemoryRegion&)#1}>(RegionsTree::find_reserved_region(unsigned char*)::{lambda(ReservedMemoryRegion&)#1})::{lambda(Treap<unsigned long, VMATree::IntervalChange, VMATree::PositionComparator, TreapCHeapAllocator>::TreapNode*)#1}) const+0x4c1  (growableArray.hpp:142)
V  [libjvm.so+0x15f7b59]  RegionsTree::commit_region(unsigned char*, unsigned long, NativeCallStack const&)+0x149  (vmatree.hpp:227)
V  [libjvm.so+0x18cc8cc]  VirtualMemoryTracker::add_committed_region(unsigned char*, unsigned long, NativeCallStack const&)+0x2c  (virtualMemoryTracker.cpp:150)
V  [libjvm.so+0x14dc5b7]  os::commit_memory(char*, unsigned long, bool)+0x97  (memTracker.hpp:175)
V  [libjvm.so+0xac611f]  initialize_assert_poison()+0x7f  (debug.cpp:715)
V  [libjvm.so+0x181aecd]  Threads::create_vm(JavaVMInitArgs*, bool*)+0x53d  (threads.cpp:490)
V  [libjvm.so+0xfb4494]  JNI_CreateJavaVM+0x54  (jni.cpp:3596)
C  [libjli.so+0x432f]  JavaMain+0x8f  (java.c:1490)
C  [libjli.so+0x79b9]  ThreadJavaMain+0x9  (java_md.c:633)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1799014090

From jsjolen at openjdk.org  Fri Nov  8 10:52:04 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:04 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <SL_3K1hX_LaE83mhektCB2uzm8_U1oNm0XTzoXqTPOI=.a8c0609f-bda5-4ba0-a985-1e66ffaa0c1e@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <9UIAcuZEBgvAaPcqvejgUtwP0YJjacmOHv-I6qLPRrQ=.1c5add51-73dd-4e7f-891e-08f1cfb9a288@github.com>
 <EqBwHhhXGClg93QU8xyO8hcGe120C1_eQQkWNGI4UbY=.62582027-f3cc-47f0-afb0-46d39a2d63e8@github.com>
 <SL_3K1hX_LaE83mhektCB2uzm8_U1oNm0XTzoXqTPOI=.a8c0609f-bda5-4ba0-a985-1e66ffaa0c1e@github.com>
Message-ID: <oqMSX5srTsN1BJWxI7m6JV__K2p4ZD9JsgbFc2qe_do=.802a81da-b3d2-46d9-bbf4-2833c0b74b25@github.com>

On Mon, 14 Oct 2024 08:50:52 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Why is this assert triggered? That sounds like a bug.
>
> The assertion that happens during building jdk-image:
> 
> #
> # A fatal error has been detected by the Java Runtime Environment:
> #
> #  Internal Error (/home/afshin/scratch/833XX_nmt_VMT_with_tree/src/hotspot/share/utilities/growableArray.hpp:142), pid=1234272, tid=1234278
> #  assert(0 <= i && i < _len) failed: illegal index 0 for length 0
> #
> # JRE version:  (24.0) (fastdebug build )
> # Java VM: OpenJDK 64-Bit Server VM (fastdebug 24-internal-2024-09-30-0937351.afshin..., mixed mode, emulated-client, tiered, compressed oops, compressed class ptrs, serial gc, linux-amd64)
> # Core dump will be written. Default location: Core dumps may be processed with "/usr/share/apport/apport -p%p -s%s -c%c -d%d -P%P -u%u -g%g -- %E" (or dumping to /home/afshin/scratch/833XX_nmt_VMT_with_tree/make/core.1234272)
> #
> #
> 
> ---------------  S U M M A R Y ------------
> 
> Command Line: -Denv.class.path= -Dapplication.home=/home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk -Xms8m -XX:+UseSerialGC -Xms32M -Xmx512M -XX:TieredStopAtLevel=1 -Djdk.module.main=jdk.jlink jdk.jlink/jdk.tools.jmod.Main create --module-version 24-internal --target-platform linux-amd64 --module-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/images/jmods --libs /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_libs/jdk.sctp --class-path /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/jdk/modules/jdk.sctp --legal-notices /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/modules_legal/common --exclude **{_the.*,_*.marker*,*.diz,*.debuginfo,*.dSYM/**,*.dSYM} --compress zip-1 --date 2024-09-30T09:37:57Z /home/afshin/scratch/833XX_nmt_VMT_with_tree/build/linux-x64/support/images/jmods/jdk.sctp.jmod
> 
> Host: afshin-Precision-7920-Tower, Intel(R) Xeon(R) Silver 4114 CPU @ 2.20GHz, 40 cores, 62G, Ubuntu 20.04.6 LTS
> Time: Mon Oct 14 10:52:34 2024 CEST elapsed time: 0.002402 seconds (0d 0h 0m 0s)
> 
> ---------------  T H R E A D  ---------------
> 
> Current thread is native thread
> 
> Stack: [0x00007ffa5243a000,0x00007ffa5253b000],  sp=0x00007ffa52539390,  free space=1020k
> Native frames: (J=compiled Java code, j=interpreted, Vv=VM code, C=native code)
> V  [libjvm.so+0x18df026]  VMError::report_and_die(int, char const*, char const*, __va_list_tag*, Thread*, unsigned char*, void*, void*, char const*, int, unsigned long)+0x486  (growableArray.hpp:142)
> V  [libjvm.so+0x18df870]  VMError::report_and_die(Thread*, void*, char const*, int, char const*, char const*,...

OK, so there's a bug in the new VMT. You should be getting the command run so that you can reproduce it in gdb. If not, you can add `LOG=cmdlines` as an environment variable before building.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1802521408

From jsjolen at openjdk.org  Fri Nov  8 10:52:05 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:05 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <hc6rePUj72SsUJ5TcO7IxHIvPNXKNFTCDsAcHf9_tAQ=.d8201b02-9076-4598-bec9-a630d57d2d8c@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <EOuTTycP6Ha4EbFcKFcAVxVkp6aTwsmSgHLvLLd6WvA=.2c2f817a-851a-41a6-850b-99672c849d26@github.com>
 <hc6rePUj72SsUJ5TcO7IxHIvPNXKNFTCDsAcHf9_tAQ=.d8201b02-9076-4598-bec9-a630d57d2d8c@github.com>
Message-ID: <YC-luVkHqkgt_AHPyJaya3AF01RQAZO8E6oLljVnaDI=.62186a90-a180-4f5d-89da-dd404e789dcb@github.com>

On Tue, 20 Aug 2024 07:33:06 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> src/hotspot/share/nmt/nmtNativeCallStackStorage.hpp line 94:
>> 
>>> 92:     if (si._stack_index < 0 || si._stack_index >= _stacks.length()) {
>>> 93:       return _fake_stack;
>>> 94:     }
>> 
>> Is that a leftover from debugging?
>> 
>> Shouldn't this be an `assert` in final code?
>
> You are right. Since the next lines check the `-1` as special case; this check should be either an `assert` or logged. I wait for @jdksjolen, as this is his code.

Old code, delete it. No logging for this. You can always add an assert for `si._stack_index >= _stacks.length()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1731029704

From jsjolen at openjdk.org  Fri Nov  8 10:52:05 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:05 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
Message-ID: <6o6kdvS3Uy-Fq1bbRBmiPYvV7ztF6Urm0x5lkfgA2kY=.9e576627-d4cb-47a9-a916-59687afa11b5@github.com>

On Mon, 5 Aug 2024 16:50:00 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> The bool argument is just passed along.
>> 
>> ```c++
>>   RegionsTree(bool with_storage) : VMATree(), _ncs_storage(with_storage) {
>>   }
>
> Done.
> For my curiosity, what is the advantage?

1. No malloc
2. No indirection, so no cache misses
3. A clear lifetime and clear ownership, both are bound to the `RegionsTree` object

>> Then just invert it: Have the outer class be static and the inner class be an instance. We can change the `MemoryFileTracker` to be that, as it's not as large of a change.
>
> It is still a big change. Why not another RFE?

Because we want to switch to a new way of exposing the public interface, as opposed to an under-the-hood optimization. This PR is still in draft and we're far away from next RDP1, we're not in a hurry and can afford to get this right. I do not want to repeat the same mistakes of the old codebase.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711099968
PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711190300

From azafari at openjdk.org  Fri Nov  8 10:52:06 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:06 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <6o6kdvS3Uy-Fq1bbRBmiPYvV7ztF6Urm0x5lkfgA2kY=.9e576627-d4cb-47a9-a916-59687afa11b5@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
 <6o6kdvS3Uy-Fq1bbRBmiPYvV7ztF6Urm0x5lkfgA2kY=.9e576627-d4cb-47a9-a916-59687afa11b5@github.com>
Message-ID: <1NaOK_jn5BkkHoXnlaP_vLz0Gyp9PcqFbHzFYOhlmuI=.d65aa63e-26c5-4084-997c-dd9b1cc03cd2@github.com>

On Fri, 9 Aug 2024 09:05:37 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Done.
>> For my curiosity, what is the advantage?
>
> 1. No malloc
> 2. No indirection, so no cache misses
> 3. A clear lifetime and clear ownership, both are bound to the `RegionsTree` object

OK. Thanks for your description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713371752

From jsjolen at openjdk.org  Fri Nov  8 10:52:06 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:06 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
Message-ID: <AQp1oQzBQXetZQvpjx9UwPpGQ45lJDA5sDNrwgC2UHA=.dc91e33d-cdfc-48d3-81c0-affbab0fcc34@github.com>

On Fri, 9 Aug 2024 10:14:10 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> - `VMATree` is used instead of `SortedLinkList` in new class `VirtualMemoryTrackerWithTree`.
>>  -  A wrapper/helper `RegionTree` is made around VMATree to make some calls easier.
>>  -  Both old and new versions exist in the code and can be selected via `MemTracker::set_version()`
>>  - `find_reserved_region()` is used in 4 cases, it will be removed in further PRs.
>>  - All tier1 tests pass except one ~that expects a 50% increase in committed memory but it does not happen~  https://bugs.openjdk.org/browse/JDK-8335167.
>>  - Adding a runtime flag for selecting the old or new version can be added later.
>>  - Some performance tests are added for new version, VMATree and Treap, to show the idea and should be improved later. Based on the results of comparing speed of VMATree and VMT, VMATree shows ~40x faster response time.
>
> src/hotspot/share/nmt/regionsTree.hpp line 46:
> 
>> 44:   using Node = VMATree::TreapNode;
>> 45: 
>> 46:   class NodeHelper : public Node {
> 
> This shouldn't inherit from `Node` and then have each instance be cast into `NodeHelper`. Make into `class Utils : public AllStatic`.

Alternatively create it by composition:

```c++
class NodeHelper {
  Node& node;
  NodeHelper(Node* node) : node(*node) {}
  // All of the methods
};

{ // Some Node* node
  NodeHelper nh(node);
  // Use nh 
}

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711643629

From azafari at openjdk.org  Fri Nov  8 10:52:06 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:06 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <AQp1oQzBQXetZQvpjx9UwPpGQ45lJDA5sDNrwgC2UHA=.dc91e33d-cdfc-48d3-81c0-affbab0fcc34@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <AQp1oQzBQXetZQvpjx9UwPpGQ45lJDA5sDNrwgC2UHA=.dc91e33d-cdfc-48d3-81c0-affbab0fcc34@github.com>
Message-ID: <34_DIwceR7SBt_B6wwmMqA9yLFss4bkqGx4f-k6gSeM=.88fa4c55-442a-4d71-a511-1a81d070d185@github.com>

On Fri, 9 Aug 2024 15:05:59 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> src/hotspot/share/nmt/regionsTree.hpp line 46:
>> 
>>> 44:   using Node = VMATree::TreapNode;
>>> 45: 
>>> 46:   class NodeHelper : public Node {
>> 
>> This shouldn't inherit from `Node` and then have each instance be cast into `NodeHelper`. Make into `class Utils : public AllStatic`.
>
> Alternatively create it by composition:
> 
> ```c++
> class NodeHelper {
>   Node& node;
>   NodeHelper(Node* node) : node(*node) {}
>   // All of the methods
> };
> 
> { // Some Node* node
>   NodeHelper nh(node);
>   // Use nh 
> }

Done. The alternative way.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713462208

From jsjolen at openjdk.org  Fri Nov  8 10:52:07 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:07 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
Message-ID: <VlWhNXWElYQlzPuMJRa0XwGGvvaNDkHKwxoSD0BZ1iY=.2f92c63d-98e7-4581-bd56-7916ad4b165e@github.com>

On Mon, 5 Aug 2024 08:41:49 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> In `MemoryFileTracker`, the changes in commit/reserve are applied to a local `VirtualMemorySnapshot`. Here we have to apply them to the global `VirtualMemorySummary`.
>
> Yeah, that doesn't seem like a problem.
> 
> ```c++
>   for (int i = 0; i < mt_number_of_types; i++) {
>     r = diff.flag[i].reserve;
>     c = diff.flag[i].commit;
>     flag = NMTUtil::index_to_flag(i);
>     VirtualMemory* mem = VirtualMemorySummary::as_snapshot()->by_type(flag);
>     reserved = mem->reserved();
>     committed = mem->committed();
>     mem->reserve_memory(r);
>     mem->commit_memory(c);
>     if ((size_t)-r > reserved) {
>       print_err("release");
>     }
>     if ((size_t)-c > reserved || (size_t)c > committed) {
>       print_err("uncommit");
>     }
>   }

This applies the reserve/commit regardless of outcome, so slightly different.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1703753128

From azafari at openjdk.org  Fri Nov  8 10:52:07 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:07 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <VlWhNXWElYQlzPuMJRa0XwGGvvaNDkHKwxoSD0BZ1iY=.2f92c63d-98e7-4581-bd56-7916ad4b165e@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <VlWhNXWElYQlzPuMJRa0XwGGvvaNDkHKwxoSD0BZ1iY=.2f92c63d-98e7-4581-bd56-7916ad4b165e@github.com>
Message-ID: <LZQH5bNpAL0oF7tepVLTWE_1PCtTvVOVY1St63JgUqY=.03ddc8e2-8460-475b-8912-248f9d2a9b9f@github.com>

On Mon, 5 Aug 2024 08:42:43 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> Yeah, that doesn't seem like a problem.
>> 
>> ```c++
>>   for (int i = 0; i < mt_number_of_types; i++) {
>>     r = diff.flag[i].reserve;
>>     c = diff.flag[i].commit;
>>     flag = NMTUtil::index_to_flag(i);
>>     VirtualMemory* mem = VirtualMemorySummary::as_snapshot()->by_type(flag);
>>     reserved = mem->reserved();
>>     committed = mem->committed();
>>     mem->reserve_memory(r);
>>     mem->commit_memory(c);
>>     if ((size_t)-r > reserved) {
>>       print_err("release");
>>     }
>>     if ((size_t)-c > reserved || (size_t)c > committed) {
>>       print_err("uncommit");
>>     }
>>   }
>
> This applies the reserve/commit regardless of outcome, so slightly different.

The main purpose of the `if (...)` cases is to find if the request to apply the delta is valid or not. There are related assertions in VirtualMemory but not so informative. Also, using `log_debug` lets the build proceed and just show the messages.
These messages help a lot when something goes wrong in terms of commit/uncommit/release failure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704398731

From jsjolen at openjdk.org  Fri Nov  8 10:52:07 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:07 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <LZQH5bNpAL0oF7tepVLTWE_1PCtTvVOVY1St63JgUqY=.03ddc8e2-8460-475b-8912-248f9d2a9b9f@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <VlWhNXWElYQlzPuMJRa0XwGGvvaNDkHKwxoSD0BZ1iY=.2f92c63d-98e7-4581-bd56-7916ad4b165e@github.com>
 <LZQH5bNpAL0oF7tepVLTWE_1PCtTvVOVY1St63JgUqY=.03ddc8e2-8460-475b-8912-248f9d2a9b9f@github.com>
Message-ID: <nxTScZg_msjP6q87AuHF05_g_4HRY3ePmdVkIusuaZA=.fe2475d1-b104-44f9-923b-e9140d163c9d@github.com>

On Mon, 5 Aug 2024 16:54:40 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> This applies the reserve/commit regardless of outcome, so slightly different.
>
> The main purpose of the `if (...)` cases is to find if the request to apply the delta is valid or not. There are related assertions in VirtualMemory but not so informative. Also, using `log_debug` lets the build proceed and just show the messages.
> These messages help a lot when something goes wrong in terms of commit/uncommit/release failure.

How does my example code not account for this? You can still get rid of the sign checking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1711187386

From azafari at openjdk.org  Fri Nov  8 10:52:08 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:08 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <nxTScZg_msjP6q87AuHF05_g_4HRY3ePmdVkIusuaZA=.fe2475d1-b104-44f9-923b-e9140d163c9d@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <VlWhNXWElYQlzPuMJRa0XwGGvvaNDkHKwxoSD0BZ1iY=.2f92c63d-98e7-4581-bd56-7916ad4b165e@github.com>
 <LZQH5bNpAL0oF7tepVLTWE_1PCtTvVOVY1St63JgUqY=.03ddc8e2-8460-475b-8912-248f9d2a9b9f@github.com>
 <nxTScZg_msjP6q87AuHF05_g_4HRY3ePmdVkIusuaZA=.fe2475d1-b104-44f9-923b-e9140d163c9d@github.com>
Message-ID: <Ze7LIZkunfvfqu8X97YlV0WRTKE8PaBduPcdWrrHX8Q=.bc9584e1-2ac0-41e9-a936-f7ff8cbcd686@github.com>

On Fri, 9 Aug 2024 10:03:52 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> The main purpose of the `if (...)` cases is to find if the request to apply the delta is valid or not. There are related assertions in VirtualMemory but not so informative. Also, using `log_debug` lets the build proceed and just show the messages.
>> These messages help a lot when something goes wrong in terms of commit/uncommit/release failure.
>
> How does my example code not account for this? You can still get rid of the sign checking.

Case of 'commit' error is missing from your suggestion. At commit time, ` c > reserved` is invalid too.
`(size_t)-r` for positive `r` is a large number and is greater than `reserved`. 
We have to find out the intent of the call first (by checking the sign of `r` or `c`) and then check if it is valid or not.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1713513436

From azafari at openjdk.org  Fri Nov  8 10:52:08 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:08 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
Message-ID: <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com>

On Mon, 5 Aug 2024 17:20:24 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> Why would the execution time grow logarithmically when we do linearly more work? When we run this with `N2` we will perform `10_000 * log(10_000, 2)` units of work, and for `N1` we will perform `1_000 * log(1_000, 2)` units of work, approximately. A closer approximation is `O(log(1)) + O(log(2)) + ... + O(log(n))` for `n = N2` or `n = N1`.
>> 
>> Let's calculate that:
>> 
>> 
>>>>> import math
>>>>> def time_it(n):
>> ...     t = 0
>> ...     for i in range(1, n):
>> ...             t  = t + math.log(i)
>> ...     return [t, 3*t] # Approximate best and worst case
>> ... 
>>>>> time_it(1000)
>> [5905.220423209189, 17715.661269627566]
>>>>> time_it(10_000)
>> [82099.71749644217, 246299.15248932652]
>>>>> def compare(a, b):
>> ...     ab, aw = a
>> ...     bb, bw = b
>> ...     return [ bb / ab, bw / aw ]
>> ... 
>>>>> compare(time_it(1000), time_it(10_000))
>> [13.902904821938064, 13.902904821938066]
>>>>> # Ouch, that's outside of our linear bound!
>> 
>> 
>> What I said previously also applies, especially the performance of `malloc` will impact this I suspect.
>
> It is considered that `malloc` or other external events are the same for two cases. If we know that there might be some noise for one or another, we should check and disable them. This is the approach I have talked. How can we avoid noise from `malloc` side?

When it is said that an algorithm has the log(n) time-complexity, it means that if the input grows n times, the times grows log(n) times. The tree data-structure has log(n) time-complexity. VMATree may have not exactly log(n) response times due to self-balancing costs. But it is still expected to be less than O(n).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1704427407

From jsjolen at openjdk.org  Fri Nov  8 10:52:09 2024
From: jsjolen at openjdk.org (Johan =?UTF-8?B?U2rDtmxlbg==?=)
Date: Fri, 8 Nov 2024 10:52:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
 <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com>
Message-ID: <GIpPltCD2ELaAlxQqncRlaAuX3bM90UDn8UbnHE3Y8I=.3112ac66-62e0-43ba-bc59-576d75dc5771@github.com>

On Mon, 5 Aug 2024 17:23:46 GMT, Afshin Zafari <azafari at openjdk.org> wrote:

>> It is considered that `malloc` or other external events are the same for two cases. If we know that there might be some noise for one or another, we should check and disable them. This is the approach I have talked. How can we avoid noise from `malloc` side?
>
> When it is said that an algorithm has the log(n) time-complexity, it means that if the input grows n times, the times grows log(n) times. The tree data-structure has log(n) time-complexity. VMATree may have not exactly log(n) response times due to self-balancing costs. But it is still expected to be less than O(n).

Hi Afshin, could we take a step back and do some asymptotic time complexity analysis of this problem?

The test is measuring the following code:

```c++
for (int i = 0; i < n; i++) {
  int a = (os::random() % n) * 100;
  treap.upsert(a, 0);
}


So this algorithm is the tme complexity which we are trying to understand. First, let's simplify the code slightly:

```c++
auto f = [&](auto n) { int a = (os::random() % n) * 100;  treap.upsert(a, i); };
for (int i = 0; i < n; i++) {
  f(i);
}


Clearly, `f(n)` is executed `n` times, agreed? Then the time complexity of the whole program must be `O(n*f(n))`, correct? It's the time complexity of `f(n)` performed `n` times.

Let's replace `f` with something else to see if we can understand the time complexity of the whole code snippet again.

```c++
int arr[n];
auto f = [&](auto n) { arr[n] = 0; };
for (int i = 0; i < n; i++) {
  f(i);
}


Now, we both agree that assigning to an array has time complexity `O(1)`, correct? Then, if we fill that in in our expression `O(n * f(n))` we receive `O(n * 1) = O(n)`, correct? In other words, the time complexity of the algorithm the test is measuring is *linear*, and we ought to expect that with an array the time taken for the array should be 10x longer with 10k elements as compared to 1k elements.

OK, now let's *assume* that `f(n)` has time complexity `O(log n)`, then shouldn't the algorithm we're measuring have time complexity `O(n * log n)`, that is actually *slower* than `O(n)`.

In conclusion: if `treap.upsert()` has time complexity `O(log n)` then the whole algorithm should have time complexity `O(n * log n)` and the measurements we're seeing are as expected *and the test shouldn't fail*.

Have I missed anything or made any mistakes? Please let me know.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1705025716

From azafari at openjdk.org  Fri Nov  8 10:52:09 2024
From: azafari at openjdk.org (Afshin Zafari)
Date: Fri, 8 Nov 2024 10:52:09 GMT
Subject: RFR: 8337217: Port VirtualMemoryTracker to use VMATree
In-Reply-To: <GIpPltCD2ELaAlxQqncRlaAuX3bM90UDn8UbnHE3Y8I=.3112ac66-62e0-43ba-bc59-576d75dc5771@github.com>
References: <_QgAec-LQq4pdC6sP3UAZLHRT30q1mxXohvGDag1a6U=.214e9d81-c627-4f34-af8f-cb71506eeda2@github.com>
 <kLbS6vUIJ5BLsdzY1oJ8KQflW8a0odpTp6AI9HDBJVU=.216aa2fe-da41-4367-a287-3aa5d58b0772@github.com>
 <s4fX_EDz39hpzzWPbIhuepBybgPRgvb6Tzys_IeakEo=.c6cf943a-a6a1-4945-95b9-709e9a9e435e@github.com>
 <1u3WP9RzjZZiy1CkcuwSIKqOzMxzMiZssKOU8qiBaoI=.250c90cb-f946-4b8e-ae7d-0b60b03559f9@github.com>
 <eyjjRXo8kIxfvT79xgo01sBJYO00POP4xHo7DZTHna4=.ee1269ed-cc79-4905-aefd-a3035dda4e50@github.com>
 <5y5A3NZ0xOQvQ26ao94mbrvFMbF1mLaqyL6YZcTHJ9U=.f73c445f-38b0-4419-bc6d-50e7793d7084@github.com>
 <GIpPltCD2ELaAlxQqncRlaAuX3bM90UDn8UbnHE3Y8I=.3112ac66-62e0-43ba-bc59-576d75dc5771@github.com>
Message-ID: <0Z4IlT_4DH7rajUP2HfXV55YUiJ_kJnFhpdbD71p52k=.c18e3a38-6c97-497b-9a4c-2724207b454e@github.com>

On Tue, 6 Aug 2024 07:12:13 GMT, Johan Sj?len <jsjolen at openjdk.org> wrote:

>> When it is said that an algorithm has the log(n) time-complexity, it means that if the input grows n times, the times grows log(n) times. The tree data-structure has log(n) time-complexity. VMATree may have not exactly log(n) response times due to self-balancing costs. But it is still expected to be less than O(n).
>
> Hi Afshin, could we take a step back and do some asymptotic time complexity analysis of this problem?
> 
> The test is measuring the following code:
> 
> ```c++
> for (int i = 0; i < n; i++) {
>   int a = (os::random() % n) * 100;
>   treap.upsert(a, 0);
> }
> 
> 
> So this algorithm is the tme complexity which we are trying to understand. First, let's simplify the code slightly:
> 
> ```c++
> auto f = [&](auto n) { int a = (os::random() % n) * 100;  treap.upsert(a, i); };
> for (int i = 0; i < n; i++) {
>   f(i);
> }
> 
> 
> Clearly, `f(n)` is executed `n` times, agreed? Then the time complexity of the whole program must be `O(n*f(n))`, correct? It's the time complexity of `f(n)` performed `n` times.
> 
> Let's replace `f` with something else to see if we can understand the time complexity of the whole code snippet again.
> 
> ```c++
> int arr[n];
> auto f = [&](auto n) { arr[n] = 0; };
> for (int i = 0; i < n; i++) {
>   f(i);
> }
> 
> 
> Now, we both agree that assigning to an array has time complexity `O(1)`, correct? Then, if we fill that in in our expression `O(n * f(n))` we receive `O(n * 1) = O(n)`, correct? In other words, the time complexity of the algorithm the test is measuring is *linear*, and we ought to expect that with an array the time taken for the array should be 10x longer with 10k elements as compared to 1k elements.
> 
> OK, now let's *assume* that `f(n)` has time complexity `O(log n)`, then shouldn't the algorithm we're measuring have time complexity `O(n * log n)`, that is actually *slower* than `O(n)`.
> 
> In conclusion: if `treap.upsert()` has time complexity `O(log n)` then the whole algorithm should have time complexity `O(n * log n)` and the measurements we're seeing are as expected *and the test shouldn't fail*.
> 
> Have I missed anything or made any mistakes? Please let me know.

The big O is a _notation_ and is not a math function. So `O(a * b)` is not always same as `O(a) * O(b)`.
Stick to this _definition_: "when an algorithm has time-complexity of O(`g(n)`), it means if the input grows `n` times the time of executing the algorithm grows `g(n)` times." Where `g()` is `log()` in our case.
IOW, the big O answers the following question:
$t_1$ = time for running `f()` for $n_1$ items
$t_2$ = time for running `f()` for $n_2$ items
if we know $\Large{\frac{n_2}{n_1} = n}$ what is expected value of $t_2$?

A detailed description can be found [here](https://en.wikipedia.org/wiki/Big_O_notation).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20425#discussion_r1705161898

From eirbjo at openjdk.org  Fri Nov  8 11:01:15 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 8 Nov 2024 11:01:15 GMT
Subject: RFR: 8343819: Link Float.NaN and Double.NaN to equivalence discussion
 in Double
Message-ID: <ugKltRYAkNLJ-GKuxYzTVOxVggO4tnX2KVZHw7Xh17g=.162e25f8-b5db-499b-a450-e4899a0b1f8c@github.com>

Please review this doc-only enhancement which links the word _equivalent_ in `Float.NaN` and `Double.NaN` constant field descriptions to the floating-point equivalence discussion in `Double`.  

> It is equivalent to the value returned by{@code Float.intBitsToFloat(0x7fc00000)}.

For readers not well-versed in floating point, it may not be immediatly clear what _equivalent to_ means here.

The smallest improvement I could think of is to simply make the word `equivalent` a plain link to the floating-point equivalence discussion in the class description of `java.lang.Double`.

Verification: This is a doc-only change. I ran `make docs` and verified that the links resolve.

-------------

Commit messages:
 - Link Double.NaN and Float.Nan to the floating-point equivalence discussion in Double##equivalenceRelation.

Changes: https://git.openjdk.org/jdk/pull/21972/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21972&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343819
  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21972.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21972/head:pull/21972

PR: https://git.openjdk.org/jdk/pull/21972

From alanb at openjdk.org  Fri Nov  8 11:05:37 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 11:05:37 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <rSQvUkjDXEZei6Dgr-BhOYCLr3Fo_1QNdBDzfjyo4kI=.1e436131-dd1e-4747-92d6-476095113c68@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
 <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>
 <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>
 <jn2BQPpc-gQAfNF2I3TQy2EIRD-M27td6BmFmf0y088=.8148de4f-07c7-4eb7-a5ab-121044d9d6e3@github.com>
 <rSQvUkjDXEZei6Dgr-BhOYCLr3Fo_1QNdBDzfjyo4kI=.1e436131-dd1e-4747-92d6-476095113c68@github.com>
Message-ID: <lkToYy7973bPD5csWGBc_OQY6GHD7YW3aQmmbbaa6cA=.113649d9-7901-42ca-ac45-46235a4010f3@github.com>

On Fri, 8 Nov 2024 10:34:43 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> That's okay, I wasn't initially sure why they were changed.  I'm looking at JRTArchiveFile.toEntry and wondering there should be a follow-up issue (not this PR) to fail early if running on a patched run-time even though it would be an odd configuration to attempt to do that.
>
> There already is. See:
> https://github.com/openjdk/jdk/pull/14787/files#diff-b6b47eacb6060eb0a583a253f322f5d274063e082a12a72e8628a6e1ba6cdd3eR466-R471
> 
> It's also tested with [PatchedJDKModuleJlinkTest.java](https://github.com/openjdk/jdk/pull/14787/files#diff-11b8a26307346fd7ca016a349243cabd3b982964aaf4335298e28e956b3968eb). Do we need more?

Yes, I know there is a test. It's "no such file" case in JRTArchiveFile.toEntry that I'm looking at.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834151588

From ihse at openjdk.org  Fri Nov  8 11:24:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 11:24:52 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v32]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <HJ_Q6vI8J-AQp08b97u6i6cMt-N_tJ8_z7st2ei3et0=.872787dc-e88d-48c0-bb51-86e3157ea61c@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge branch 'master' into impl-JEP-479
 - Remove FIXME
 - fix: jvm_md.h was included, but not jvm.h...
 - Update copyright years
 - Merge branch 'master' into impl-JEP-479
 - JVM_EnqueueOperation do not need __stdcall name lookup anymore
 - [JNI/JVM/AGENT]_[ONLOAD/ONUNLOAD/ONATTACH]_SYMBOLS are now identical on Windows and Unix, so unify them
 - Fix build_agent_function_name to not handle "@"-stdcall style names
 - buildJniFunctionName is now identical on Windows and Unix, so unify it
 - Also restore ADLC_CFLAGS_WARNINGS changes that are not needed any longer
 - ... and 27 more: https://git.openjdk.org/jdk/compare/0c281acf...a9d56f2f

-------------

Changes: https://git.openjdk.org/jdk/pull/21744/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31
  Stats: 1925 lines in 85 files changed: 86 ins; 1572 del; 267 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Fri Nov  8 11:31:40 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 11:31:40 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Inline buildJniFunctionName

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21744/files
  - new: https://git.openjdk.org/jdk/pull/21744/files/a9d56f2f..445515e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=32
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21744&range=31-32

  Stats: 14 lines in 1 file changed: 4 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21744.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21744/head:pull/21744

PR: https://git.openjdk.org/jdk/pull/21744

From ihse at openjdk.org  Fri Nov  8 11:31:41 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 8 Nov 2024 11:31:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v30]
In-Reply-To: <ebrOcbIXqNUwLD-vhw4PyoMIl8KShh6JCCjE9xMwmFk=.fbed032e-4207-451b-a985-55ef5523862b@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <MDJehqxcKmRUtl3v-K_-e7W8S2mDkbxlBSdi_6dxBzg=.1fbf6eef-8238-4492-86cc-76be2cf5302c@github.com>
 <LL-YMpcGfLcrz69z-iCRZAxB9JUBQYpF4ChWHtvi7d8=.a8cd06eb-b448-4f53-9050-b0fece6ed89c@github.com>
 <_8hqosvrOekf3ephURXyuAKg9hl2FRpH-tJ-y_PFE6k=.f5ab5105-b4d3-4e5a-ae7d-705838274dc1@github.com>
 <ebrOcbIXqNUwLD-vhw4PyoMIl8KShh6JCCjE9xMwmFk=.fbed032e-4207-451b-a985-55ef5523862b@github.com>
Message-ID: <9-Gr4GhhtLOPX6w1PMSIcvx25_d9-MchNZtIId2mZLg=.79e4368a-412d-42c6-8db7-7288b50cb63e@github.com>

On Wed, 6 Nov 2024 21:24:14 GMT, Kim Barrett <kbarrett at openjdk.org> wrote:

>> @kimbarrett I added this to https://bugs.openjdk.org/browse/JDK-8343703. You are not as explicit here as the other places you commented that it is okay to do as a follow-up, but I'll assume that was what you meant. If not, let me know, and I'll look at fixing it for this PR already.
>
> The first part, eliminating the (IMO not actually helpful) helper function, I wanted done here.  The second part,
> cleaning up or commenting the calculation of the length and dealing with perhaps unneeded conditionals, I'm
> okay with being in a followup.  I guess I can live with the first part being in that followup too.

Ok, fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834182702

From alanb at openjdk.org  Fri Nov  8 11:48:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 11:48:43 GMT
Subject: RFR: 8211033: Clean up the processing -classpath argument not to
 set LM_CLASS
In-Reply-To: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
References: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
Message-ID: <QZ7ukbfqHaZilWWq6gAXvNOjogPu2uE7b076cLFYsSc=.57e1c0d7-f2d8-4e73-9b95-91ec549b07c6@github.com>

On Fri, 8 Nov 2024 08:51:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.org/browse/JDK-8211033?
> 
> As noted in that issue, this is a clean up of the code which determines the "mode" through with the `java` application is being launched. In its current form the presence of `--classpath` (or its equivalent arguments) was unnecessary updating the mode to `LM_CLASS`. The commit in this PR removes that part to allow for the mode to be detected based merely on the presence (or absence) of `-m`, `-jar`, `--source` options. If neither is specified, the file extension is checked to determine the launch mode. 
> 
> Given the nature of this clean up, no new tests have been introduced. Existing tests in tier1, tier2, tier3 continue to pass with this change.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21971#pullrequestreview-2423527963

From qamai at openjdk.org  Fri Nov  8 12:01:11 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Nov 2024 12:01:11 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing out
Message-ID: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>

Hi,

This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:

    // Keep the 2 threads operating on the same scope
    int k = lock.getAndAdd(1) + 1;
    while (k != i * 2) {
        Thread.onSpinWait();
        k = lock.get();
    }

Given the initial condition:

    Thread 1: i = 0
    Thread 2: i = 0
    lock: -2

The `lock` then undergoes the following operations:



        Thread 1          Thread 2         lock value
      getAndAdd(1)                            -1
                        getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
                        getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
          get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
                           get()               1 -> Thread 2 now cannot proceed because lock can never reach 2


The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.

Please take a look, thanks a lot.

-------------

Commit messages:
 - use < instead of !=

Changes: https://git.openjdk.org/jdk/pull/21976/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21976&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343793
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21976/head:pull/21976

PR: https://git.openjdk.org/jdk/pull/21976

From mcimadamore at openjdk.org  Fri Nov  8 12:26:37 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 8 Nov 2024 12:26:37 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out
In-Reply-To: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
Message-ID: <drz5Vrt9cpnmazTP1Ungn8OSwI_GaO5F8Vhy9KKwFbY=.dfcd41ba-6dee-4933-984e-cf8405565cb1@github.com>

On Fri, 8 Nov 2024 11:56:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
> 
>     // Keep the 2 threads operating on the same scope
>     int k = lock.getAndAdd(1) + 1;
>     while (k != i * 2) {
>         Thread.onSpinWait();
>         k = lock.get();
>     }
> 
> Given the initial condition:
> 
>     Thread 1: i = 0
>     Thread 2: i = 0
>     lock: -2
> 
> The `lock` then undergoes the following operations:
> 
> 
> 
>         Thread 1          Thread 2         lock value
>       getAndAdd(1)                            -1
>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
> 
> 
> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
> 
> Please take a look, thanks a lot.

I'm playing with something like this:


@Test
    public void testAcquireCloseRace() throws InterruptedException {
        int MAX_ITERATIONS = 1000;
        AtomicInteger iteration = new AtomicInteger();
        boolean[] result = new boolean[1];
        MemorySessionImpl[] scopes = new MemorySessionImpl[MAX_ITERATIONS];
        for (int i = 0; i < MAX_ITERATIONS; i++) {
            scopes[i] = MemorySessionImpl.toMemorySession(Arena.ofShared());
        }

        // This thread tries to close the scopes
        Thread t1 = new Thread(() -> {
            int it = iteration.get();
            while (it < MAX_ITERATIONS) {
                while (true) {
                    try {
                        scopes[it].close();
                        // if we close successfully, the iteration is now completed
                        break;
                    } catch (IllegalStateException e) {
                        // scope is acquired, wait and try again
                        Thread.onSpinWait();
                    }
                }
                // wait for other thread to complete its iteration
                int prev = it;
                while (prev == it) {
                    Thread.onSpinWait();
                    it = iteration.get();
                }
            }
        });

        // This thread tries to acquire the scopes, then check if it is alive after an acquire failure
        Thread t2 = new Thread(() -> {
            int it = iteration.get();
            while (it < MAX_ITERATIONS) {
                while (true) {
                    try {
                        scopes[it].acquire0();
                    } catch (IllegalStateException e) {
                        // we failed to acquire, meaning the other thread has closed this scope
                        if (scopes[it].isAlive()) {
                            result[0] = true;
                        }
                        // this iteration is now completed
                        break;
                    }
                    // if we get here, acquire was successful, so we need to release...
                    scopes[it].release0();
                    // ... and then try again
                }
                // advance to next iteration
                it = iteration.addAndGet(1);
            }
        });

        t1.start();
        t2.start();
        t1.join();
        t2.join();
        assertFalse(result[0]);
    }


I think I find this logic a bit more direct:

* both thread agree on an iteration count (the atomic integer)
* thread A keeps trying closing a scope -- if it succeds, its iteration is done, and it waits for the next thread to be done
* thread B keeps acquiring and releasing a scope -- if it fails to acquire, that means that the scope is closed by the other thread, so this iteration is done, and we can update the shared iteration counter

What do you think?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21976#issuecomment-2464628207

From prappo at openjdk.org  Fri Nov  8 12:38:06 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 8 Nov 2024 12:38:06 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v5]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <0Qqgqopg8A8uXWPafyVBz8LpW6M1HTLMqnF3M-KPHHg=.7b8e11f9-5978-4497-9ed3-c4997d53c31b@github.com>

> Prepare for JDK 25.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - Update --release 24 symbol information for JDK 24 build 23
   
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 21
   
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
 - Add forgotten .jcheck/conf
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/9a0553bb..84dce9a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=03-04

  Stats: 132677 lines in 806 files changed: 104773 ins; 9792 del; 18112 mod
  Patch: https://git.openjdk.org/jdk/pull/21763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21763/head:pull/21763

PR: https://git.openjdk.org/jdk/pull/21763

From alanb at openjdk.org  Fri Nov  8 12:56:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 12:56:20 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v2]
In-Reply-To: <3J4BybOBLEvHajoowPmaESUb0lfmWvB51buu68o9mSQ=.78df4cd7-edc2-4ec4-9782-7f2bbf18cd53@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <3J4BybOBLEvHajoowPmaESUb0lfmWvB51buu68o9mSQ=.78df4cd7-edc2-4ec4-9782-7f2bbf18cd53@github.com>
Message-ID: <xq5vzIPSa18O9FPzdzzy4uUXGXRQHhZTvOvVhB9p1mQ=.36bff480-d606-49de-af08-2d453d88eba9@github.com>

On Mon, 4 Nov 2024 16:10:47 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating copyright years and removing an unneccessary import for Gatherers

Looks fine, you'll need to sync up the PR to resolve the merge conflict, and you'll need to update the copyright header of several files (esp. tests) before integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2464686608

From sgehwolf at openjdk.org  Fri Nov  8 12:57:45 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 12:57:45 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v46]
In-Reply-To: <lkToYy7973bPD5csWGBc_OQY6GHD7YW3aQmmbbaa6cA=.113649d9-7901-42ca-ac45-46235a4010f3@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <xdMJwvgr5a-vzSeTPganTpuA3FWueMTtFyBFqjt2PYA=.7c8c9b32-c846-4cb4-b1e6-4de7896b133c@github.com>
 <xvcgtflnuh1A_TcQdtTKLzr-3SBrgHTCj-b74Tr-Zus=.40d55d88-393f-4caa-896d-d1924a07904d@github.com>
 <AcVKkCAlFv4zPjnpF3n8o4otMVvXXiozfrW7QIm9wkU=.05ef178f-a567-4e19-9f61-9865b2e3e8e0@github.com>
 <jn2BQPpc-gQAfNF2I3TQy2EIRD-M27td6BmFmf0y088=.8148de4f-07c7-4eb7-a5ab-121044d9d6e3@github.com>
 <rSQvUkjDXEZei6Dgr-BhOYCLr3Fo_1QNdBDzfjyo4kI=.1e436131-dd1e-4747-92d6-476095113c68@github.com>
 <lkToYy7973bPD5csWGBc_OQY6GHD7YW3aQmmbbaa6cA=.113649d9-7901-42ca-ac45-46235a4010f3@github.com>
Message-ID: <8xReyXQHm1yZjYLiCwdQKOKMQ58ENTgwWqjwBEd2Jgg=.96053a2e-37cf-4b0b-ad66-8cbb1f77e97d@github.com>

On Fri, 8 Nov 2024 11:02:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> There already is. See:
>> https://github.com/openjdk/jdk/pull/14787/files#diff-b6b47eacb6060eb0a583a253f322f5d274063e082a12a72e8628a6e1ba6cdd3eR466-R471
>> 
>> It's also tested with [PatchedJDKModuleJlinkTest.java](https://github.com/openjdk/jdk/pull/14787/files#diff-11b8a26307346fd7ca016a349243cabd3b982964aaf4335298e28e956b3968eb). Do we need more?
>
> Yes, I know there is a test. It's "no such file" case in JRTArchiveFile.toEntry that I'm looking at.

Filed https://bugs.openjdk.org/browse/JDK-8343839 for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/14787#discussion_r1834361272

From asemenyuk at openjdk.org  Fri Nov  8 13:14:46 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Nov 2024 13:14:46 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v4]
In-Reply-To: <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
Message-ID: <n2zEsls7l9gbnfUaWNu3dhqoywBdFAqJt7q1YS00HPk=.e8c1b455-9d71-440e-8ae9-683b683274c8@github.com>

On Thu, 31 Oct 2024 07:18:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove global memHandle, would've liked to keep it as a comment :(

Changes requested by asemenyuk (Reviewer).

src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp line 183:

> 181:     add32bitPadding(buf); // Padding2
> 182: 
> 183:  // const DWORD neutralLangId = (0x04b0 | MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL) << 16);

As ` neutralLangId` is unused, remove it instead of commenting it out.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2423768191
PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1834382152

From jwaters at openjdk.org  Fri Nov  8 13:39:08 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Nov 2024 13:39:08 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v5]
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <upTvje0kzoe3TIIzbLcXiNFKznTd26nr6VUUE7fjwaU=.9e4ea989-c45b-4cd2-ab87-743b913acad8@github.com>

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Remove neutralLangId in VersionInfo.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21616/files
  - new: https://git.openjdk.org/jdk/pull/21616/files/4d15fe78..68767cbe

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=03-04

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616

PR: https://git.openjdk.org/jdk/pull/21616

From jwaters at openjdk.org  Fri Nov  8 13:39:09 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Fri, 8 Nov 2024 13:39:09 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v4]
In-Reply-To: <n2zEsls7l9gbnfUaWNu3dhqoywBdFAqJt7q1YS00HPk=.e8c1b455-9d71-440e-8ae9-683b683274c8@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <vAxr5Fbbc98tBTOdLvs8uhdI4WPrg-1BRfWQgSmCavQ=.75c5ce3a-5b0c-4a39-a69f-f64e4e7235a3@github.com>
 <n2zEsls7l9gbnfUaWNu3dhqoywBdFAqJt7q1YS00HPk=.e8c1b455-9d71-440e-8ae9-683b683274c8@github.com>
Message-ID: <V_rxQUWSQh8wzhmkefPwgGBbjtbvihL6KdCZBPiJDPQ=.a8a58b48-9fb4-4126-b5d7-68b12b551ec7@github.com>

On Fri, 8 Nov 2024 13:10:48 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove global memHandle, would've liked to keep it as a comment :(
>
> src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp line 183:
> 
>> 181:     add32bitPadding(buf); // Padding2
>> 182: 
>> 183:  // const DWORD neutralLangId = (0x04b0 | MAKELANGID(LANG_NEUTRAL, SUBLANG_NEUTRAL) << 16);
> 
> As ` neutralLangId` is unused, remove it instead of commenting it out.

Will do

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1834413246

From vklang at openjdk.org  Fri Nov  8 13:43:26 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 13:43:26 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v3]
In-Reply-To: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
Message-ID: <U29E6VqWoNuH9A9990kbQPATuFC4kU0R8zu0p5ZG_QE=.1acb1273-7fab-4780-b909-c51b4b7c16e4@github.com>

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:

 - Updating copyright years and removing an unneccessary import for Gatherers
 - Removing PreviewFeature from Gatherers
 - Updating @since to 24 for Gatherers

-------------

Changes: https://git.openjdk.org/jdk/pull/21686/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21686&range=02
  Stats: 39 lines in 24 files changed: 0 ins; 19 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21686/head:pull/21686

PR: https://git.openjdk.org/jdk/pull/21686

From pchilanomate at openjdk.org  Fri Nov  8 13:48:00 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 8 Nov 2024 13:48:00 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <wQhIYGy1JULXOd4-arVYp3gABhb2Smg92LAQzCYj2kg=.ff7f91a4-9118-4cbc-a7d3-133271d09201@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:

 - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
 - Add ObjectWaiter::at_monitorenter

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21565/files
  - new: https://git.openjdk.org/jdk/pull/21565/files/62b16c6a..3cdb8f86

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=02-03

  Stats: 44 lines in 5 files changed: 36 ins; 1 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From vklang at openjdk.org  Fri Nov  8 13:49:32 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 13:49:32 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v3]
In-Reply-To: <U29E6VqWoNuH9A9990kbQPATuFC4kU0R8zu0p5ZG_QE=.1acb1273-7fab-4780-b909-c51b4b7c16e4@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <U29E6VqWoNuH9A9990kbQPATuFC4kU0R8zu0p5ZG_QE=.1acb1273-7fab-4780-b909-c51b4b7c16e4@github.com>
Message-ID: <PdeiuNW-Aqa1161UJeEuicfEtakSBplXvZTIYFTPlOM=.086c34f3-49eb-4c68-86d0-3aec5434709d@github.com>

On Fri, 8 Nov 2024 13:43:26 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains three commits:
> 
>  - Updating copyright years and removing an unneccessary import for Gatherers
>  - Removing PreviewFeature from Gatherers
>  - Updating @since to 24 for Gatherers

@liach @AlanBateman rebase on current mainline and fixed the conflicts and pushed the update. The CSR is accepted so this should be ready to merge.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2464805059

From mullan at openjdk.org  Fri Nov  8 13:49:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 8 Nov 2024 13:49:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=08
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From pchilanomate at openjdk.org  Fri Nov  8 13:48:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 8 Nov 2024 13:48:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
Message-ID: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com>

On Wed, 30 Oct 2024 17:23:31 GMT, Coleen Phillimore <coleenp at openjdk.org> wrote:

>> Patricio Chilano Mateo has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>>  - Add ObjectWaiter::at_monitorenter
>
> src/hotspot/share/oops/stackChunkOop.inline.hpp line 189:
> 
>> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const {
>> 188:   ObjectWaiter* waiter = object_waiter();
>> 189:   if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) {
> 
> Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; }
> 
> Not sure what this is excluding.

I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case.

> src/hotspot/share/runtime/continuationFreezeThaw.cpp line 1657:
> 
>> 1655: }
>> 1656: 
>> 1657: template<typename ConfigT, bool preempt>
> 
> This function is kind of big, do we really want it duplicated to pass preempt as a template parameter?

I checked and release build is same size and fast/slow debug difference is only about 16kb. Since it doesn?t hurt I would rather not touch the fast paths, but I see `ConfigT` has been unused for some time now so I can do a follow up cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834427410
PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834425311

From pchilanomate at openjdk.org  Fri Nov  8 13:48:03 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Fri, 8 Nov 2024 13:48:03 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v4]
In-Reply-To: <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <Llxn-kp9dV4GVGQwjQBsqigyHqMvXeFBVSw3zMVTNyY=.b55bfdc9-1bb6-4035-a6eb-79840c820f00@github.com>
 <_9UitJwAQtkjVFcSNwxZuuxBI9HaJ3N0fLHTIcVHyk8=.229fa38b-deca-4adf-974f-c8301ae6cd5d@github.com>
Message-ID: <4wpTgmx1V3RtcHOC0q-19yKgMwSg4og_30EdNvz6oA0=.d8be3ea5-7a30-4ec9-89cb-a013318189f2@github.com>

On Fri, 8 Nov 2024 13:43:14 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> src/hotspot/share/oops/stackChunkOop.inline.hpp line 189:
>> 
>>> 187: inline ObjectMonitor* stackChunkOopDesc::current_pending_monitor() const {
>>> 188:   ObjectWaiter* waiter = object_waiter();
>>> 189:   if (waiter != nullptr && (waiter->is_monitorenter() || (waiter->is_wait() && (waiter->at_reenter() || waiter->notified())))) {
>> 
>> Can we hide this conditional under ObjectWaiter::pending_monitor() { all this stuff with a comment; }
>> 
>> Not sure what this is excluding.
>
> I added method `at_monitorenter()` to ObjectWaiter. We are checking if the vthread is blocked trying to acquire (or re-acquire for the wait case) the monitor. While looking at these I also noticed we were missing a call to `current_waiting_monitor` in `JvmtiEnvBase::get_locked_objects_in_frame()` so I added it. We didn?t had a case for this so it went unnoticed. I extended JVMTI test `VThreadMonitorTest.java` to cover this case.

Thanks for pointing at this code because I also realized there is a nice cleanup that can be done here. First these methods should be moved to `java_lang_VirtualThread` class where they naturally belong (these are the equivalent of the JavaThread methods but for an unmounted vthread). Also the `objectWaiter` field can be added to the VirtualThread class rather than the stackChunk, which not?only is more appropriate too and gives us the get/set symmetry for these methods, but we can also save memory since one virtual thread can have many stackChunks around. I have a patch for that but I?ll do it after this PR to avoid new changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21565#discussion_r1834429835

From sgehwolf at openjdk.org  Fri Nov  8 13:49:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 13:49:57 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v47]
In-Reply-To: <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
Message-ID: <_dnt7V8HD0WtXFX_uAEe3C90eu9Ec5uNZpS1JNwbhc0=.5516c31a-4424-41b6-bb09-e39c72b4b501@github.com>

On Fri, 8 Nov 2024 10:42:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports from VMProps

GHA failure of MacOSX on aarch64 is still infra related.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2464808704

From vklang at openjdk.org  Fri Nov  8 13:56:38 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 13:56:38 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
Message-ID: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:

  Updating the copyright year of the Gatherer benchmarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21686/files
  - new: https://git.openjdk.org/jdk/pull/21686/files/6e8e1415..d4a6cfaa

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21686&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21686&range=02-03

  Stats: 11 lines in 11 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21686.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21686/head:pull/21686

PR: https://git.openjdk.org/jdk/pull/21686

From asemenyuk at openjdk.org  Fri Nov  8 13:59:45 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 8 Nov 2024 13:59:45 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v5]
In-Reply-To: <upTvje0kzoe3TIIzbLcXiNFKznTd26nr6VUUE7fjwaU=.9e4ea989-c45b-4cd2-ab87-743b913acad8@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <upTvje0kzoe3TIIzbLcXiNFKznTd26nr6VUUE7fjwaU=.9e4ea989-c45b-4cd2-ab87-743b913acad8@github.com>
Message-ID: <ePsv5AeQ3DlaROoazqlpHKjhbbo9-x0_4btkNwaASMU=.aebeb6e2-9d48-402a-8229-0e636d28aa00@github.com>

On Fri, 8 Nov 2024 13:39:08 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove neutralLangId in VersionInfo.cpp

Marked as reviewed by asemenyuk (Reviewer).

jpackage changes look good. Thank you!

-------------

PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2423878603
PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2464832211

From qamai at openjdk.org  Fri Nov  8 14:08:48 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Nov 2024 14:08:48 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out
In-Reply-To: <drz5Vrt9cpnmazTP1Ungn8OSwI_GaO5F8Vhy9KKwFbY=.dfcd41ba-6dee-4933-984e-cf8405565cb1@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
 <drz5Vrt9cpnmazTP1Ungn8OSwI_GaO5F8Vhy9KKwFbY=.dfcd41ba-6dee-4933-984e-cf8405565cb1@github.com>
Message-ID: <mUSY0a1Mf2cQJPqsqt0Mvc4kmcBv3RA74AmKuS2YMZU=.d1e9f985-0d8a-4357-bb8f-bdf2674704aa@github.com>

On Fri, 8 Nov 2024 12:22:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
>> 
>>     // Keep the 2 threads operating on the same scope
>>     int k = lock.getAndAdd(1) + 1;
>>     while (k != i * 2) {
>>         Thread.onSpinWait();
>>         k = lock.get();
>>     }
>> 
>> Given the initial condition:
>> 
>>     Thread 1: i = 0
>>     Thread 2: i = 0
>>     lock: -2
>> 
>> The `lock` then undergoes the following operations:
>> 
>> 
>> 
>>         Thread 1          Thread 2         lock value
>>       getAndAdd(1)                            -1
>>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
>> 
>> 
>> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
>> 
>> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
>> 
>> Please take a look, thanks a lot.
>
> I'm playing with something like this:
> 
> 
> @Test
>     public void testAcquireCloseRace() throws InterruptedException {
>         int MAX_ITERATIONS = 1000;
>         AtomicInteger iteration = new AtomicInteger();
>         boolean[] result = new boolean[1];
>         MemorySessionImpl[] scopes = new MemorySessionImpl[MAX_ITERATIONS];
>         for (int i = 0; i < MAX_ITERATIONS; i++) {
>             scopes[i] = MemorySessionImpl.toMemorySession(Arena.ofShared());
>         }
> 
>         // This thread tries to close the scopes
>         Thread t1 = new Thread(() -> {
>             int it = iteration.get();
>             while (it < MAX_ITERATIONS) {
>                 while (true) {
>                     try {
>                         scopes[it].close();
>                         // if we close successfully, the iteration is now completed
>                         break;
>                     } catch (IllegalStateException e) {
>                         // scope is acquired, wait and try again
>                         Thread.onSpinWait();
>                     }
>                 }
>                 // wait for other thread to complete its iteration
>                 int prev = it;
>                 while (prev == it) {
>                     Thread.onSpinWait();
>                     it = iteration.get();
>                 }
>             }
>         });
> 
>         // This thread tries to acquire the scopes, then check if it is alive after an acquire failure
>         Thread t2 = new Thread(() -> {
>             int it = iteration.get();
>             while (it < MAX_ITERATIONS) {
>                 while (true) {
>                     try {
>                         scopes[it].acquire0();
>                     } catch (IllegalStateException e) {
>                         // we failed to acquire, meaning the other thread has closed this scope
>                         if (scopes[it].isAlive()) {
>                             result[0] = true;
>                         }
>                         // this iteration is now completed
>                         break;
>                     }
>                     // if we get here, acquire was successful, so we need to release...
>                     scopes[it].release0();
>                     // ... and then try again
>                 }
>                 // advance to next iteration
>                 it = iteration.addAndGet(1);
>             }
>         });
> 
>         t1.start();
>         t2.start();
>         t1.join();
>         t2.join();
>         assertFalse(result[0]);
>     }
> 
> 
> I think I find this logic a bit more dir...

@mcimadamore I think your approach is more or less similar. Although it is a little bit clearer in terms of what index we are operating on, it is a bit less clear in terms of the synchronization mechanism, as it is spread out to a wider scope.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21976#issuecomment-2464849390

From alanb at openjdk.org  Fri Nov  8 14:16:33 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 14:16:33 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
Message-ID: <cRr3T8G6Px8ccWcZpfYnh6gjIjsA0Je3VDF-q0PNYos=.d655ea83-07eb-4819-b91c-28cf11b7ebae@github.com>

On Fri, 8 Nov 2024 13:56:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating the copyright year of the Gatherer benchmarks

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21686#pullrequestreview-2423918386

From alanb at openjdk.org  Fri Nov  8 15:18:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 15:18:08 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v47]
In-Reply-To: <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
Message-ID: <1sM7628A6QrdijAuL6eDqvDFN4FMwQSlY73OZscpV8Q=.01e5b484-b479-4963-979f-d004a30f04e0@github.com>

On Fri, 8 Nov 2024 10:42:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports from VMProps

I'm worked through the make + src changes and don't have any issues. I skimmed tests some didn't study closely. You will need to bump the copyright header of several jlink src files before integrating.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2465008109

From alanb at openjdk.org  Fri Nov  8 15:21:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 15:21:42 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v47]
In-Reply-To: <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
Message-ID: <BCsIMpxXnaWQQpJom8a9y2UPLGviAQCiwEcZt1uyzC8=.b4c1736f-e6f2-4c5b-9b76-16d968c5ea82@github.com>

On Fri, 8 Nov 2024 10:42:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports from VMProps

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2424083294

From nbenalla at openjdk.org  Fri Nov  8 15:40:36 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Fri, 8 Nov 2024 15:40:36 GMT
Subject: RFR: 8343780: Add since checker tests to the Tools area modules and
 add missing @since to  jdk.jfr.Recording
Message-ID: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>

Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html).

The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers.

The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK.

Notes: 
- I have also added an `@since` tag that was missing.
- You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test)

TIA

-------------

Commit messages:
 - remove backticks
 - 8343780

Changes: https://git.openjdk.org/jdk/pull/21982/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343780
  Stats: 16 lines in 6 files changed: 1 ins; 0 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21982/head:pull/21982

PR: https://git.openjdk.org/jdk/pull/21982

From mcimadamore at openjdk.org  Fri Nov  8 15:58:10 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 8 Nov 2024 15:58:10 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out
In-Reply-To: <drz5Vrt9cpnmazTP1Ungn8OSwI_GaO5F8Vhy9KKwFbY=.dfcd41ba-6dee-4933-984e-cf8405565cb1@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
 <drz5Vrt9cpnmazTP1Ungn8OSwI_GaO5F8Vhy9KKwFbY=.dfcd41ba-6dee-4933-984e-cf8405565cb1@github.com>
Message-ID: <wYK8xATk6tbcAMEyViglqnha-nAxORTMIlfM8-gx80s=.30146848-0704-4bf3-b088-9062b727080a@github.com>

On Fri, 8 Nov 2024 12:22:54 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
>> 
>>     // Keep the 2 threads operating on the same scope
>>     int k = lock.getAndAdd(1) + 1;
>>     while (k != i * 2) {
>>         Thread.onSpinWait();
>>         k = lock.get();
>>     }
>> 
>> Given the initial condition:
>> 
>>     Thread 1: i = 0
>>     Thread 2: i = 0
>>     lock: -2
>> 
>> The `lock` then undergoes the following operations:
>> 
>> 
>> 
>>         Thread 1          Thread 2         lock value
>>       getAndAdd(1)                            -1
>>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
>> 
>> 
>> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
>> 
>> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
>> 
>> Please take a look, thanks a lot.
>
> I'm playing with something like this:
> 
> 
> @Test
>     public void testAcquireCloseRace() throws InterruptedException {
>         int MAX_ITERATIONS = 1000;
>         AtomicInteger iteration = new AtomicInteger();
>         boolean[] result = new boolean[1];
>         MemorySessionImpl[] scopes = new MemorySessionImpl[MAX_ITERATIONS];
>         for (int i = 0; i < MAX_ITERATIONS; i++) {
>             scopes[i] = MemorySessionImpl.toMemorySession(Arena.ofShared());
>         }
> 
>         // This thread tries to close the scopes
>         Thread t1 = new Thread(() -> {
>             int it = iteration.get();
>             while (it < MAX_ITERATIONS) {
>                 while (true) {
>                     try {
>                         scopes[it].close();
>                         // if we close successfully, the iteration is now completed
>                         break;
>                     } catch (IllegalStateException e) {
>                         // scope is acquired, wait and try again
>                         Thread.onSpinWait();
>                     }
>                 }
>                 // wait for other thread to complete its iteration
>                 int prev = it;
>                 while (prev == it) {
>                     Thread.onSpinWait();
>                     it = iteration.get();
>                 }
>             }
>         });
> 
>         // This thread tries to acquire the scopes, then check if it is alive after an acquire failure
>         Thread t2 = new Thread(() -> {
>             int it = iteration.get();
>             while (it < MAX_ITERATIONS) {
>                 while (true) {
>                     try {
>                         scopes[it].acquire0();
>                     } catch (IllegalStateException e) {
>                         // we failed to acquire, meaning the other thread has closed this scope
>                         if (scopes[it].isAlive()) {
>                             result[0] = true;
>                         }
>                         // this iteration is now completed
>                         break;
>                     }
>                     // if we get here, acquire was successful, so we need to release...
>                     scopes[it].release0();
>                     // ... and then try again
>                 }
>                 // advance to next iteration
>                 it = iteration.addAndGet(1);
>             }
>         });
> 
>         t1.start();
>         t2.start();
>         t1.join();
>         t2.join();
>         assertFalse(result[0]);
>     }
> 
> 
> I think I find this logic a bit more dir...

> @mcimadamore I think your approach is more or less similar. Although it is a little bit clearer in terms of what index we are operating on, it is a bit less clear in terms of the synchronization mechanism, as it is spread out to a wider scope.

IMHO both synchronization mechanisms are spread out in scope, as no matter what you'll have an action at a distance. FWIW, I find the logic with index updating particularly hard to read -- and a very indirect way to coordinate the two threads, which is why I tried to reach for something a little more explicit.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21976#issuecomment-2465099538

From jvernee at openjdk.org  Fri Nov  8 16:04:10 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Fri, 8 Nov 2024 16:04:10 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out
In-Reply-To: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
Message-ID: <VyT-UiP9G8xXKk9sToKxQkebcscu4oGJKxccKm2deY0=.3190cdae-4876-4c64-afe2-ff5cff52e4fd@github.com>

On Fri, 8 Nov 2024 11:56:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
> 
>     // Keep the 2 threads operating on the same scope
>     int k = lock.getAndAdd(1) + 1;
>     while (k != i * 2) {
>         Thread.onSpinWait();
>         k = lock.get();
>     }
> 
> Given the initial condition:
> 
>     Thread 1: i = 0
>     Thread 2: i = 0
>     lock: -2
> 
> The `lock` then undergoes the following operations:
> 
> 
> 
>         Thread 1          Thread 2         lock value
>       getAndAdd(1)                            -1
>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
> 
> 
> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
> 
> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
> 
> Please take a look, thanks a lot.

I think I also prefer Maurizio's version.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21976#issuecomment-2465114542

From schernyshev at openjdk.org  Fri Nov  8 16:13:42 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 8 Nov 2024 16:13:42 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
Message-ID: <XgUP3oTSxxBjeS0CJNMhixZP45NYBdsAOepkDuQvhz8=.66911e34-2b98-4e04-a0bc-f4b9ffed6c4b@github.com>

On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343191
>  - patch reimplemented
>  - fix the logic that skips duplicate controller's mount points
>  - 8343191: Cgroup v1 subsystem fails to set subsystem path

Hi Severin, thanks for this question. I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
I believe it's because v2 uses --cgroupns=private by default, in which cgroup is mounted at hierarchy leaf, so both `_root` and `cgroup_path` are `/`.

It's an open question what happens if a process is moved between cgroups in v2 mode. I will look into it and file an issue if there are problems in v2.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2465146149

From pminborg at openjdk.org  Fri Nov  8 16:19:30 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Nov 2024 16:19:30 GMT
Subject: RFR: 8343844: Add benchmarks for superword/autovectorization in FFM
 BulkOperations
Message-ID: <dKiL59B0_f9HqviLKyFCLoV14mw20ZnDgBb1KYcY1bM=.5ba48263-2375-4206-a54e-98170e618626@github.com>

This PR proposed to add a few benchmarks using  superword/autovectorization

-------------

Commit messages:
 - Add benchmarks

Changes: https://git.openjdk.org/jdk/pull/21988/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21988&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343844
  Stats: 36 lines in 1 file changed: 36 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21988.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21988/head:pull/21988

PR: https://git.openjdk.org/jdk/pull/21988

From liach at openjdk.org  Fri Nov  8 16:22:13 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Nov 2024 16:22:13 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
Message-ID: <2GUfR_26OiD5yS6fM4InA4PPngjwrfCAEYhES8DcRMk=.83a6cb05-9a8a-40e0-8f07-415da9827e9f@github.com>

On Fri, 8 Nov 2024 13:56:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating the copyright year of the Gatherer benchmarks

The removal of preview toggles look good. Confirmed that since in stream packages and removal of preview toggles tests/micro look good.

Side comment: With the `jvmArgs` cleared on benchmark `@Fork`, you can just make it `@Fork(1)` instead of `@Fork(value = 1)`.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21686#pullrequestreview-2424229448

From vklang at openjdk.org  Fri Nov  8 16:28:56 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 8 Nov 2024 16:28:56 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <2GUfR_26OiD5yS6fM4InA4PPngjwrfCAEYhES8DcRMk=.83a6cb05-9a8a-40e0-8f07-415da9827e9f@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
 <2GUfR_26OiD5yS6fM4InA4PPngjwrfCAEYhES8DcRMk=.83a6cb05-9a8a-40e0-8f07-415da9827e9f@github.com>
Message-ID: <gza4QT8nV8wKCYAcOYysUDYtdR0nCDhRr9kL0hSwozU=.c211bc3d-9d6e-46ed-ac24-d1be5c32d31f@github.com>

On Fri, 8 Nov 2024 16:17:39 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Updating the copyright year of the Gatherer benchmarks
>
> The removal of preview toggles look good. Confirmed that since in stream packages and removal of preview toggles tests/micro look good.
> 
> Side comment: With the `jvmArgs` cleared on benchmark `@Fork`, you can just make it `@Fork(1)` instead of `@Fork(value = 1)`.

@liach 

>Side comment: With the jvmArgs cleared on benchmark @Fork, you can just make it @Fork(1) instead of @Fork(value = 1).

Yeah, I opted to keep it as-is to make the delta between old-and-new low (and to make adding additional params slightly faster). I'd be happy to change it if you insist, tho! :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2465208982

From sgehwolf at openjdk.org  Fri Nov  8 16:38:39 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 16:38:39 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v47]
In-Reply-To: <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <-500l71ou1gWtn3Z2OGAqnYB4YRKV_OPKYFFm2rZ9Cs=.ff410c53-2e5d-48c4-82a3-68c353e1a99f@github.com>
Message-ID: <5dKYeUfeXZOWEEBLOM0uyTBSi7_soyQ2yhVlgP4_-t0=.278c8341-1da9-4ced-9928-f26b133d573f@github.com>

On Fri, 8 Nov 2024 10:42:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports from VMProps

Thanks for the review!

> You will need to bump the copyright header of several jlink src files before integrating.

OK. Let me work on that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2465228449

From mcimadamore at openjdk.org  Fri Nov  8 16:40:28 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 8 Nov 2024 16:40:28 GMT
Subject: RFR: 8343844: Add benchmarks for superword/autovectorization in
 FFM BulkOperations
In-Reply-To: <dKiL59B0_f9HqviLKyFCLoV14mw20ZnDgBb1KYcY1bM=.5ba48263-2375-4206-a54e-98170e618626@github.com>
References: <dKiL59B0_f9HqviLKyFCLoV14mw20ZnDgBb1KYcY1bM=.5ba48263-2375-4206-a54e-98170e618626@github.com>
Message-ID: <DQgPiU5YYj3mkHBG_VMqc7yhfPo3suPDx2TMJA0ZCzs=.9ba24428-ca21-4b0f-bae2-106e45a0a6e4@github.com>

On Fri, 8 Nov 2024 16:13:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to add a few benchmarks using  superword/autovectorization

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21988#pullrequestreview-2424305115

From pminborg at openjdk.org  Fri Nov  8 16:40:28 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Fri, 8 Nov 2024 16:40:28 GMT
Subject: Integrated: 8343844: Add benchmarks for superword/autovectorization in
 FFM BulkOperations
In-Reply-To: <dKiL59B0_f9HqviLKyFCLoV14mw20ZnDgBb1KYcY1bM=.5ba48263-2375-4206-a54e-98170e618626@github.com>
References: <dKiL59B0_f9HqviLKyFCLoV14mw20ZnDgBb1KYcY1bM=.5ba48263-2375-4206-a54e-98170e618626@github.com>
Message-ID: <NCg1AfjKM79Jb1-o9GY_6oWeOjTBoWViFmR6GIZXdgs=.167e23e1-50b9-44cf-9c88-a20f04f6c106@github.com>

On Fri, 8 Nov 2024 16:13:28 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposed to add a few benchmarks using  superword/autovectorization

This pull request has now been integrated.

Changeset: 2fb0c1dd
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2fb0c1dd62f1c690cf6b78f5cdfe18b10c991886
Stats:     36 lines in 1 file changed: 36 ins; 0 del; 0 mod

8343844: Add benchmarks for superword/autovectorization in FFM BulkOperations

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/21988

From qamai at openjdk.org  Fri Nov  8 16:59:48 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Nov 2024 16:59:48 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out [v2]
In-Reply-To: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
Message-ID: <JXtMZfC1mGBWHP2QByLjJzcjzoWiwDDDxPGDp3Gu5m4=.7010d3f7-045f-42ed-a0fb-7ab2a1488cc4@github.com>

> Hi,
> 
> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
> 
>     // Keep the 2 threads operating on the same scope
>     int k = lock.getAndAdd(1) + 1;
>     while (k != i * 2) {
>         Thread.onSpinWait();
>         k = lock.get();
>     }
> 
> Given the initial condition:
> 
>     Thread 1: i = 0
>     Thread 2: i = 0
>     lock: -2
> 
> The `lock` then undergoes the following operations:
> 
> 
> 
>         Thread 1          Thread 2         lock value
>       getAndAdd(1)                            -1
>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
> 
> 
> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
> 
> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
> 
> Please take a look, thanks a lot.

Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:

  refactor the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21976/files
  - new: https://git.openjdk.org/jdk/pull/21976/files/940b7d04..e77ce9e8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21976&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21976&range=00-01

  Stats: 24 lines in 1 file changed: 10 ins; 6 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21976.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21976/head:pull/21976

PR: https://git.openjdk.org/jdk/pull/21976

From qamai at openjdk.org  Fri Nov  8 16:59:48 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Fri, 8 Nov 2024 16:59:48 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out
In-Reply-To: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
Message-ID: <cecpfcW4mWkSY11pJ8fR8UVdgxDT43magTrFGH2DIR4=.d8183369-d5c0-42bb-a6f1-e6c98c15df8c@github.com>

On Fri, 8 Nov 2024 11:56:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
> 
>     // Keep the 2 threads operating on the same scope
>     int k = lock.getAndAdd(1) + 1;
>     while (k != i * 2) {
>         Thread.onSpinWait();
>         k = lock.get();
>     }
> 
> Given the initial condition:
> 
>     Thread 1: i = 0
>     Thread 2: i = 0
>     lock: -2
> 
> The `lock` then undergoes the following operations:
> 
> 
> 
>         Thread 1          Thread 2         lock value
>       getAndAdd(1)                            -1
>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
> 
> 
> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
> 
> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
> 
> Please take a look, thanks a lot.

Sure, I have refactored the test, no failure after 200 runs.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21976#issuecomment-2465276187

From liach at openjdk.org  Fri Nov  8 17:01:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Nov 2024 17:01:14 GMT
Subject: RFR: 8342707: Prepare Gatherers for graduation from Preview [v4]
In-Reply-To: <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
 <Qn_qv_7zR1pCaqHEWsQsmxCM_1L2LhgU3M2YG3r4u60=.0e3ffbf6-cec0-4177-a0a8-74c374c96dd1@github.com>
Message-ID: <NLEcCoYK_MBVYwO-xXEiAjRY1Kh_B1FQLCXgk__H424=.251065bf-bd7f-46b8-baa5-2c2fa370122d@github.com>

On Fri, 8 Nov 2024 13:56:38 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Make final adjustments to drop PreviewFeature and updating the @ since markers.
>
> Viktor Klang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Updating the copyright year of the Gatherer benchmarks

The current form makes it easy to add jvm args in the future, too.  It's totally fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21686#issuecomment-2465277946

From sgehwolf at openjdk.org  Fri Nov  8 17:07:55 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 8 Nov 2024 17:07:55 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v48]
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <mo5Snm_t2jL26zuC8hsdRvcybh4n_1FW1CtuqY3-rhA=.e1648d7b-492b-4d85-9135-627822dd57dc@github.com>

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:

  Update copyright headers

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/14787/files
  - new: https://git.openjdk.org/jdk/pull/14787/files/0bf4843d..2042fc34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=47
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=14787&range=46-47

  Stats: 10 lines in 10 files changed: 0 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/14787.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/14787/head:pull/14787

PR: https://git.openjdk.org/jdk/pull/14787

From alanb at openjdk.org  Fri Nov  8 17:12:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 8 Nov 2024 17:12:09 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v48]
In-Reply-To: <mo5Snm_t2jL26zuC8hsdRvcybh4n_1FW1CtuqY3-rhA=.e1648d7b-492b-4d85-9135-627822dd57dc@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <mo5Snm_t2jL26zuC8hsdRvcybh4n_1FW1CtuqY3-rhA=.e1648d7b-492b-4d85-9135-627822dd57dc@github.com>
Message-ID: <xtKDhlwiW7SGgzonmJl849VMxyFnvQjCZQJPOU_54TY=.1035463a-340e-4b04-a45d-3be42358d794@github.com>

On Fri, 8 Nov 2024 17:07:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright headers

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2424410814

From naoto at openjdk.org  Fri Nov  8 17:30:22 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Nov 2024 17:30:22 GMT
Subject: RFR: 8343804: Show the default time zone with -XshowSettings
 option
In-Reply-To: <j_12hylBtkrFJuhf1F10IVUmXmQiPeZbbeijQyV5rKw=.dcd79a91-acfc-4a4e-9c5c-da50cbb89b7a@github.com>
References: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
 <j_12hylBtkrFJuhf1F10IVUmXmQiPeZbbeijQyV5rKw=.dcd79a91-acfc-4a4e-9c5c-da50cbb89b7a@github.com>
Message-ID: <qo1Rh5-U1jUvW7kE49-u5dljBiRGU_2CG4u8wSL8H80=.748f0e9c-8467-49de-b7b7-0f2cb5d222d9@github.com>

On Fri, 8 Nov 2024 04:40:15 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Naoto, this looks good to me. The test itself could assert that the printed timezone is indeed the default timezone, but if you prefer it in its current form, that's fine too.

Thank you, Jai. I considererd that too, i.e. affirming the actual tz value. I decided not to do it aligning with other tests that do not affirm their values either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21965#issuecomment-2465370971

From joehw at openjdk.org  Fri Nov  8 17:48:22 2024
From: joehw at openjdk.org (Joe Wang)
Date: Fri, 8 Nov 2024 17:48:22 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v3]
In-Reply-To: <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
 <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
Message-ID: <oalw1QxC95AUdy9-N0ik7vQnd2NApcoBHmpxvsC2seQ=.5a81c1d6-4d0e-4cab-8886-2d0f1a39d410@github.com>

On Thu, 7 Nov 2024 18:30:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
>> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
>> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
>> Unit tests was not affected:
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp                                     516   516     0     0
>>    jtreg:test/jdk/javax/xml                             70    70     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> The tier1 is OK too.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317542: Specjvm::xml have scalability issue for high vCPU numbers

Thanks for the great work! Nice improvement on systems with high vCPUs. There are other areas worth checking. But this is a good step forward.

-------------

Marked as reviewed by joehw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21815#pullrequestreview-2424531410

From duke at openjdk.org  Fri Nov  8 17:54:17 2024
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 8 Nov 2024 17:54:17 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v13]
In-Reply-To: <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <RFrK9ALsBo8MgXYfB15CRRQepo1N8HRHt4o4pWgWVvg=.9e8a45d5-9564-4e69-94f8-976f6587bd37@github.com>
 <KSJbqk7LJWwqQ22HOiFpiG542N_HJ_b6p0Y2rEkVvy8=.d1353202-8207-49ca-bc4f-a0cebf550258@github.com>
 <urz1bJ3br1yVNWYz6url1aGZHACIhdv1fQ5yEHpnaLA=.834e856e-b313-4b4c-9c85-072b0fb57a7e@github.com>
Message-ID: <yU4WXt45TjPWFSLDvknTnRDOG1gc0169uz9Cb4SmFIM=.9a8faece-9c7f-46e1-95ac-0b24e6cb0d10@github.com>

On Wed, 30 Oct 2024 11:05:17 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> make/scripts/compare.sh line 1457:
>> 
>>> 1455:         THIS_SEC_BIN="$THIS_SEC_DIR/sec-bin.zip"
>>> 1456:         if [ "$OPENJDK_TARGET_OS" = "windows" ]; then
>>> 1457:             JGSS_WINDOWS_BIN="jgss-windows-x64-bin.zip"
>> 
>> This is now being defined for windows-aarch64 too, when it previously wasn't.  That seems wrong,
>> given the "x64" suffix.
>
> Well... this was broken on windows-aarch64 before, too, since then it would have looked for `jgss-windows-i586-bin.zip`. 
> 
> I'm going to leave this as it is. Obviously there is a lot more work needed to get the compare script running on windows-aarch64, and I seriously doubt anyone care about that platform enough to spend that time (Microsoft themselves seems to have all but abandoned the windows-aarch64 port...).

@magicus @kimbarrett @shipilev Thanks for catching this. We want to get this working on Windows AArch64. I have filed https://bugs.openjdk.org/browse/JDK-8343857.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834839335

From aivanov at openjdk.org  Fri Nov  8 18:18:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Fri, 8 Nov 2024 18:18:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
Message-ID: <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>

On Tue, 29 Oct 2024 17:06:08 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> src/java.desktop/share/classes/java/awt/MouseInfo.java line 68:
>> 
>>> 66:      * @throws SecurityException if a security manager exists and its
>>> 67:      *            {@code checkPermission} method doesn't allow the operation
>>> 68:      * @see       GraphicsConfiguration
>> 
>> Is `GraphicsConfiguration` removed from the list because it's already mentioned and linked in the description above? Is it intentional?
>
>> Is it intentional?
> 
> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again?

It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).

Without the `@see` tag, one has to read the entire description to find the link.

It looks subtle. We can restore the `@see`-link later if deemed necessary.

Does anyone else have an opinion?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1826266398

From duke at openjdk.org  Fri Nov  8 18:29:37 2024
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 8 Nov 2024 18:29:37 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <Amn2B-rwKXoBUGxQ902tzohzEwP-Za_jLOq9iovXRzk=.fa631f1b-9ebd-44fc-8f3f-422de6b192b5@github.com>

On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline buildJniFunctionName

src/hotspot/os/posix/include/jvm_md.h line 41:

> 39: 
> 40: #define JNI_ONLOAD_SYMBOLS   {"JNI_OnLoad"}
> 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"}

are these changes related to the Windows 32-bit x86 port?

src/hotspot/os/posix/os_posix.cpp line 699:

> 697: }
> 698: 
> 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) {

are these changes related to the Windows 32-bit x86 port?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878288
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834878195

From honkar at openjdk.org  Fri Nov  8 18:36:29 2024
From: honkar at openjdk.org (Harshitha Onkar)
Date: Fri, 8 Nov 2024 18:36:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
Message-ID: <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>

On Fri, 1 Nov 2024 20:26:45 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>>> Is it intentional?
>> 
>> It was probably by mistake. but you are right, I see it mentioned already in the doc. I don't think we need to mention it again?
>
> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).
> 
> Without the `@see` tag, one has to read the entire description to find the link.
> 
> It looks subtle. We can restore the `@see`-link later if deemed necessary.
> 
> Does anyone else have an opinion?

I can add it back if it is more convenient and readable to have the `@see` tag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1834883137

From kbarrett at openjdk.org  Fri Nov  8 18:53:34 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 8 Nov 2024 18:53:34 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <AK84V2NwC_9BcgrVVckQUIy-yELNx22fLrMgezMupr8=.6c642b1f-75d2-4ad6-b0f6-76b499d34f87@github.com>

On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline buildJniFunctionName

Still looks good.

-------------

Marked as reviewed by kbarrett (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424652542

From kbarrett at openjdk.org  Fri Nov  8 18:53:35 2024
From: kbarrett at openjdk.org (Kim Barrett)
Date: Fri, 8 Nov 2024 18:53:35 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <Amn2B-rwKXoBUGxQ902tzohzEwP-Za_jLOq9iovXRzk=.fa631f1b-9ebd-44fc-8f3f-422de6b192b5@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
 <Amn2B-rwKXoBUGxQ902tzohzEwP-Za_jLOq9iovXRzk=.fa631f1b-9ebd-44fc-8f3f-422de6b192b5@github.com>
Message-ID: <8YGMIrEQv6aPy_9IXzP9VqZ6tB0CTSwnH1XkfkDlXzM=.c1dd03d4-6d33-4dc8-a8b1-691a0616a6a5@github.com>

On Fri, 8 Nov 2024 18:26:25 GMT, Saint Wesonga <duke at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Inline buildJniFunctionName
>
> src/hotspot/os/posix/include/jvm_md.h line 41:
> 
>> 39: 
>> 40: #define JNI_ONLOAD_SYMBOLS   {"JNI_OnLoad"}
>> 41: #define JNI_ONUNLOAD_SYMBOLS {"JNI_OnUnload"}
> 
> are these changes related to the Windows 32-bit x86 port?

After removal of Windows 32-bit x86 port, all definitions of these macros are identical, so are merged into jvm.h.
There is additional followup work involving these: see https://bugs.openjdk.org/browse/JDK-8343703.

> src/hotspot/os/posix/os_posix.cpp line 699:
> 
>> 697: }
>> 698: 
>> 699: void os::print_jni_name_prefix_on(outputStream* st, int args_size) {
> 
> are these changes related to the Windows 32-bit x86 port?

As part of removal of Windows 32-bit x86 port, these functions are no longer needed nor called, and all
definitions removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900456
PR Review Comment: https://git.openjdk.org/jdk/pull/21744#discussion_r1834900337

From acobbs at openjdk.org  Fri Nov  8 19:07:16 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 8 Nov 2024 19:07:16 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v3]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <dnV6AR8eTDXrX505rYy-j0mocbws2Nlf2-HWGGCoVac=.cf4f83dd-e6cb-4d1b-96c8-680cf64457f3@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update copyright years.
 - Remove a few more @SuppressWarnings annotations.
 - Remove a few more @SuppressWarnings annotations.
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove unnecessary @SuppressWarnings annotations.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/7842dfea..a64d5594

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=01-02

  Stats: 131613 lines in 758 files changed: 103986 ins; 9698 del; 17929 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

PR: https://git.openjdk.org/jdk/pull/21852

From kvn at openjdk.org  Fri Nov  8 19:11:41 2024
From: kvn at openjdk.org (Vladimir Kozlov)
Date: Fri, 8 Nov 2024 19:11:41 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <S-U2kCBhx9cweO0eJDjSJzkeUaEM5eQ_zhGBlgM7lnw=.9148cad5-1d30-43ca-a53d-f5912753cbb5@github.com>

On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline buildJniFunctionName

Re-approve.

-------------

Marked as reviewed by kvn (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424696022

From acobbs at openjdk.org  Fri Nov  8 19:47:14 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Fri, 8 Nov 2024 19:47:14 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v4]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <gyv3FuuYnMooqIZ-RUDCDFFipdJUOZglHH6-k8WMv38=.f203c313-72a8-4f69-b47e-c97f5a5afe6c@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Put back @SuppressWarnings annotations to be fixed by JDK-8343286.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/a64d5594..9137373f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=02-03

  Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

PR: https://git.openjdk.org/jdk/pull/21852

From duke at openjdk.org  Fri Nov  8 20:12:19 2024
From: duke at openjdk.org (Saint Wesonga)
Date: Fri, 8 Nov 2024 20:12:19 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <qZoG7f7Hk2WfNJoQgA7VgAbQj-uS-ta8A32bRTPXDa8=.b1e7d03a-cf33-42c4-bfe9-9db52e2ea465@github.com>

On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline buildJniFunctionName

Marked as reviewed by swesonga at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2424836232

From naoto at openjdk.org  Fri Nov  8 20:25:24 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Nov 2024 20:25:24 GMT
Subject: RFR: 8343804: Show the default time zone with -XshowSettings
 option
In-Reply-To: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
References: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
Message-ID: <ERkjxr556CEr39CV5HQE_HUrb80Xf_R753PNDPnzsqA=.1ec876dd-4732-4fa6-a7dc-edc0b467aebb@github.com>

On Thu, 7 Nov 2024 23:36:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A small enhancement in the Java launcher. For diagnostic purposes, display the default time zone ID with the `-XshowSettings` option.

Thank you for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21965#issuecomment-2465689586

From naoto at openjdk.org  Fri Nov  8 20:25:25 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 8 Nov 2024 20:25:25 GMT
Subject: Integrated: 8343804: Show the default time zone with -XshowSettings
 option
In-Reply-To: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
References: <PF75-r9oixVmOoAtKzJzseUJkhu2FyI-JIbgwIHe3oY=.bb690ddd-d783-4d81-be37-32da9f0d2358@github.com>
Message-ID: <nV0NhQrhumlU_2tCrSp30TRM53aCN0UM72nLHG13RLA=.46ad0de1-f485-4b63-b087-58de522cfaa9@github.com>

On Thu, 7 Nov 2024 23:36:39 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> A small enhancement in the Java launcher. For diagnostic purposes, display the default time zone ID with the `-XshowSettings` option.

This pull request has now been integrated.

Changeset: 03298558
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0329855831102a48abf14b5befc933f84dfd3460
Stats:     9 lines in 2 files changed: 7 ins; 0 del; 2 mod

8343804: Show the default time zone with -XshowSettings option

Reviewed-by: iris, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/21965

From vlivanov at openjdk.org  Fri Nov  8 20:28:07 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 8 Nov 2024 20:28:07 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
Message-ID: <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>

On Fri, 8 Nov 2024 08:15:32 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Creating specialized IR to shield pattern from subsequent transforms in optimization pipeline

In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I don't see a compelling reason to do so. IMO matcher functionality is more than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` + `has_int_inputs()` predicate. For `MulUIVL` you additionally do input rewiring (using `forward_masked_input`), but (1)  `AndV src (Replicate 0xFFFFFFFF))` operands can be easily detected on matcher side (with an extra AD instruction); and (2) such optimization is limited because it is valid only for `0xFFFFFFFF` case while `has_uint_inputs() == true` for `C <=  0xFFFFFFFF`.

So, IMO `MulIVL` and `MulUIVL` nodes just add noise in Ideal graph without improving situation during matching.

src/hotspot/share/opto/vectornode.cpp line 2132:

> 2130:   // Directly forward masked inputs if
> 2131:   if (n->Opcode() == Op_AndV) {
> 2132:      return n->in(1)->Opcode() == Op_Replicate ? n->in(2) : n->in(1);

This particular check should ensure that Replicate constant is `0xFFFFFFFF`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2424864897
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1835023354

From almatvee at openjdk.org  Fri Nov  8 20:37:21 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 8 Nov 2024 20:37:21 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v5]
In-Reply-To: <upTvje0kzoe3TIIzbLcXiNFKznTd26nr6VUUE7fjwaU=.9e4ea989-c45b-4cd2-ab87-743b913acad8@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <upTvje0kzoe3TIIzbLcXiNFKznTd26nr6VUUE7fjwaU=.9e4ea989-c45b-4cd2-ab87-743b913acad8@github.com>
Message-ID: <ZkDqhHdTm0qlLe8U0VVg8-VGFVHVo2Y9A-NRXTFp47g=.b3b612dc-40ab-40da-9c23-d153853e34d4@github.com>

On Fri, 8 Nov 2024 13:39:08 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove neutralLangId in VersionInfo.cpp

src/jdk.jpackage/windows/native/libjpackage/VersionInfo.cpp line 1:

> 1: /*

Copyright year needs to be updated. "2020," -> "2020, 2024,".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21616#discussion_r1835031208

From iklam at openjdk.org  Fri Nov  8 21:02:16 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 8 Nov 2024 21:02:16 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v10]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <4wG_Fbrs_mcjApZOJqSgVNa5RUMflOwm9G3W4a4OzWQ=.6203c74f-0eaf-47dd-8121-a9e845153265@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 177 commits:

 - fixed merge with UseCompactObjectHeaders
 -  Merge branch 'master' into jep-483-candidate
 - fixed merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline
 - @DanHeidinga comment -- exit VM when runtimeSetup() fails
 - fixed merge
 - Merge branch 'master' into jep-483-candidate
 - 8343493: Perform module checks during MetaspaceShared::map_archives()
 - reverted changes in modules.cpp to make it easy to merge with mainline
 - Fixed whitespace; fixed minimal build
 - ... and 167 more: https://git.openjdk.org/jdk/compare/44ec501a...ce4c93ee

-------------

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=09
  Stats: 7193 lines in 107 files changed: 6358 ins; 513 del; 322 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From prr at openjdk.org  Fri Nov  8 21:05:41 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Nov 2024 21:05:41 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
Message-ID: <dhLdeBXtuGvkkliM-T9_iulm4XDPiHmO7jzAkk64sfQ=.71503749-f671-4a6f-b734-0e75e944aca8@github.com>

On Fri, 8 Nov 2024 13:49:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

Marked as reviewed by prr (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2424915104

From prr at openjdk.org  Fri Nov  8 21:05:42 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 8 Nov 2024 21:05:42 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
 <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
 <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>
Message-ID: <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@github.com>

On Fri, 1 Nov 2024 18:06:47 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

> > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test.
> 
> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
> 
> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
> 
> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198

I think I was just saying there appeared to be dead code in the test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1835053637

From schernyshev at openjdk.org  Fri Nov  8 21:20:46 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Fri, 8 Nov 2024 21:20:46 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
Message-ID: <-iPx4Rv3BEWIqj4KUMiPE4DI8CcRvEqy6jzZ3EMJCEY=.d8223257-466f-4a8b-aa9b-73cbcf6bd364@github.com>

On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343191
>  - patch reimplemented
>  - fix the logic that skips duplicate controller's mount points
>  - 8343191: Cgroup v1 subsystem fails to set subsystem path

It looks to me that v2 mode is not affected, at least the way it is in v1. In v2 mode, cgroup is mounted either at leaf node (private namespace), or the complete hierarchy at /sys/fs/cgroup (host namespace).

In host mode it works right away, as the full hierarchy is accessible. With a cgroup v2 created like this:


sudo mkdir -p /sys/fs/cgroup/test
echo 200000000 | sudo tee /sys/fs/cgroup/test/memory.max
``` 
The result would be

[0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.001s][debug][os,container] Detected cgroups v2 unified hierarchy
[0.001s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/test
[0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/test/memory.max
[0.001s][trace][os,container] Memory Limit is: 199999488



In the private namespace (it's a default setting in v2 hosts), it may fail migrating the process between cgroups (a docker issue?). It may look like the cgroup files are not mapped at all, while `cgroup_path` appears to be set relative to the old cgroup (the old cgroup isn't mapped though).

[0.000s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.001s][debug][os,container] Detected cgroups v2 unified hierarchy
[0.001s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/../../test
[0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../test/memory.max
[0.001s][debug][os,container] Open of file /sys/fs/cgroup/../../test/memory.max failed, No such file or directory
[0.001s][trace][os,container] Memory Limit failed: -2
[0.001s][trace][os,container] Memory Limit is: -2
[0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312
[0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../memory.max
[0.001s][debug][os,container] Open of file /sys/fs/cgroup/../../memory.max failed, No such file or directory
[0.001s][trace][os,container] Memory Limit failed: -2
[0.001s][trace][os,container] Memory Limit is: -2
[0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312
[0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../memory.max
[0.001s][debug][os,container] Open of file /sys/fs/cgroup/../memory.max failed, No such file or directory
[0.001s][trace][os,container] Memory Limit failed: -2
[0.001s][trace][os,container] Memory Limit is: -2
[0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312
[0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max
[0.001s][debug][os,container] Open of file /sys/fs/cgroup/memory.max failed, No such file or directory
[0.001s][trace][os,container] Memory Limit failed: -2


The following script

docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \
    sh -c "N=$(ls -la /sys/fs/cgroup | wc -l) ; sleep 10 ; echo $N ; ls -la /sys/fs/cgroup | wc -l" &
sleep 10
HOSTPID=$(sudo ps -ef | awk '/cgroup/ && !/docker/ && !/awk/ && !/grep/ { print $2 }')
echo $HOSTPID | sudo tee /sys/fs/cgroup/test/cgroup.procs > /dev/null
sleep 5

will display

74
1

means there are no files in  `/sys/fs/cgroup` after migration. It seems like it's not something that can be fixed in Java (and it hasn't much to do with this PR too).

When moved into a subgroup, such as

sudo docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \
    sh -c "sleep 10 ; /jdk/bin/java -Xlog:os+container=trace -version" &
sleep 5
HOSTPID=$(sudo ps -ef | awk '/container=trace/ && !/docker/ && !/awk/ { print $2 }')
CGPATH=$(cat /proc/$HOSTPID/cgroup | cut -f3 -d: )
sudo mkdir -p "/sys/fs/cgroup$CGPATH/test" 
echo $HOSTPID | sudo tee "/sys/fs/cgroup$CGPATH/test/cgroup.procs" > /dev/null
sleep 10

the cgroup will be mounted /sys/fs/cgroup, and the correct memory limit is displayed (thanks to the conroller path adjustment) - inherited from the parent.

[0.001s][debug][os,container] Detected cgroups v2 unified hierarchy
[0.001s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/test
[0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/test/memory.max
[0.001s][debug][os,container] Open of file /sys/fs/cgroup/test/memory.max failed, No such file or directory
[0.001s][trace][os,container] Memory Limit failed: -2
[0.001s][trace][os,container] Memory Limit is: -2
[0.001s][debug][os,container] container memory limit failed: -2, using host value 4105613312
[0.001s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max
[0.001s][trace][os,container] Memory Limit is: 419430400

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2465764229

From liach at openjdk.org  Fri Nov  8 22:04:40 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 8 Nov 2024 22:04:40 GMT
Subject: RFR: 8327858: Improve spliterator and forEach for single-element
 immutable collections [v4]
In-Reply-To: <wQ_yMnYZfpwLoEcOie-sTlUjn8cMeB76s_p3-PTv6Wc=.e1efc8ed-da0f-4a39-a238-1a4a1e419db3@github.com>
References: <UUULUZ6TOYKmKRqBcfSCUIia0twwVYuzxssahpMMFLA=.c0dd040a-9d67-4e8a-97b9-dd6fcb20f298@github.com>
 <wQ_yMnYZfpwLoEcOie-sTlUjn8cMeB76s_p3-PTv6Wc=.e1efc8ed-da0f-4a39-a238-1a4a1e419db3@github.com>
Message-ID: <PlgLieRAf5lyNg320NMaotx3mFcch5zSdero1U-THvA=.5a1c00cb-e9ba-4420-9a36-264b3aafe7c4@github.com>

On Fri, 11 Oct 2024 15:49:33 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Please review this patch that:
>> 1. Implemented `forEach` to optimize for 1 or 2 element collections.
>> 2. Implemented `spliterator` to optimize for a single element.
>> 
>> The default implementations for multiple-element immutable collections are fine as-is, specializing implementation doesn't provide much benefit.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 18 commits:
> 
>  - s'marks requests
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Add test to ensure reproducible iteration order
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Use the improved form in forEach
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - Null checks should probably be in the beginning...
>  - mark implicit null checks
>  - Merge branch 'master' of https://github.com/openjdk/jdk into feature/imm-coll-stream
>  - ... and 8 more: https://git.openjdk.org/jdk/compare/7276a1be...4f1f4f1b

Keep alive; maybe we can look forward to 25.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/15834#issuecomment-2465816966

From darcy at openjdk.org  Fri Nov  8 22:36:11 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 8 Nov 2024 22:36:11 GMT
Subject: RFR: 8343819: Link Float.NaN and Double.NaN to equivalence
 discussion in Double
In-Reply-To: <ugKltRYAkNLJ-GKuxYzTVOxVggO4tnX2KVZHw7Xh17g=.162e25f8-b5db-499b-a450-e4899a0b1f8c@github.com>
References: <ugKltRYAkNLJ-GKuxYzTVOxVggO4tnX2KVZHw7Xh17g=.162e25f8-b5db-499b-a450-e4899a0b1f8c@github.com>
Message-ID: <X9SIzcejpHn464YcSbEOMQ72kN9B-W5WLkVRj2m5nwM=.9aa3c813-2bdc-4102-b45c-2da4b105a736@github.com>

On Fri, 8 Nov 2024 10:10:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this doc-only enhancement which links the word _equivalent_ in `Float.NaN` and `Double.NaN` constant field descriptions to the floating-point equivalence discussion in `Double`.  
> 
>> It is equivalent to the value returned by{@code Float.intBitsToFloat(0x7fc00000)}.
> 
> For readers not well-versed in floating point, it may not be immediatly clear what _equivalent to_ means here.
> 
> The smallest improvement I could think of is to simply make the word `equivalent` a plain link to the floating-point equivalence discussion in the class description of `java.lang.Double`.
> 
> Verification: This is a doc-only change. I ran `make docs` and verified that the links resolve.

Looks fine; thanks.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21972#pullrequestreview-2425021526

From mcimadamore at openjdk.org  Fri Nov  8 22:36:11 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Fri, 8 Nov 2024 22:36:11 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out [v2]
In-Reply-To: <JXtMZfC1mGBWHP2QByLjJzcjzoWiwDDDxPGDp3Gu5m4=.7010d3f7-045f-42ed-a0fb-7ab2a1488cc4@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
 <JXtMZfC1mGBWHP2QByLjJzcjzoWiwDDDxPGDp3Gu5m4=.7010d3f7-045f-42ed-a0fb-7ab2a1488cc4@github.com>
Message-ID: <Z34oDev5QWsYDJ1O_08wBrZlqpIErW0CGbYE0BMM5lM=.c819050d-59a6-432b-8801-514dcb4b0701@github.com>

On Fri, 8 Nov 2024 16:59:48 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
>> 
>>     // Keep the 2 threads operating on the same scope
>>     int k = lock.getAndAdd(1) + 1;
>>     while (k != i * 2) {
>>         Thread.onSpinWait();
>>         k = lock.get();
>>     }
>> 
>> Given the initial condition:
>> 
>>     Thread 1: i = 0
>>     Thread 2: i = 0
>>     lock: -2
>> 
>> The `lock` then undergoes the following operations:
>> 
>> 
>> 
>>         Thread 1          Thread 2         lock value
>>       getAndAdd(1)                            -1
>>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
>> 
>> 
>> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
>> 
>> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
>> 
>> Please take a look, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the test

Thanks!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21976#pullrequestreview-2425021686

From sviswanathan at openjdk.org  Fri Nov  8 23:20:29 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 8 Nov 2024 23:20:29 GMT
Subject: RFR: 8310691: [REDO] [vectorapi] Refactor VectorShuffle
 implementation [v2]
In-Reply-To: <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>
References: <THkBB_CfGhq0BmtaUwwCMTe-drHLuL1z9gvGWfADS1Y=.03554793-4ec8-4178-9900-cc22328acd86@github.com>
 <NU6mVE36GBMrybhpFZv4J2ngaTI6-Qbj6z4eaGzyb5M=.20f1ae72-0a09-4169-9863-18adf17bf033@github.com>
 <tRYnC7MXtHxubnaDjsOXXR0kG_FHp-c_IcQeXRvhtuQ=.6372a187-4698-4505-88c4-0392b28ce3fa@github.com>
Message-ID: <eRnXECROJ99v9esircLUm1e8qhm71sJDHEWaR3dgbTo=.8e13b46c-0e57-4fcc-be9c-45b9daef12a3@github.com>

On Sun, 6 Oct 2024 10:24:53 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Quan Anh Mai has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains one commit:
>> 
>>   [vectorapi] Refactor VectorShuffle implementation
>
> I have adapted the patch in accordance with https://github.com/openjdk/jdk/pull/20634, I moved the index wrapping into C2 instead of making it a separate step as I think it seems clearer. Also, I think in the future we can eliminate this step so putting it in C2 would make the progress easier.
> 
> Please take a look, thanks a lot.

@merykitty Could you please merge with the latest and resolve conflicts?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21042#issuecomment-2465889165

From sviswanathan at openjdk.org  Fri Nov  8 23:21:30 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Fri, 8 Nov 2024 23:21:30 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
Message-ID: <RvkEn6C7t0sGn1e939rf2SU07rxGwBEocMIoxBe_D-Q=.b3439e6e-7a70-49fb-b9c8-28eff1d7fed8@github.com>

On Fri, 8 Nov 2024 20:25:10 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Creating specialized IR to shield pattern from subsequent transforms in optimization pipeline
>
> src/hotspot/share/opto/vectornode.cpp line 2132:
> 
>> 2130:   // Directly forward masked inputs if
>> 2131:   if (n->Opcode() == Op_AndV) {
>> 2132:      return n->in(1)->Opcode() == Op_Replicate ? n->in(2) : n->in(1);
> 
> This particular check should ensure that Replicate constant is `0xFFFFFFFF`.

Yes, this should ensure 0xFFFFFFFF.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1835148834

From weijun at openjdk.org  Sat Nov  9 00:57:23 2024
From: weijun at openjdk.org (Weijun Wang)
Date: Sat, 9 Nov 2024 00:57:23 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v9]
In-Reply-To: <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <iQOq6iXSVfDvowMEvThTJVYKu4j02aqBdpDfZfHzJmw=.2ef05391-1350-48e3-82d1-9500067f991d@github.com>
Message-ID: <R5hyTWGUzhiJE4SpPYJPTygHl6poBtz11qYOO6jeegQ=.32767fc6-3ca5-48bc-b491-d039d99083b8@github.com>

On Fri, 8 Nov 2024 13:49:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 224 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 214 more: https://git.openjdk.org/jdk/compare/d0077eec...6ad9192e

Marked as reviewed by weijun (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2425106253

From duke at openjdk.org  Sat Nov  9 02:00:48 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 02:00:48 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a ClassNotFoundException if
 the default FileSystemProvider is not the system-default provider
Message-ID: <Od0I9yl5-u-H_xf4YMZ4VNWBB4KZwTK2sglrhHKwnZg=.a5eeb439-1bad-4483-8ec4-99b89116976a@github.com>

Use the built-in file system provider rather than the custom file system provider.
Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

-------------

Commit messages:
 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider

Changes: https://git.openjdk.org/jdk/pull/21556/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21556&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331467
  Stats: 33 lines in 5 files changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21556.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21556/head:pull/21556

PR: https://git.openjdk.org/jdk/pull/21556

From duke at openjdk.org  Sat Nov  9 02:20:24 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 02:20:24 GMT
Subject: Withdrawn: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <Od0I9yl5-u-H_xf4YMZ4VNWBB4KZwTK2sglrhHKwnZg=.a5eeb439-1bad-4483-8ec4-99b89116976a@github.com>
References: <Od0I9yl5-u-H_xf4YMZ4VNWBB4KZwTK2sglrhHKwnZg=.a5eeb439-1bad-4483-8ec4-99b89116976a@github.com>
Message-ID: <5Ro4ykZrKBJi-uUjZasJGxb_Y0WJo48V92QSM1C762s=.4b1a80ed-abaa-45dc-8b32-10a4ab81dcf7@github.com>

On Thu, 17 Oct 2024 03:37:38 GMT, jyxzwd <duke at openjdk.org> wrote:

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21556

From duke at openjdk.org  Sat Nov  9 02:22:56 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 02:22:56 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a ClassNotFoundException if
 the default FileSystemProvider is not the system-default provider
Message-ID: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>

Use the built-in file system provider rather than the custom file system provider.
Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

-------------

Commit messages:
 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider

Changes: https://git.openjdk.org/jdk/pull/21997/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21997&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331467
  Stats: 33 lines in 5 files changed: 32 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21997/head:pull/21997

PR: https://git.openjdk.org/jdk/pull/21997

From jwaters at openjdk.org  Sat Nov  9 04:26:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 9 Nov 2024 04:26:55 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
 <SggKNDCRHs0irYUWCRal7gya7cZF7C8uXuXrlnwrMQQ=.fa48e548-3c8b-46bc-8dd8-1895d4fec107@github.com>
 <r54jnGo7jwe1fTmcza3ZTnn68s5GcKaTOf56YFO-CZ4=.03ca37d7-0807-47d8-8b77-02b2ee470401@github.com>
 <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com>
Message-ID: <z7cD_1hGCkWdN4OuPAD3iHgpJSFLy0AvU01uqF4N5-U=.6fe18746-1271-4367-b11d-18ea0e0fa362@github.com>

On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem
>> 
>> I'll also start looking into this in the meantime, unless you explicitly want me not to do so
>
>> > I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem
>> 
>> I'll also start looking into this in the meantime, unless you explicitly want me not to do so
> 
> Feel free to if you'd like to. Personally I don't consider it to be that important.

@plummercj @alexeysemenyukoracle @sashamatveev reawaiting review

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2466039622

From jwaters at openjdk.org  Sat Nov  9 04:26:55 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Sat, 9 Nov 2024 04:26:55 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v6]
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <QIIQn0HPDgZvyT1pKZVs-BfkcW_ds8noRd9DxaRinzU=.4e2105d2-16ef-4def-827e-a72a908cb0d2@github.com>

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did

Julian Waters has updated the pull request incrementally with one additional commit since the last revision:

  Copyright in VersionInfo.cpp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21616/files
  - new: https://git.openjdk.org/jdk/pull/21616/files/68767cbe..5e9039fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616

PR: https://git.openjdk.org/jdk/pull/21616

From asemenyuk at openjdk.org  Sat Nov  9 05:11:42 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 9 Nov 2024 05:11:42 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v6]
In-Reply-To: <QIIQn0HPDgZvyT1pKZVs-BfkcW_ds8noRd9DxaRinzU=.4e2105d2-16ef-4def-827e-a72a908cb0d2@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <QIIQn0HPDgZvyT1pKZVs-BfkcW_ds8noRd9DxaRinzU=.4e2105d2-16ef-4def-827e-a72a908cb0d2@github.com>
Message-ID: <PBIXzF52nhSB9wGuTo3Y8Yc_bSOcbtBoIz96JpsDdBY=.011bd2a0-89ac-4f27-9420-8898510113e5@github.com>

On Sat, 9 Nov 2024 04:26:55 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copyright in VersionInfo.cpp

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2425219022

From mchung at openjdk.org  Sat Nov  9 05:18:23 2024
From: mchung at openjdk.org (Mandy Chung)
Date: Sat, 9 Nov 2024 05:18:23 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v48]
In-Reply-To: <mo5Snm_t2jL26zuC8hsdRvcybh4n_1FW1CtuqY3-rhA=.e1648d7b-492b-4d85-9135-627822dd57dc@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <mo5Snm_t2jL26zuC8hsdRvcybh4n_1FW1CtuqY3-rhA=.e1648d7b-492b-4d85-9135-627822dd57dc@github.com>
Message-ID: <TdmV94IrIt9TstZW_YVdD-Aha9RD9iveGZjagkOt6Kg=.ca8479ef-5c62-48da-a28e-0af0d88f1fb5@github.com>

On Fri, 8 Nov 2024 17:07:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright headers

Marked as reviewed by mchung (Reviewer).

Thanks for the update and skimmed through the tests.  Looks good.

I also agree that better to fail early when detecting patched modules as described in JDK-8343839.

-------------

PR Review: https://git.openjdk.org/jdk/pull/14787#pullrequestreview-2425219797
PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2466054872

From qamai at openjdk.org  Sat Nov  9 09:41:58 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 9 Nov 2024 09:41:58 GMT
Subject: RFR: 8343793: Test java/foreign/TestMemorySession.java is timing
 out [v2]
In-Reply-To: <JXtMZfC1mGBWHP2QByLjJzcjzoWiwDDDxPGDp3Gu5m4=.7010d3f7-045f-42ed-a0fb-7ab2a1488cc4@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
 <JXtMZfC1mGBWHP2QByLjJzcjzoWiwDDDxPGDp3Gu5m4=.7010d3f7-045f-42ed-a0fb-7ab2a1488cc4@github.com>
Message-ID: <x0lwXQLOr06oJJJjPWV1Q2sI4KtNdX01SGOpZuiIe98=.d389b61e-c730-4808-b8f8-06a58227d976@github.com>

On Fri, 8 Nov 2024 16:59:48 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

>> Hi,
>> 
>> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
>> 
>>     // Keep the 2 threads operating on the same scope
>>     int k = lock.getAndAdd(1) + 1;
>>     while (k != i * 2) {
>>         Thread.onSpinWait();
>>         k = lock.get();
>>     }
>> 
>> Given the initial condition:
>> 
>>     Thread 1: i = 0
>>     Thread 2: i = 0
>>     lock: -2
>> 
>> The `lock` then undergoes the following operations:
>> 
>> 
>> 
>>         Thread 1          Thread 2         lock value
>>       getAndAdd(1)                            -1
>>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
>> 
>> 
>> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
>> 
>> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
>> 
>> Please take a look, thanks a lot.
>
> Quan Anh Mai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   refactor the test

Thanks for your reviews and suggestions. I have run the test a couple hundred times more, and there is no failure. GHA failures are in Installing dependencies steps, I have rerun it some times and there is no other failure there.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21976#issuecomment-2466147311

From alanb at openjdk.org  Sat Nov  9 09:00:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Nov 2024 09:00:52 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
Message-ID: <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>

On Sat, 9 Nov 2024 02:18:22 GMT, jyxzwd <duke at openjdk.org> wrote:

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java line 51:

> 49:     private static final String JAVA_HOME = System.getProperty("java.home");
> 50:     private static final Path BOOT_MODULES_JIMAGE =
> 51:             sun.nio.fs.DefaultFileSystemProvider.create().getPath(JAVA_HOME, "lib", "modules");

This is JDK internal so if the classes in jrt-fs.jar are loaded by a custom class loader, in for example JDK 17 or 21, then this will fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835320287

From eirbjo at openjdk.org  Sat Nov  9 05:56:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 9 Nov 2024 05:56:12 GMT
Subject: Integrated: 8343819: Link Float.NaN and Double.NaN to equivalence
 discussion in Double
In-Reply-To: <ugKltRYAkNLJ-GKuxYzTVOxVggO4tnX2KVZHw7Xh17g=.162e25f8-b5db-499b-a450-e4899a0b1f8c@github.com>
References: <ugKltRYAkNLJ-GKuxYzTVOxVggO4tnX2KVZHw7Xh17g=.162e25f8-b5db-499b-a450-e4899a0b1f8c@github.com>
Message-ID: <Ye9nFPdR6FHrnBTNnw9CrHRnBf-U8h8YZbOH7abdQgg=.575634d0-51e8-438a-b4e4-507bfa6ee586@github.com>

On Fri, 8 Nov 2024 10:10:28 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this doc-only enhancement which links the word _equivalent_ in `Float.NaN` and `Double.NaN` constant field descriptions to the floating-point equivalence discussion in `Double`.  
> 
>> It is equivalent to the value returned by{@code Float.intBitsToFloat(0x7fc00000)}.
> 
> For readers not well-versed in floating point, it may not be immediatly clear what _equivalent to_ means here.
> 
> The smallest improvement I could think of is to simply make the word `equivalent` a plain link to the floating-point equivalence discussion in the class description of `java.lang.Double`.
> 
> Verification: This is a doc-only change. I ran `make docs` and verified that the links resolve.

This pull request has now been integrated.

Changeset: 8a69893e
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8a69893e1d01f27b0be65cca69601856c1e54e98
Stats:     6 lines in 2 files changed: 0 ins; 0 del; 6 mod

8343819: Link Float.NaN and Double.NaN to equivalence discussion in Double

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/21972

From qamai at openjdk.org  Sat Nov  9 09:41:58 2024
From: qamai at openjdk.org (Quan Anh Mai)
Date: Sat, 9 Nov 2024 09:41:58 GMT
Subject: Integrated: 8343793: Test java/foreign/TestMemorySession.java is
 timing out
In-Reply-To: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
References: <v_sNUzTRAuwxZWdk63umtc0IJq0kJ9peBksYgJ3C12E=.419ef9d5-0df4-4383-91bc-686c70643033@github.com>
Message-ID: <3HHFRKVsZ72zcbp5WPgRRWfwzu5aq-5J8A7iEE4MLTs=.e35c4860-b933-4af6-af19-51b92e775af8@github.com>

On Fri, 8 Nov 2024 11:56:08 GMT, Quan Anh Mai <qamai at openjdk.org> wrote:

> Hi,
> 
> This patch fixes the deadlock in `TestMemorySession#testAcquireCloseRace`. The lock-step spin lock is implemented as with `lock` being an `AtomicInteger`:
> 
>     // Keep the 2 threads operating on the same scope
>     int k = lock.getAndAdd(1) + 1;
>     while (k != i * 2) {
>         Thread.onSpinWait();
>         k = lock.get();
>     }
> 
> Given the initial condition:
> 
>     Thread 1: i = 0
>     Thread 2: i = 0
>     lock: -2
> 
> The `lock` then undergoes the following operations:
> 
> 
> 
>         Thread 1          Thread 2         lock value
>       getAndAdd(1)                            -1
>                         getAndAdd(1)           0 -> Thread 2 then continues its next iteration, its i value is now 1
>                         getAndAdd(1)           1 -> Thread 2 reaches the next iteration before thread 1 has a chance to read the value 0
>           get()                                1 -> Thread 1 now cannot proceed because it missed the value 0
>                            get()               1 -> Thread 2 now cannot proceed because lock can never reach 2
> 
> 
> The solution is to not rely on the exact value of the lock but instead whether the lock has passed the expected value.
> 
> Testing: I have run this test several hundreds times and got no failure while without this patch I encountered a timeout every approximately 30 times.
> 
> Please take a look, thanks a lot.

This pull request has now been integrated.

Changeset: 2614c991
Author:    Quan Anh Mai <qamai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2614c991d8244337dbf6a22bf296cd5eff5a7809
Stats:     24 lines in 1 file changed: 10 ins; 6 del; 8 mod

8343793: Test java/foreign/TestMemorySession.java is timing out

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/21976

From stuefe at openjdk.org  Sat Nov  9 07:24:10 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 9 Nov 2024 07:24:10 GMT
Subject: RFR: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port [v33]
In-Reply-To: <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
 <6_PztFqmtuCsDR3H07Zab7lQU-yMI6fqs064R_BnyIg=.d4660e62-6d17-4c84-b195-76ecc6c1659c@github.com>
Message-ID: <deG-5pSaioxX_iu3HGqZFikAnKlhDF8Mx962lPoKHSM=.1a200b5b-d345-41f9-adfc-9902849b0a63@github.com>

On Fri, 8 Nov 2024 11:31:40 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
>> 
>> This is the summary of JEP 479:
>>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Inline buildJniFunctionName

Still looks good to me.

-------------

Marked as reviewed by stuefe (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21744#pullrequestreview-2425254474

From duke at openjdk.org  Sat Nov  9 13:09:20 2024
From: duke at openjdk.org (jyxzwd)
Date: Sat, 9 Nov 2024 13:09:20 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
Message-ID: <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>

On Sat, 9 Nov 2024 08:57:17 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Use the built-in file system provider rather than the custom file system provider.
>> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.
>
> src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java line 51:
> 
>> 49:     private static final String JAVA_HOME = System.getProperty("java.home");
>> 50:     private static final Path BOOT_MODULES_JIMAGE =
>> 51:             sun.nio.fs.DefaultFileSystemProvider.create().getPath(JAVA_HOME, "lib", "modules");
> 
> This is JDK internal so if the classes in jrt-fs.jar are loaded by a custom class loader, in for example JDK 17 or 21, then this will fail.

I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already included under the java.base module? This would mean that the classes in jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a custom class loader wouldn?t typically need to load them again.
Could you kindly advise if there are any scenarios in JDK 17 or JDK 21 where custom loading of jrt-fs.jar would still be necessary?
Thank you very much for your guidance.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835357748

From alanb at openjdk.org  Sat Nov  9 18:15:12 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 9 Nov 2024 18:15:12 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
Message-ID: <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>

On Sat, 9 Nov 2024 13:06:30 GMT, jyxzwd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/jimage/ImageReaderFactory.java line 51:
>> 
>>> 49:     private static final String JAVA_HOME = System.getProperty("java.home");
>>> 50:     private static final Path BOOT_MODULES_JIMAGE =
>>> 51:             sun.nio.fs.DefaultFileSystemProvider.create().getPath(JAVA_HOME, "lib", "modules");
>> 
>> This is JDK internal so if the classes in jrt-fs.jar are loaded by a custom class loader, in for example JDK 17 or 21, then this will fail.
>
> I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already included under the java.base module? This would mean that the classes in jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a custom class loader wouldn?t typically need to load them again.
> Could you kindly advise if there are any scenarios in JDK 17 or JDK 21 where custom loading of jrt-fs.jar would still be necessary?
> Thank you very much for your guidance.

The jrt file system provider supports both the current JDK and a remote/target JDK. When the JDK is not the current JDK then it loads the jrt file system provider from target's JDK jrt-fs.jar. To understand this more, try this example where you set targetJDK to the file path of another JDK on your system.


String targetJDK = .
var fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", targetJDK));
byte[] classBytes = Files.readAllBytes(fs.getPath("/modules/java.base/java/lang/String.class"));


Run with `-Xlog:class+load` and you'll see jrtfs and support jimage class files loaded from the target JDK. If you dig deeper you'll see they are loaded by a custom class loader, they are defined by the boot loader and aren't in java.base. Hopefully this makes it clear why classes in jdk.internal.jimage or jdk.internal.jrtfs can't reference JDK internal classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835482157

From dl at openjdk.org  Sat Nov  9 21:58:19 2024
From: dl at openjdk.org (Doug Lea)
Date: Sat, 9 Nov 2024 21:58:19 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v19]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <toOPvGznkbQtS1FgaZlnkJZQpgq8zUTmCr_eTSNNydY=.a9f879f5-85db-4ff6-88d8-d03af124de9c@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Add CLEANED runState

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/f657543b..3a88605f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=17-18

  Stats: 149 lines in 1 file changed: 42 ins; 44 del; 63 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From asemenyuk at openjdk.org  Sat Nov  9 23:02:42 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sat, 9 Nov 2024 23:02:42 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
Message-ID: <DaVSilwVpF9N1VVzuhweL2hRytS8Hp-lFBzcgmmEQ34=.093ef353-0b3e-4ce9-8d55-0ee307a85f80@github.com>

On Fri, 31 May 2024 14:05:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
> 
> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
> 
> These loopholes were eliminated:
> 
>  - stdout and stderr of app launchers is never suppressed;
>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
> 
> Other changes are due to changes in HelloApp.AppOutputVerifier class.

The crash is sporadic, hard to reproduce, and happens only on Linux.
Almost every jpackage test runs a launcher, so the alternative to "hiding" the issue was to disable all jpackage tests or make them not run launchers on Linux. There is no good solution except nailing and fixing the root cause.

I agree the fix doesn't match a title. Isn't it too late to rename the title after the fix has been integrated? I can add a comment to JBS explaining that the crash is still there. Would this help?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2147482032
PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2147522342

From stuefe at openjdk.org  Sat Nov  9 23:02:42 2024
From: stuefe at openjdk.org (Thomas Stuefe)
Date: Sat, 9 Nov 2024 23:02:42 GMT
Subject: RFR: 8331977: Crash: SIGSEGV in dlerror()
In-Reply-To: <DaVSilwVpF9N1VVzuhweL2hRytS8Hp-lFBzcgmmEQ34=.093ef353-0b3e-4ce9-8d55-0ee307a85f80@github.com>
References: <ZJ-3CSix-7KDLyG4pkBY38ompRlk8InxhIPsmJy-NGQ=.a6984371-8759-4165-863d-491e10e25cab@github.com>
 <DaVSilwVpF9N1VVzuhweL2hRytS8Hp-lFBzcgmmEQ34=.093ef353-0b3e-4ce9-8d55-0ee307a85f80@github.com>
Message-ID: <8B21PDkz0H1QAImiWd1fxIOwL70aN9NgcBxSk5Xmb78=.531f53c3-7233-48e9-8768-13e7ca4fab63@github.com>

On Tue, 4 Jun 2024 13:02:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fix MainClassTest class to use HelloApp.AppOutputVerifier class to run app launcher instead of raw Executor. This makes MainClassTest test run app launchers with retries. This change addresses the primary issue.
>> 
>> Fix inconsistencies in HelloApp.AppOutputVerifier class. It used to provide API allowing to run launchers without retries. It inconsistently allowed the execution of launchers with suppressed output (stdout and stderr). It inconsistently executed launchers with/without PATH removed from the environment.
>> 
>> These loopholes were eliminated:
>> 
>>  - stdout and stderr of app launchers is never suppressed;
>>  - PATH env variable is always deleted for app launchers on Windows. It is not deleted on other platforms. This change sets the correct scope of [JDK-8254920](https://bugs.openjdk.org/browse/JDK-8254920) fix that introduced the removal of PATH env variable for app launchers;
>>  - app launchers are always executed with retries unless the launcher is executed with `jpackage.test.noexit` system property set to `true` indicating the test app will not terminate on its own.
>> 
>> Other changes are due to changes in HelloApp.AppOutputVerifier class.
>
> The crash is sporadic, hard to reproduce, and happens only on Linux.
> Almost every jpackage test runs a launcher, so the alternative to "hiding" the issue was to disable all jpackage tests or make them not run launchers on Linux. There is no good solution except nailing and fixing the root cause.

@alexeysemenyukoracle Would have been good to rename this JBS issue then to something like "rerun tests in case of crashes", since the issue, from the outside, looks like a fix for the crash itself.

This is mostly to make our lives easier when it comes to backporting (which may happen years from now, when everyone forgot what this was)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19502#issuecomment-2147486733

From duke at openjdk.org  Sat Nov  9 23:03:54 2024
From: duke at openjdk.org (Davide Perini)
Date: Sat, 9 Nov 2024 23:03:54 GMT
Subject: RFR: 8325203: System.exit(0) kills the launched 3rd party
 application
In-Reply-To: <gnLJp1YaaHyWxu_giK77lLLnusmymrqz_IzNzPOjZ10=.c9dacfb9-d4c5-479d-b238-d45f76d86e08@github.com>
References: <wnL_xrUMWYBsWNbrgmRQMIkn-hJqZurm_Nul43t2xSc=.a76d54b7-b2e1-4574-bba9-d808e9b67f1b@github.com>
 <gnLJp1YaaHyWxu_giK77lLLnusmymrqz_IzNzPOjZ10=.c9dacfb9-d4c5-479d-b238-d45f76d86e08@github.com>
Message-ID: <PPlT0sOKNy2i3froqIvBSQBZkLqVUftRGKu8tk9eIBs=.aaad7cd8-aa97-4e1a-a508-c3af641e6426@github.com>

On Thu, 8 Feb 2024 21:03:26 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Tested with the use case from the CR.
>> 
>> The idea of the fix is to prevent grandchildren processes from being automatically attached to the job killing all processes attached to it when the job object is destroyed.
>> 
>> Filed a follow-up https://bugs.openjdk.org/browse/JDK-8325525 CR to track adding a jtreg test for the issue.
>
> @sashamatveev please review

@alexeysemenyukoracle sorry if I quote you.
Do you know how the release cycle works here? 
Will we see this fix in the next JDK21 release?

thanks for your work and for the fix :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/17779#issuecomment-1978380017

From dl at openjdk.org  Sat Nov  9 23:08:30 2024
From: dl at openjdk.org (Doug Lea)
Date: Sat, 9 Nov 2024 23:08:30 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v20]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <bfMDUxUDojHvHQqhUWLi3DOU44knmArfRuN-TtxRoNM=.c4883c8b-5fe7-4c63-bb08-4d0f398c1fad@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 38 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - Add CLEANED runState
 - Merge branch 'openjdk:master' into JDK-8336707
 - More shutdown streamlining
 - Don't report termination while cancellations in progress
 - Reduce read contention
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reduce shutdown overhead and contention
 - dropWaiters now back to releaseAll
 - Merge branch 'openjdk:master' into JDK-8336707
 - ... and 28 more: https://git.openjdk.org/jdk/compare/302782db...96183529

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/3a88605f..96183529

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=18-19

  Stats: 8940 lines in 387 files changed: 6024 ins; 1491 del; 1425 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From duke at openjdk.org  Sun Nov 10 04:54:40 2024
From: duke at openjdk.org (jyxzwd)
Date: Sun, 10 Nov 2024 04:54:40 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
Message-ID: <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>

On Sat, 9 Nov 2024 18:12:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> I was wondering, in JDK 17 or JDK 21, isn't classes in jrt-fs.jar already included under the java.base module? This would mean that the classes in jrt-fs.jar are actually already loaded by the bootstrapClassLoader, so a custom class loader wouldn?t typically need to load them again.
>> Could you kindly advise if there are any scenarios in JDK 17 or JDK 21 where custom loading of jrt-fs.jar would still be necessary?
>> Thank you very much for your guidance.
>
> The jrt file system provider supports both the current JDK and a remote/target JDK. When the JDK is not the current JDK then it loads the jrt file system provider from target's JDK jrt-fs.jar. To understand this more, try this example where you set targetJDK to the file path of another JDK on your system.
> 
> 
> String targetJDK = .
> var fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", targetJDK));
> byte[] classBytes = Files.readAllBytes(fs.getPath("/modules/java.base/java/lang/String.class"));
> 
> 
> Run with `-Xlog:class+load` and you'll see jrtfs and support jimage class files loaded from the target JDK. If you dig deeper you'll see they are loaded by a custom class loader, they are not defined by the boot loader and aren't in java.base. Hopefully this makes it clear why classes in jdk.internal.jimage or jdk.internal.jrtfs can't access JDK internal classes.

I got it.Thank you for the detailed explanation!Maybe we should consider another way to load the custom FileSystemProvider.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835576027

From peter.firmstone at zeus.net.au  Sun Nov 10 07:05:48 2024
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 10 Nov 2024 17:05:48 +1000
Subject: JDK-8019345 & 8294241: Deprecate URL public constructors
Message-ID: <2bab0e68-e928-4d4a-a474-a613d6ac11f7@zeus.net.au>

So we have an RFC3986 compliant URI implementation, that's not 
compatible with Java's RFC2396 URI and now we use deprecated URL public 
constructors...

But I guess they're only deprecated, not going to be removed, we can't 
change our code to use RFC2396 URI without unintended consequences...?? 
Having said that, I would discourage developers from writing any new 
code that uses RFC2396 URI.

My understanding is Java's RFC2396 cannot be changed for backward 
compatibility reasons, it's not strictly compliant with RFC2396 and 
varies from the spec with a larger allowed character set (unescaped)...

Perhaps a new RFC3986 URI implementation could utilise a provider 
mechanism, with some static methods that allow the developer to select 
which RFC compliant URI version they want to use?

We haven't used Java's URI class for a long time, as there are 
significant performance benefits to using RFC3986 et al, such as not 
relying on DNS lookup for identity.

Javadoc from our RFC3986 Uri implementation (AL2.0):

/**
 ?* This class represents an immutable instance of a URI as defined by 
RFC 3986.
 ?* <p>
 ?* This class replaces java.net.URI functionality.
 ?* <p>
 ?* Unlike java.net.URI this class is not Serializable and hashCode and
 ?* equality is governed by strict RFC3986 normalisation. In addition 
"other"
 ?* characters allowed in java.net.URI as specified by javadoc, not 
specifically
 ?* allowed by RFC3986 are illegal and must be escaped.? This strict 
adherence
 ?* is essential to eliminate false negative or positive matches.
 ?* <p>
 ?* In addition to RFC3896 normalisation, on OS platforms with a \ file 
separator
 ?* the path is converted to UPPER CASE for comparison for file: schema, 
during
 ?* equals and hashCode calls.
 ?* <p>
 ?* IPv6 and IPvFuture host addresses must be enclosed in square 
brackets as per
 ?* RFC3986.? A zone delimiter %, if present, must be represented in 
escaped %25
 ?* form as per RFC6874.
 ?* <p>
 ?* In addition to RFC3986 normalization, IPv6 host addresses will be 
normalized
 ?* to comply with RFC 5952 A Recommendation for IPv6 Address Text 
Representation.
 ?* This is to ensure consistent equality between identical IPv6 addresses.
 ?*
 ?* @since 3.0.0
 ?*/
public final class Uri implements Comparable<Uri> {

-- 
Regards,
  
Peter


From peter.firmstone at zeus.net.au  Sun Nov 10 07:26:06 2024
From: peter.firmstone at zeus.net.au (Peter Firmstone)
Date: Sun, 10 Nov 2024 17:26:06 +1000
Subject: JDK-8019345 & 8294241: Deprecate URL public constructors
In-Reply-To: <2bab0e68-e928-4d4a-a474-a613d6ac11f7@zeus.net.au>
References: <2bab0e68-e928-4d4a-a474-a613d6ac11f7@zeus.net.au>
Message-ID: <6913d79d-ddda-435b-9401-df07c2f66d1f@zeus.net.au>

Our code addresses compatibility:

/** Fixes windows file URI string by converting back slashes to forward
 ???? * slashes and inserting a forward slash before the drive letter if 
it is
 ???? * missing.? No normalisation or modification of case is performed.
 ???? * @param uri String representation of URI
 ???? * @return fixed URI String
 ???? */
 ??? public static String fixWindowsURI(String uri) {
 ??????? if (uri == null) return null;
 ??????? if (File.separatorChar != '\\') return uri;
 ??????? if ( uri.startsWith("file:") || uri.startsWith("FILE:")){
 ??????????? char [] u = uri.toCharArray();
 ??????????? int l = u.length;
 ??????????? StringBuilder sb = new StringBuilder(uri.length()+1);
 ??????????? for (int i=0; i<l; i++){
 ??????????????? // Ensure we use forward slashes
 ??????????????? if (u[i] == File.separatorChar) {
 ??????????????????? sb.append('/');
 ??????????????????? continue;
 ??????????????? }
 ??????????????? if (i == 5 && uri.startsWith(":", 6 )) {
 ??????????????????? // Windows drive letter without leading slashes 
doesn't comply
 ??????????????????? // with URI spec, fix it here
 ??????????????????? sb.append("/");
 ??????????????? }
 ??????????????? sb.append(u[i]);
 ??????????? }
 ??????????? return sb.toString();
 ??????? }
 ??????? return uri;
 ??? }


<SNIP>


public static Uri filePathToUri(String path) throws URISyntaxException{
 ??????? String forwardSlash = "/";
 ??????? if (path == null || path.length() == 0) {
 ??????????? // codebase is "file:"
 ??????????? path = "*";
 ??????? }
 ??????? // Ensure compatibility with URLClassLoader, when directory
 ??????? // character is dropped by File.
 ??????? boolean directory = false;
 ??????? if (path.endsWith(forwardSlash)) directory = true;
 ??????? path = new File(path).getAbsolutePath();
 ??????? if (directory) {
 ??????????? if (!(path.endsWith(File.separator))){
 ??????????????? path = path + File.separator;
 ??????????? }
 ??????? }
 ??????? if (File.separatorChar == '\\') {
 ??????????? path = path.replace(File.separatorChar, '/');
 ??????? }
 ??????? path = fixWindowsURI("file:" + path);
 ??????? return Uri.escapeAndCreate(path); //$NON-NLS-1$
 ??? }


-- 
Regards,
  
Peter

On 10/11/2024 5:05 pm, Peter Firmstone wrote:
> So we have an RFC3986 compliant URI implementation, that's not 
> compatible with Java's RFC2396 URI and now we use deprecated URL 
> public constructors...
>
> But I guess they're only deprecated, not going to be removed, we can't 
> change our code to use RFC2396 URI without unintended 
> consequences...?? Having said that, I would discourage developers from 
> writing any new code that uses RFC2396 URI.
>
> My understanding is Java's RFC2396 cannot be changed for backward 
> compatibility reasons, it's not strictly compliant with RFC2396 and 
> varies from the spec with a larger allowed character set (unescaped)...
>
> Perhaps a new RFC3986 URI implementation could utilise a provider 
> mechanism, with some static methods that allow the developer to select 
> which RFC compliant URI version they want to use?
>
> We haven't used Java's URI class for a long time, as there are 
> significant performance benefits to using RFC3986 et al, such as not 
> relying on DNS lookup for identity.
>
> Javadoc from our RFC3986 Uri implementation (AL2.0):
>
> /**
> ?* This class represents an immutable instance of a URI as defined by 
> RFC 3986.
> ?* <p>
> ?* This class replaces java.net.URI functionality.
> ?* <p>
> ?* Unlike java.net.URI this class is not Serializable and hashCode and
> ?* equality is governed by strict RFC3986 normalisation. In addition 
> "other"
> ?* characters allowed in java.net.URI as specified by javadoc, not 
> specifically
> ?* allowed by RFC3986 are illegal and must be escaped.? This strict 
> adherence
> ?* is essential to eliminate false negative or positive matches.
> ?* <p>
> ?* In addition to RFC3896 normalisation, on OS platforms with a \ file 
> separator
> ?* the path is converted to UPPER CASE for comparison for file: 
> schema, during
> ?* equals and hashCode calls.
> ?* <p>
> ?* IPv6 and IPvFuture host addresses must be enclosed in square 
> brackets as per
> ?* RFC3986.? A zone delimiter %, if present, must be represented in 
> escaped %25
> ?* form as per RFC6874.
> ?* <p>
> ?* In addition to RFC3986 normalization, IPv6 host addresses will be 
> normalized
> ?* to comply with RFC 5952 A Recommendation for IPv6 Address Text 
> Representation.
> ?* This is to ensure consistent equality between identical IPv6 
> addresses.
> ?*
> ?* @since 3.0.0
> ?*/
> public final class Uri implements Comparable<Uri> {
>

From jbhateja at openjdk.org  Sun Nov 10 07:43:48 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 10 Nov 2024 07:43:48 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
Message-ID: <IwXC8gTLD1LKFMu6DpulYxgbt5Zp1WTaL6Cc19V2dJw=.80a1e2a3-178b-4f10-9431-ea41e1c3ddd8@github.com>

On Fri, 8 Nov 2024 20:25:23 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

> In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I don't see a compelling reason to do so. IMO matcher functionality is more than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` + `has_int_inputs()` predicate. For `MulUIVL` you additionally do input rewiring (using `forward_masked_input`), but (1) `AndV src (Replicate 0xFFFFFFFF))` operands can be easily detected on matcher side (with an extra AD instruction); and (2) such optimization is limited because it is valid only for `0xFFFFFFFF` case while `has_uint_inputs() == true` for `C <= 0xFFFFFFFF`.
> 
> So, IMO `MulIVL` and `MulUIVL` nodes just add noise in Ideal graph without improving situation during matching.

Hi Vladimir, 
Problem occurs if AndV gets shared, in such case matcher will not be able to absorb the masking pattern.
Specialized IR overrules any such limitations and shields pattern it represents from downstream optimizations.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2466624605

From jbhateja at openjdk.org  Sun Nov 10 07:43:49 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 10 Nov 2024 07:43:49 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <RvkEn6C7t0sGn1e939rf2SU07rxGwBEocMIoxBe_D-Q=.b3439e6e-7a70-49fb-b9c8-28eff1d7fed8@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
 <RvkEn6C7t0sGn1e939rf2SU07rxGwBEocMIoxBe_D-Q=.b3439e6e-7a70-49fb-b9c8-28eff1d7fed8@github.com>
Message-ID: <i8dNiKAZ4RsQAiFxtufWCv_O4vRSE1O-K3Fe14lAbvY=.88de32d8-267d-4079-b2ce-3ba801808ead@github.com>

On Fri, 8 Nov 2024 23:18:18 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> src/hotspot/share/opto/vectornode.cpp line 2132:
>> 
>>> 2130:   // Directly forward masked inputs if
>>> 2131:   if (n->Opcode() == Op_AndV) {
>>> 2132:      return n->in(1)->Opcode() == Op_Replicate ? n->in(2) : n->in(1);
>> 
>> This particular check should ensure that Replicate constant is `0xFFFFFFFF`.
>
> Yes, this should ensure 0xFFFFFFFF.

We land here after checking if inputs are uints.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1835611481

From alan.bateman at oracle.com  Sun Nov 10 07:56:07 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Sun, 10 Nov 2024 07:56:07 +0000
Subject: JDK-8019345 & 8294241: Deprecate URL public constructors
In-Reply-To: <2bab0e68-e928-4d4a-a474-a613d6ac11f7@zeus.net.au>
References: <2bab0e68-e928-4d4a-a474-a613d6ac11f7@zeus.net.au>
Message-ID: <de31cb06-b4f7-430b-a85b-976e6d238f9d@oracle.com>

On 10/11/2024 07:05, Peter Firmstone wrote:
> So we have an RFC3986 compliant URI implementation, that's not 
> compatible with Java's RFC2396 URI and now we use deprecated URL 
> public constructors...
>
> But I guess they're only deprecated, not going to be removed, we can't 
> change our code to use RFC2396 URI without unintended 
> consequences...?? Having said that, I would discourage developers from 
> writing any new code that uses RFC2396 URI.
>
> My understanding is Java's RFC2396 cannot be changed for backward 
> compatibility reasons, it's not strictly compliant with RFC2396 and 
> varies from the spec with a larger allowed character set (unescaped)...
>
> Perhaps a new RFC3986 URI implementation could utilise a provider 
> mechanism, with some static methods that allow the developer to select 
> which RFC compliant URI version they want to use?
>
> We haven't used Java's URI class for a long time, as there are 
> significant performance benefits to using RFC3986 et al, such as not 
> relying on DNS lookup for identity.

It's probably best to bring discussion about RFC 2396 vs. 3986 to 
net-dev as that is where both java.net.URI and legacy java.net.URL are 
maintained. Also make sure to clearly distinguish the two APIs in any 
discussion as it might confuse lurkers to bring up DNS lookup in the 
context of parsing input as a URI. As regards efforts to move to the 
newer RFC then I think you know the previous effort to upgrade to the 
newer RFC had to be backed out (before the release GA) due to 
compatibility issues. There have been efforts since then, including 
prototyping several API directions. I can't tell if you are asking about 
that or specifically the legacy URL constructors that have been 
deprecated for several releases, so maybe make that clearer in your mail 
to net-dev too.

-Alan


From jbhateja at openjdk.org  Sun Nov 10 08:22:12 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Sun, 10 Nov 2024 08:22:12 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v3]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <BXyG2N1JgAdJ5NJQKcRaO6kJkJr3Vm9ccg2WO0t4CiA=.1bc78d8a-e6da-4994-8af5-db1d5061a44c@github.com>

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Jatin Bhateja has updated the pull request incrementally with two additional commits since the last revision:

 - Refining comment
 - Review resolutions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21244/files
  - new: https://git.openjdk.org/jdk/pull/21244/files/613f491b..eba586b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=01-02

  Stats: 17 lines in 2 files changed: 8 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21244/head:pull/21244

PR: https://git.openjdk.org/jdk/pull/21244

From swen at openjdk.org  Sun Nov 10 08:58:18 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Sun, 10 Nov 2024 08:58:18 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
Message-ID: <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>

> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
> 
> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
> 3. Eliminate duplicate code in BigDecimal

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  add benchmark

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21593/files
  - new: https://git.openjdk.org/jdk/pull/21593/files/e97138db..cf947f61

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21593&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21593&range=02-03

  Stats: 50 lines in 1 file changed: 50 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21593.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21593/head:pull/21593

PR: https://git.openjdk.org/jdk/pull/21593

From duke at openjdk.org  Sun Nov 10 14:51:14 2024
From: duke at openjdk.org (jyxzwd)
Date: Sun, 10 Nov 2024 14:51:14 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
 <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
Message-ID: <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>

On Sun, 10 Nov 2024 04:50:36 GMT, jyxzwd <duke at openjdk.org> wrote:

>> The jrt file system provider supports both the current JDK and a remote/target JDK. When the JDK is not the current JDK then it loads the jrt file system provider from target's JDK jrt-fs.jar. To understand this more, try this example where you set targetJDK to the file path of another JDK on your system.
>> 
>> 
>> String targetJDK = .
>> var fs = FileSystems.newFileSystem(URI.create("jrt:/"), Map.of("java.home", targetJDK));
>> byte[] classBytes = Files.readAllBytes(fs.getPath("/modules/java.base/java/lang/String.class"));
>> 
>> 
>> Run with `-Xlog:class+load` and you'll see jrtfs and support jimage class files loaded from the target JDK. If you dig deeper you'll see they are loaded by a custom class loader, they are not defined by the boot loader and aren't in java.base. Hopefully this makes it clear why classes in jdk.internal.jimage or jdk.internal.jrtfs can't access JDK internal classes.
>
> I got it.Thank you for the detailed explanation!Maybe we should consider another way to load the custom FileSystemProvider.

If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we will step into the method SystemModuleFinders$SystemModuleReader#findImageLocation again, and the var imageReader will be null.But we can not define a custom classLoader to load the custom DefaultFileSystemProvider since it needs to maintain JDK 8 source compatibility.So the only way that I can think of is to use the installedProvider which has the 'file' scheme to directly get the 'modules' path value.

In ImageReaderFactory:

private static final Path BOOT_MODULES_JIMAGE = null;

    static {
        // check installed providers
        for (FileSystemProvider provider : FileSystemProvider.installedProviders()) {
            if ("file".equalsIgnoreCase(provider.getScheme())) {
                try {
                    BOOT_MODULES_JIMAGE = provider.getFileSystem(URI.create("file:/")).getPath(JAVA_HOME, "lib", "modules");
                    if (BOOT_MODULES_JIMAGE != null) break;
                } catch (UnsupportedOperationException uoe) {
                }
            }
        }
    }

What do you think of this?I am new to openjdk source development.So I truely appreciate the time you dedecate to my question!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835713466

From liach at openjdk.org  Sun Nov 10 17:06:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Nov 2024 17:06:30 GMT
Subject: RFR: 8343251: Facelift for Type and AnnotatedType specifications
 [v5]
In-Reply-To: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
References: <j-VwsmusjASyyyxrzDKDzaTFADK-fvP7GL0DrrbO-54=.15cc14ef-dca8-4083-9ecf-5b9c3cbf1855@github.com>
Message-ID: <3LLsHC9azQPo4CbObJAMKk18NNSTjwjrObTKBt1UJac=.098b7ad2-0fca-47ea-b268-42a37c34417c@github.com>

> The Type and AnnotatedType hierarchies have been enigmatic to new users: users have no clue how to categorize arbitrary type objects, when it is safe to cast to more specific types, and the exact conditions for method contracts.
> 
> A manifest is [JDK-8306039](https://bugs.openjdk.org/browse/JDK-8306039), where people are massively confused by the conditions for `ParameterizedType::getOwnerType` to return `null`.
> 
> To fix these problems, I consulted the JLS, used some terms from there and added JLS links to make the definitions concise and accurate.
> 
> Here are some actions:
> 1. Add section for hierarchy overview for both Type and AnnotatedType
> 2. Specify the underlying type for different AnnotatedType subinterfaces
> 3. Define "inner member class" for `getOwnerType`, and refer to it in `AnnotatedType::getAnnotatedOwnerType`.
> 4. Improve the specification for `ParameterizedType::getActualTypeArguments` to note the existence of owner types; also for annotated version
> 5. Minor improvements to `ParameterizedType::getRawType`
> 6. Move the equals specification for `ParameterizedType` to the actual `equals` method.
> 
> API diffs: https://cr.openjdk.org/~liach/8343251-apidiff/java.base/java/lang/reflect/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 12 additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Improve getRawType
 - Intro and other various improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Cleanup
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Mass improvements
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - Merge branch 'master' of https://github.com/openjdk/jdk into doc/owner-type
 - ... and 2 more: https://git.openjdk.org/jdk/compare/b1a8df87...35abd93c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19977/files
  - new: https://git.openjdk.org/jdk/pull/19977/files/83feba99..35abd93c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19977&range=03-04

  Stats: 141342 lines in 1043 files changed: 110613 ins; 11443 del; 19286 mod
  Patch: https://git.openjdk.org/jdk/pull/19977.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19977/head:pull/19977

PR: https://git.openjdk.org/jdk/pull/19977

From alanb at openjdk.org  Sun Nov 10 17:07:36 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sun, 10 Nov 2024 17:07:36 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider
In-Reply-To: <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
 <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
 <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>
Message-ID: <zRxBk__5eBUlixtYNb1fZAIZ_UzY31w2ilj0ZkOfcq4=.38c84893-ec1b-45a9-bc55-3b1b4554dc1c@github.com>

On Sun, 10 Nov 2024 14:48:26 GMT, jyxzwd <duke at openjdk.org> wrote:

>> I got it.Thank you for the detailed explanation!Maybe we should consider another way to load the custom FileSystemProvider.
>
> If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we will step into the method SystemModuleFinders$SystemModuleReader#findImageLocation again, and the var imageReader will be null.But we can not define a custom classLoader to load the custom DefaultFileSystemProvider since it needs to maintain JDK 8 source compatibility.So the only way that I can think of is to use the installedProvider which has the 'file' scheme to directly get the 'modules' path value.
> 
> In ImageReaderFactory:
> 
> private static final Path BOOT_MODULES_JIMAGE = null;
> 
>     static {
>         // check installed providers
>         for (FileSystemProvider provider : FileSystemProvider.installedProviders()) {
>             if ("file".equalsIgnoreCase(provider.getScheme())) {
>                 try {
>                     BOOT_MODULES_JIMAGE = provider.getFileSystem(URI.create("file:/")).getPath(JAVA_HOME, "lib", "modules");
>                     if (BOOT_MODULES_JIMAGE != null) break;
>                 } catch (UnsupportedOperationException uoe) {
>                 }
>             }
>         }
>     }
> 
> What do you think of this?I am new to openjdk source development.So I truely appreciate the time you dedecate to my question!

I assume this will lead to recursive initialisation, e.g. `FileSystems.getFileSystem(URI.create("jrt:/"))` will use FileSystemProvider.installedProviders to iterate over the installed providers.

I don't have time to look into this more but I think it will have to reflectively get the FileSystem so that the code isn't compiled with references to the built-in provider, as in something like this (not tested):


    private static final Path BOOT_MODULES_JIMAGE;
    static {
        FileSystem fs;
        if (ImageReaderFactory.class.getClassLoader() == null) {
            // fs = DefaultFileSystemProvider.theFileSystem()
            try {
                fs = (FileSystem) Class.forName("sun.nio.fs.DefaultFileSystemProvider")
                        .getMethod("theFileSystem")
                        .invoke(null);
            } catch (Exception e) {
                throw new ExceptionInInitializerError(e);
            }
        } else {
            fs = FileSystems.getDefault();
        }
        BOOT_MODULES_JIMAGE = fs.getPath(JAVA_HOME, "lib", "modules");
    }

Also just to say that we need to create a good test for this issue. I expect it will be rarely to interpose on the default file system and use jrtfs at the same time, but that is what this bug report is about so we'll need to create a good test.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1835741459

From dl at openjdk.org  Sun Nov 10 17:51:43 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 10 Nov 2024 17:51:43 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v21]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <CZgxCjEdct918hzacDCL9MkR1LfyAo2kj2gPFUdySgs=.7324a202-e7f0-45f0-b0cb-5626e164937a@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - Minor improvements
 - Merge branch 'openjdk:master' into JDK-8336707
 - Add CLEANED runState
 - Merge branch 'openjdk:master' into JDK-8336707
 - More shutdown streamlining
 - Don't report termination while cancellations in progress
 - Reduce read contention
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reduce shutdown overhead and contention
 - ... and 30 more: https://git.openjdk.org/jdk/compare/1b2f97e6...4db28137

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/96183529..4db28137

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=19-20

  Stats: 1270 lines in 10 files changed: 887 ins; 149 del; 234 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From liach at openjdk.org  Sun Nov 10 22:52:08 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Nov 2024 22:52:08 GMT
Subject: RFR: 8343650: Reuse StringLatin1::putCharsAt and
 StringUTF16::putCharsAt
In-Reply-To: <z6Fuk2vuX3I9lkrBuiou_DW41ZDF6YN_puY97ZggS6I=.f281484c-083f-46d7-9a21-583931341156@github.com>
References: <z6Fuk2vuX3I9lkrBuiou_DW41ZDF6YN_puY97ZggS6I=.f281484c-083f-46d7-9a21-583931341156@github.com>
Message-ID: <fQXIrSct0eAyGRAV1XrR4QPAWZPeQOfOP4iz2xSC9O8=.ed718547-da16-4cfd-937b-91df11e2ab55@github.com>

On Tue, 5 Nov 2024 15:29:39 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Reuse the optimized putCharsAt method of StringLatin1 and StringUTF16 in PR #19626 to simplify the code, eliminate boundary checks, and improve performance

Looks good.  Tier 1-3 tests pass.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21907#pullrequestreview-2425878833

From liach at openjdk.org  Sun Nov 10 22:54:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Sun, 10 Nov 2024 22:54:54 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
Message-ID: <PjYinKHarIZV--XwORqu5mSBhSKWy2fHdEyfopHyp58=.779945e7-a37f-406e-bd1c-2c8651bb1bc6@github.com>

On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
>> 
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
>> 3. Eliminate duplicate code in BigDecimal
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

Looks good. Tier 1-3 tests pass.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21593#pullrequestreview-2425879062

From swen at openjdk.org  Mon Nov 11 00:43:04 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 00:43:04 GMT
Subject: Integrated: 8343650: Reuse StringLatin1::putCharsAt and
 StringUTF16::putCharsAt
In-Reply-To: <z6Fuk2vuX3I9lkrBuiou_DW41ZDF6YN_puY97ZggS6I=.f281484c-083f-46d7-9a21-583931341156@github.com>
References: <z6Fuk2vuX3I9lkrBuiou_DW41ZDF6YN_puY97ZggS6I=.f281484c-083f-46d7-9a21-583931341156@github.com>
Message-ID: <evJt7UmivcuCW2uzf6MYATyLgpYaFeV5YkwXk6FujYM=.516a2ae2-433a-403f-9034-fd40a917446f@github.com>

On Tue, 5 Nov 2024 15:29:39 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Reuse the optimized putCharsAt method of StringLatin1 and StringUTF16 in PR #19626 to simplify the code, eliminate boundary checks, and improve performance

This pull request has now been integrated.

Changeset: 74ae3c68
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/74ae3c688b37e693e20eb4e17c631897c5464400
Stats:     36 lines in 1 file changed: 0 ins; 28 del; 8 mod

8343650: Reuse StringLatin1::putCharsAt and StringUTF16::putCharsAt

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21907

From swen at openjdk.org  Mon Nov 11 01:43:25 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 01:43:25 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
Message-ID: <Fa8VEYMS4X6fcYj9rs9E1IAB-p1S2la-2VbI373YdVM=.d7f70dc9-d44b-4ed0-ba3b-6db1ad0b38dd@github.com>

On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
>> 
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
>> 3. Eliminate duplicate code in BigDecimal
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe.

In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, `-COMPACT_STRING` performed better than `+COMPACT_STRING`. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21593#issuecomment-2467068731

From jpai at openjdk.org  Mon Nov 11 04:35:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Nov 2024 04:35:30 GMT
Subject: RFR: 8211033: Clean up the processing -classpath argument not to
 set LM_CLASS
In-Reply-To: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
References: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
Message-ID: <SBPf33D4CwzVZpP0i23DFNOIm_hIpZKLtRzh6lzWOig=.64715125-d45f-414d-8e82-03c9b5cb6e0a@github.com>

On Fri, 8 Nov 2024 08:51:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.org/browse/JDK-8211033?
> 
> As noted in that issue, this is a clean up of the code which determines the "mode" through with the `java` application is being launched. In its current form the presence of `--classpath` (or its equivalent arguments) was unnecessary updating the mode to `LM_CLASS`. The commit in this PR removes that part to allow for the mode to be detected based merely on the presence (or absence) of `-m`, `-jar`, `--source` options. If neither is specified, the file extension is checked to determine the launch mode. 
> 
> Given the nature of this clean up, no new tests have been introduced. Existing tests in tier1, tier2, tier3 continue to pass with this change.

Thank you Alan for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21971#issuecomment-2467211179

From jpai at openjdk.org  Mon Nov 11 04:35:31 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Nov 2024 04:35:31 GMT
Subject: Integrated: 8211033: Clean up the processing -classpath argument not
 to set LM_CLASS
In-Reply-To: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
References: <dNErTlPKku8paZoQ09dJutXyIB3NB4R7k74PqnzpwNs=.5444e445-ec5d-4d54-8085-502930060f94@github.com>
Message-ID: <0Xginb_5GLUyDTj4Ls1DLd9ONEj-iwqw9KnlEHYnjEY=.19c1c6dd-40f4-4927-8370-77aa346fa763@github.com>

On Fri, 8 Nov 2024 08:51:38 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which addresses https://bugs.openjdk.org/browse/JDK-8211033?
> 
> As noted in that issue, this is a clean up of the code which determines the "mode" through with the `java` application is being launched. In its current form the presence of `--classpath` (or its equivalent arguments) was unnecessary updating the mode to `LM_CLASS`. The commit in this PR removes that part to allow for the mode to be detected based merely on the presence (or absence) of `-m`, `-jar`, `--source` options. If neither is specified, the file extension is checked to determine the launch mode. 
> 
> Given the nature of this clean up, no new tests have been introduced. Existing tests in tier1, tier2, tier3 continue to pass with this change.

This pull request has now been integrated.

Changeset: ca69a53b
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ca69a53b76bf0106443985a1207fbd3d9036e1ab
Stats:     8 lines in 1 file changed: 3 ins; 5 del; 0 mod

8211033: Clean up the processing -classpath argument not to set LM_CLASS

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21971

From jpai at openjdk.org  Mon Nov 11 04:44:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Nov 2024 04:44:03 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v5]
In-Reply-To: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
Message-ID: <zPOVItIZlaE1RcV4wl-gfa1ypod8jPwPqXSnf0sqSW8=.d194c773-a14f-4ab0-8a32-e117929eda7d@github.com>

> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
> 
> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
> 
> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - 8341184: Clean up the interaction between the launcher native code and the LauncherHelper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21256/files
  - new: https://git.openjdk.org/jdk/pull/21256/files/45f1b33c..8443861f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=03-04

  Stats: 8525 lines in 319 files changed: 5754 ins; 1341 del; 1430 mod
  Patch: https://git.openjdk.org/jdk/pull/21256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256

PR: https://git.openjdk.org/jdk/pull/21256

From swen at openjdk.org  Mon Nov 11 05:10:53 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 05:10:53 GMT
Subject: Integrated: 8342650: Move getChars to DecimalDigits
In-Reply-To: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
Message-ID: <uqol8bLahIGGhopnIFS3JlDZLJkYP0TdPdY28awSzNk=.d04ac9e0-5bba-40a1-952b-cb3785e329e8@github.com>

On Sun, 20 Oct 2024 00:19:25 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
> 
> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
> 3. Eliminate duplicate code in BigDecimal

This pull request has now been integrated.

Changeset: e1d684c6
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1d684c6451ae7875b61a92603c19336ccd734d6
Stats:     757 lines in 12 files changed: 381 ins; 352 del; 24 mod

8342650: Move getChars to DecimalDigits

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/21593

From jlahoda at openjdk.org  Mon Nov 11 08:13:18 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 11 Nov 2024 08:13:18 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
Message-ID: <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>

> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
> 
> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
> 
> openjdk 24-internal 2025-03-18
> 
> Usage: java [java options...] <application> [application arguments...]
> 
> Where <application> is one of:
>   <mainclass>                to execute the main method of a compiled class
>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>   -m <module>[/<mainclass>]  to execute the main class of a module
>   <sourcefile>.java          to compile and execute a source-file program
> 
> Where key java options include:
>   --class-path <class path>
>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>   --module-path <module path>
>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
> 
> For additional help on usage:           java --help
> For an interactive Java environment:    jshell
> 
> 
> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
> 
> What do you think?
> 
> Thanks!

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:

 - Merge branch 'master' into JDK-8340133-2
 - Using correct pplaceholders.
 - Adjusting text as suggested.
 - Cleaning up the concise message:
   - using 2 spaces instead of 4,
   - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
 - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
 - Using an enum instead of booleans, as suggested.
 - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
 - Adjusting the concise help based on review suggestions.
 - Cleanup.
 - Adjusting/improving the concise help.
 - ... and 1 more: https://git.openjdk.org/jdk/compare/e60df682...b4d7b493

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21411/files
  - new: https://git.openjdk.org/jdk/pull/21411/files/d1d6e4ab..b4d7b493

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=05-06

  Stats: 295479 lines in 3320 files changed: 187870 ins; 78143 del; 29466 mod
  Patch: https://git.openjdk.org/jdk/pull/21411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21411/head:pull/21411

PR: https://git.openjdk.org/jdk/pull/21411

From sgehwolf at openjdk.org  Mon Nov 11 09:42:19 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Nov 2024 09:42:19 GMT
Subject: RFR: 8311302: Implement JEP 493: Linking Run-Time Images without
 JMODs [v48]
In-Reply-To: <mo5Snm_t2jL26zuC8hsdRvcybh4n_1FW1CtuqY3-rhA=.e1648d7b-492b-4d85-9135-627822dd57dc@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
 <mo5Snm_t2jL26zuC8hsdRvcybh4n_1FW1CtuqY3-rhA=.e1648d7b-492b-4d85-9135-627822dd57dc@github.com>
Message-ID: <70bsYiO5m6MtHpts9H0ZO6MlptkIGr7s0OdCriYyTIE=.f44d10b6-4526-4bbf-943b-f1cc0d72956b@github.com>

On Fri, 8 Nov 2024 17:07:55 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app 
 being modularized).
>> 
>> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
>> 
>> Basic usage example:
>> 
>> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
>> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
>> $ ls ../linux-x86_64-server-release/images/jdk/jmods
>> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
>> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
>> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
>> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.i...
>
> Severin Gehwolf has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update copyright headers

Thanks for the reviews! I'll integrate this later today.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/14787#issuecomment-2467671430

From jwaters at openjdk.org  Mon Nov 11 09:51:35 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 11 Nov 2024 09:51:35 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
Message-ID: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did

Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - Merge branch 'openjdk:master' into unused
 - Neater warning silencer in proc_md.h
 - Revert _WIN32 workaround in log_messages.c
 - Copyright in VersionInfo.cpp
 - Remove neutralLangId in VersionInfo.cpp
 - Remove global memHandle, would've liked to keep it as a comment :(
 - Merge branch 'master' into unused
 - 8342682

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21616/files
  - new: https://git.openjdk.org/jdk/pull/21616/files/5e9039fb..53036a65

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21616&range=05-06

  Stats: 200965 lines in 1998 files changed: 125072 ins; 52904 del; 22989 mod
  Patch: https://git.openjdk.org/jdk/pull/21616.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21616/head:pull/21616

PR: https://git.openjdk.org/jdk/pull/21616

From jwaters at openjdk.org  Mon Nov 11 09:51:36 2024
From: jwaters at openjdk.org (Julian Waters)
Date: Mon, 11 Nov 2024 09:51:36 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v2]
In-Reply-To: <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <UJyxhSlSbc6Cq0ZjzaAKZVG8QZKaIjGFcs3IAC8iRCo=.46d87a19-f31f-42ba-91cc-9c88303c85b5@github.com>
 <SggKNDCRHs0irYUWCRal7gya7cZF7C8uXuXrlnwrMQQ=.fa48e548-3c8b-46bc-8dd8-1895d4fec107@github.com>
 <r54jnGo7jwe1fTmcza3ZTnn68s5GcKaTOf56YFO-CZ4=.03ca37d7-0807-47d8-8b77-02b2ee470401@github.com>
 <_mjHLyRHeKOTjl34O-G9Ro3nqlzpyCwjGB3e4c349v8=.324046de-1a06-430f-9ed6-a8862b1a8bf1@github.com>
Message-ID: <oAepUToaFv4pD2DVTKLDKNOxbo9z9HJoqkbBSU7yCn0=.e3947f34-2703-4a8e-afbf-37417ab4dc09@github.com>

On Thu, 31 Oct 2024 19:07:42 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>>> I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem
>> 
>> I'll also start looking into this in the meantime, unless you explicitly want me not to do so
>
>> > I do wonder if mutex support can be implemented for Windows with Acquire/ReleaseSRWLockExclusive. I know it's not strictly needed, but it would be nice to have. Shame threads.h is not available with some Visual Studio versions we support, or at all with gcc. mtx_lock/unlock would be a nice solution to this problem
>> 
>> I'll also start looking into this in the meantime, unless you explicitly want me not to do so
> 
> Feel free to if you'd like to. Personally I don't consider it to be that important.

Bumping, @plummercj I found that casting to void in MUTEX_LOCK and MUTEX_UNLOCK also works, and it seems neater to me. Is this ok with you?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21616#issuecomment-2467690492

From sgehwolf at openjdk.org  Mon Nov 11 10:09:33 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Nov 2024 10:09:33 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <XgUP3oTSxxBjeS0CJNMhixZP45NYBdsAOepkDuQvhz8=.66911e34-2b98-4e04-a0bc-f4b9ffed6c4b@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <XgUP3oTSxxBjeS0CJNMhixZP45NYBdsAOepkDuQvhz8=.66911e34-2b98-4e04-a0bc-f4b9ffed6c4b@github.com>
Message-ID: <f-tvktrcHPdR9Tp1zRrI7rU7VPuQoaZrYKkZKZp0FD0=.185be49b-bba4-40ea-96c3-2cdad18fc06a@github.com>

On Fri, 8 Nov 2024 16:11:37 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.

The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2467736667

From sgehwolf at openjdk.org  Mon Nov 11 10:26:49 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Nov 2024 10:26:49 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <fAhfiQBSc7J2VaTEK1tu8_Il0EOCaxp9-fCV_36f9Co=.6dcb0be9-55d6-4520-b8aa-40b768591a99@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <fAhfiQBSc7J2VaTEK1tu8_Il0EOCaxp9-fCV_36f9Co=.6dcb0be9-55d6-4520-b8aa-40b768591a99@github.com>
Message-ID: <JA5e0849G0dyo3VHxy3PJv8gP24EhBf7TQFXLPS3X6I=.22497b11-a860-4719-97c6-7908ac2f194e@github.com>

On Thu, 7 Nov 2024 13:28:29 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> Create a new cgroup for memory
> 
> ```
> sudo mkdir -p /sys/fs/cgroup/memory/test
> ```
> 
> Run the following script
> 
> ```
> docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --memory 400m ubuntu:latest \
>     sh -c "sleep 10 ; /jdk/bin/java -Xlog:os+container=trace -version" | grep Memory\ Limit &
> sleep 10
> HOSTPID=$(sudo ps -ef | awk '/container=trace/ && !/docker/ && !/awk/ { print $2 }')
> echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs
> sleep 10
> ```
> 
> In the above script, a containerized process (`/bin/sh`) is moved to cgroup `/test` before `/jdk/bin/java` gets executed. Java inherits cgroup `/test` from its parent process, its `_root` will be `/docker/<CONTAINER_ID>`, `cgroup_path` will be `/test`.

OK, but why is https://bugs.openjdk.org/browse/JDK-8322420 not in effect in such a case?
 
> The result would be ($JAVA_HOME points to JDK before fix)
> 
> ```
> 9804
> [0.001s][trace][os,container] Memory Limit failed: -2
> [0.001s][trace][os,container] Memory Limit failed: -2
> [0.002s][trace][os,container] Memory Limit failed: -2
> [0.043s][trace][os,container] Memory Limit failed: -2
> ```
> 
> JDK updated version:
> 
> ```
> 10001
> [0.001s][trace  ][os,container] Memory Limit is: 419430400
> [0.001s][trace  ][os,container] Memory Limit is: 419430400
> [0.002s][trace  ][os,container] Memory Limit is: 419430400
> [0.035s][trace  ][os,container] Memory Limit is: 419430400
> ```

It would be good to see the full boot JVM output at the trace level. I'm wondering why the adjustment isn't sufficient for the use-case the bug describes. I.e. if the move happens *before* the JVM starts then there is a chance it works OK by detecting some limit. If not it would really be useful to understand it better.

If, however, the cgroup move happens after the JVM has started, there is nothing in the JVM which "corrects" the detected physical memory (i.e. heap size et. al) and/or detected CPUs. It's not supported to do that dynamically.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2467779326

From sgehwolf at openjdk.org  Mon Nov 11 10:26:49 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Nov 2024 10:26:49 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <f-tvktrcHPdR9Tp1zRrI7rU7VPuQoaZrYKkZKZp0FD0=.185be49b-bba4-40ea-96c3-2cdad18fc06a@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <XgUP3oTSxxBjeS0CJNMhixZP45NYBdsAOepkDuQvhz8=.66911e34-2b98-4e04-a0bc-f4b9ffed6c4b@github.com>
 <f-tvktrcHPdR9Tp1zRrI7rU7VPuQoaZrYKkZKZp0FD0=.185be49b-bba4-40ea-96c3-2cdad18fc06a@github.com>
Message-ID: <SEqkoSF-Pa3JKDay_7yFrwxbQ_v51Cdn964bvVrGpfY=.e76dc454-0226-4917-9e71-1b8d01b92a8a@github.com>

On Mon, 11 Nov 2024 10:06:11 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > I didn't check cg v2 because the issue (NPE) was observed in v1 hosts only.
> 
> The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue.

I also wonder, then, if the issue is NPE if [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) would fix that issue. The controller adjustment doesn't yet happen on the Java (Metrics) level. Only hotspot so far.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2467787891

From jpai at openjdk.org  Mon Nov 11 10:33:34 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Nov 2024 10:33:34 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
Message-ID: <GsopVlCBhEDvmVOI4jla0DOiQL7dwxAGP6bbD3qYKA0=.75277f74-313b-4147-a413-cab2df10f5b4@github.com>

On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8340133-2
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.
>  - Cleaning up the concise message:
>    - using 2 spaces instead of 4,
>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>  - Using an enum instead of booleans, as suggested.
>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>  - Adjusting the concise help based on review suggestions.
>  - Cleanup.
>  - Adjusting/improving the concise help.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/d5806885...b4d7b493

Thank you Jan, this looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2426819039

From jvernee at openjdk.org  Mon Nov 11 10:45:10 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 11 Nov 2024 10:45:10 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v2]
In-Reply-To: <t_kN9keWunZ0GSPIayskKgmZXIKh5mVFX2BglAv6wkI=.ab9752b3-0c00-4ed6-b31a-e6bf430adf3b@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <t_kN9keWunZ0GSPIayskKgmZXIKh5mVFX2BglAv6wkI=.ab9752b3-0c00-4ed6-b31a-e6bf430adf3b@github.com>
Message-ID: <b8E5eLgYHvsAKCV6mHc5Eg1PrzUPmhAIPZPu1H6wfFc=.aa73a5fe-6b78-4255-afa3-8e5c5d01c003@github.com>

On Tue, 5 Nov 2024 19:21:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
>> 
>> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
>> 
>> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test to ensure serializable lambda creation and basic execution in hidden classes

src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 210:

> 208:  * referenced method; no desugaring is needed.)
> 209:  *
> 210:  * <p>Uses besides evaluation of lambda expressions and method references are

I think this paragraph should go at the end (just before the `@since` tag), so it doesn't interrupt the explanation.

src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 212:

> 210:  * <p>Uses besides evaluation of lambda expressions and method references are
> 211:  * unintended.  These linkage methods may change their unspecified behaviors at
> 212:  * any time to better suit the Java language features, which may impact

Suggestion:

 * any time to better suit the Java language features they were designed to support, which may impact

src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 221:

> 219:  * where the caller is {@linkplain MethodHandles.Lookup#defineHiddenClass not
> 220:  * strongly reachable} from its defining class loader, and such use cases may
> 221:  * lead to resource leaks.

Not sure about having an example here, I think something more punchy is needed. IMO we should just specify the behavior, not motivate the design decisions (which are irrelevant to most users).

Maybe a simple warning such as: 'Unintended uses of these linkage methods may lead to resource leaks, or other unspecified negative effects.' would be enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1836411298
PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1836403675
PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1836396166

From ihse at openjdk.org  Mon Nov 11 10:55:20 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 11 Nov 2024 10:55:20 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
Message-ID: <FiZKWCd-Cjj2pHITrM4w8MSlNn-baG5xWcdlOPb09Q8=.71349a52-2032-46d9-abf8-aed4a3ad90d9@github.com>

On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8340133-2
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.
>  - Cleaning up the concise message:
>    - using 2 spaces instead of 4,
>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>  - Using an enum instead of booleans, as suggested.
>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>  - Adjusting the concise help based on review suggestions.
>  - Cleanup.
>  - Adjusting/improving the concise help.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/99abd24b...b4d7b493

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2426961678

From swen at openjdk.org  Mon Nov 11 11:44:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 11:44:09 GMT
Subject: RFR: 8315585: Optimization for decimal to string
Message-ID: <B7zN7JVEVKp8-kQwY_0N0lWCnMRFyJRA0xf3PJaGBpw=.1804b91a-8c70-44a3-9b7e-6855e54968d0@github.com>

Continue to complete PR #16006 to improve performance and reduce duplicate code

-------------

Commit messages:
 - optimize BigDecimal toString/toPlainString
 - add benchmark

Changes: https://git.openjdk.org/jdk/pull/22009/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22009&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8315585
  Stats: 391 lines in 3 files changed: 188 ins; 121 del; 82 mod
  Patch: https://git.openjdk.org/jdk/pull/22009.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22009/head:pull/22009

PR: https://git.openjdk.org/jdk/pull/22009

From mcimadamore at openjdk.org  Mon Nov 11 11:48:14 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Nov 2024 11:48:14 GMT
Subject: RFR: 8343771: Some FFM benchmarks are broken
In-Reply-To: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
References: <qDwIDGy0Kp1Cmlgw5aXF_PO-NFfaY7GsO7LQnmP0p8A=.841565a6-c937-4fbb-8256-99cf32f72eff@github.com>
Message-ID: <J5Fm-Gw6xPMoLsgHyh7dKAnqBftftpOkWcvF1pa_DQg=.271390ea-45b4-4b1d-9709-a2fadaf87bb1@github.com>

On Thu, 7 Nov 2024 19:09:46 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR fixes some regressions in the FFM benchmarks introduced by https://bugs.openjdk.org/browse/JDK-8332744.

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21963#issuecomment-2467974348

From swen at openjdk.org  Mon Nov 11 11:48:39 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 11:48:39 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <nMwt4NmpoiDF_klnQ099aJNdpPTBv8nFME-HRa6_MHU=.a40e0f1a-f5d3-40b9-b8f0-17317904a94a@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <nMwt4NmpoiDF_klnQ099aJNdpPTBv8nFME-HRa6_MHU=.a40e0f1a-f5d3-40b9-b8f0-17317904a94a@github.com>
Message-ID: <KDvL7wd1ENvAoHn9wG9YUIBDEivbj_B9aBdT1y6Pde4=.6d67bd1c-b92f-4f3f-9e35-df43d69b086a@github.com>

On Sun, 20 Oct 2024 17:33:09 GMT, j3graham <duke at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   add benchmark
>
> src/java.base/share/classes/java/math/BigDecimal.java line 4216:
> 
>> 4214:         // Get the significand as an absolute value
>> 4215:         if (intCompact != INFLATED) {
>> 4216:             coeff = new char[19];
> 
> A possibility here would be to change `coeff` to be a String. The ?else? branch already creates a string and has to additionally create a char array from it. If this is the only place where the `DecimalDigits.getChars(? char[])` is used, some extra code duplication could be removed.

@j3graham I have submitted PR #22009

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21593#discussion_r1836545951

From thartmann at openjdk.org  Mon Nov 11 12:09:37 2024
From: thartmann at openjdk.org (Tobias Hartmann)
Date: Mon, 11 Nov 2024 12:09:37 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
Message-ID: <5VWKbgGAnyDCnJ0Qw5z7CYsE25vb2LAkkS6hhvrdBNg=.59ad5493-5b00-45a9-8527-281c6d56ebf2@github.com>

On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
>> 
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
>> 3. Eliminate duplicate code in BigDecimal
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

This caused a regression, see [JDK-8343925](https://bugs.openjdk.org/browse/JDK-8343925). You might want to consider a quick [backout](https://openjdk.org/guide/#backing-out-a-change).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21593#issuecomment-2468016407

From alanb at openjdk.org  Mon Nov 11 12:16:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Nov 2024 12:16:13 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
Message-ID: <Ia63YWh-a0lEitOFghVnlfZ-n2wn3oMnKkC06uUtWhY=.170c6abe-b5c2-46f3-bf25-6221cb759e34@github.com>

On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
>> 
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
>> 3. Eliminate duplicate code in BigDecimal
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

I see Shaojin has created an issue to exclude the test but I think better to back this out quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21593#issuecomment-2468030968

From liach at openjdk.org  Mon Nov 11 12:33:30 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Nov 2024 12:33:30 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
Message-ID: <30h5JiZn0Lja1WJAV-n8eFGK7JbaOG6h7oWqLZC9NKo=.ffd90679-c504-41bf-a370-630c884f3f83@github.com>

On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
>> 
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
>> 3. Eliminate duplicate code in BigDecimal
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

I think the fix is easy: Unsafe calls are using a bad offset which should be cast to long.  Will submit a PR, but since I cannot reproduce the original issue locally or on internal CI, need others review first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21593#issuecomment-2468066742

From swen at openjdk.org  Mon Nov 11 12:42:24 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 12:42:24 GMT
Subject: RFR: 8343925: Test HugeToString.java crashes at
 java.util.BitSet.toString()Ljava/lang/String
Message-ID: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>

8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash, so submit this PR to roll back

-------------

Commit messages:
 - Revert "8342650: Move getChars to DecimalDigits"

Changes: https://git.openjdk.org/jdk/pull/22012/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22012&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343925
  Stats: 757 lines in 12 files changed: 352 ins; 381 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/22012.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22012/head:pull/22012

PR: https://git.openjdk.org/jdk/pull/22012

From swen at openjdk.org  Mon Nov 11 12:45:15 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 12:45:15 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits [v4]
In-Reply-To: <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
References: <nIPOiiYTiiw3KC_XFBnNYerNjukWw3UZcXdWC318taA=.4d6ec74c-f8f9-40c9-a22a-477bc578666e@github.com>
 <Im38iTUbZ_7jGJjf6_YEtzIJfJ3IzPfWuh6L5lArJWs=.3a8eede3-013d-45e3-976a-05b7d4214982@github.com>
Message-ID: <7WVa6z_bItCzV6CtEsUfEwAkt9KkskapgBi_wmrMfv4=.3292f929-eda9-444a-8fce-22101aa701b0@github.com>

On Sun, 10 Nov 2024 08:58:18 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
>> 
>> 1. HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
>> 2. Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
>> 3. Eliminate duplicate code in BigDecimal
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   add benchmark

I submitted a rollback PR #22012. I can't reproduce the problem on a MacBook M1 Max, but I agree that more testing is needed, so let's roll it back first.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21593#issuecomment-2468089941

From sgehwolf at openjdk.org  Mon Nov 11 13:38:16 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Nov 2024 13:38:16 GMT
Subject: Integrated: 8311302: Implement JEP 493: Linking Run-Time Images
 without JMODs
In-Reply-To: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
References: <Z0DJ87uKPbjS6mvJIE_oG5m-RWsbERXsytSgV8Bmhdo=.f8723513-0ac6-4e85-9131-3c3924860c61@github.com>
Message-ID: <AtYjz1SdRxhsvfwkXgkp5C5AmkGLrxMn-u0sryxjkiw=.d6502e39-ea95-4cab-8a84-d8e3c810fb13@github.com>

On Thu, 6 Jul 2023 17:34:10 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this patch which adds a jlink mode to the JDK which doesn't need the packaged modules being present. A.k.a run-time image based jlink. Fundamentally this patch adds an option to use `jlink` even though your JDK install might not come with the packaged modules (directory `jmods`). This is particularly useful to further reduce the size of a jlinked runtime. After the removal of the concept of a JRE, a common distribution mechanism is still the full JDK with all modules and packaged modules. However, packaged modules can incur an additional size tax. For example in a container scenario it could be useful to have a base JDK container including all modules, but without also delivering the packaged modules. This comes at a size advantage of `~25%`. Such a base JDK container could then be used to `jlink` application specific runtimes, further reducing the size of the application runtime image (App + JDK runtime; as a single image *or* separate bundles, depending on the app b
 eing modularized).
> 
> The basic design of this approach is to add a jlink plugin for tracking non-class and non-resource files of a JDK install. I.e. files which aren't present in the jimage (`lib/modules`). This enables producing a `JRTArchive` class which has all the info of what constitutes the final jlinked runtime.
> 
> Basic usage example:
> 
> $ diff -u <(./bin/java --list-modules --limit-modules java.se) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules java.se)
> $ diff -u <(./bin/java --list-modules --limit-modules jdk.jlink) <(../linux-x86_64-server-release/images/jdk/bin/java --list-modules --limit-modules jdk.jlink)
> $ ls ../linux-x86_64-server-release/images/jdk/jmods
> java.base.jmod            java.net.http.jmod       java.sql.rowset.jmod      jdk.crypto.ec.jmod         jdk.internal.opt.jmod                     jdk.jdi.jmod         jdk.management.agent.jmod  jdk.security.auth.jmod
> java.compiler.jmod        java.prefs.jmod          java.transaction.xa.jmod  jdk.dynalink.jmod          jdk.internal.vm.ci.jmod                   jdk.jdwp.agent.jmod  jdk.management.jfr.jmod    jdk.security.jgss.jmod
> java.datatransfer.jmod    java.rmi.jmod            java.xml.crypto.jmod      jdk.editpad.jmod           jdk.internal.vm.compiler.jmod             jdk.jfr.jmod         jdk.management.jmod        jdk.unsupported.desktop.jmod
> java.desktop.jmod         java.scripting.jmod      java.xml.jmod             jdk.hotspot.agent.jmod     jdk.internal.vm.compiler.manage...

This pull request has now been integrated.

Changeset: 2ec35808
Author:    Severin Gehwolf <sgehwolf at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2ec358082f0896480bdbfcb289b4ba2bff0dd828
Stats:     4315 lines in 47 files changed: 4065 ins; 146 del; 104 mod

8311302: Implement JEP 493: Linking Run-Time Images without JMODs

Co-authored-by: Mandy Chung <mchung at openjdk.org>
Reviewed-by: mchung, alanb, erikj, ihse

-------------

PR: https://git.openjdk.org/jdk/pull/14787

From davidalayachew at gmail.com  Mon Nov 11 13:46:20 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 11 Nov 2024 08:46:20 -0500
Subject: Question about Streams, Gatherers, and fetching too many elements
Message-ID: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>

Hello Core Libs Dev Team,

I was trying out Gatherers for a project at work, and ran into a rather sad
scenario.

I need to process a large file in batches. Each batch is small enough that
I can hold it in memory, but I cannot hold the entire file (and thus, all
of the batches) in memory at once.

Looking at the Gatherers API, I saw windowFixed and thought that it would
be a great match for my use case.

However, when trying it out, I was disappointed to see that it ran out of
memory very quickly. Here is my attempt at using it.

stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.forEach(eachList -> println(eachList.getFirst()))
;

As you can see, I am just splitting the file into batches, and printing out
the first of each batch. This is purely for example's sake, of course. I
had planned on building even more functionality on top of this, but I
couldn't even get past this example.

But anyways, not even a single one of them printed out. Which leads me to
believe that it's pulling all of them in the Gatherer.

I can get it to run successfully if I go sequentially, but not parallel.
Parallel gives me that out of memory error.

Is there any way for me to be able to have the Gatherer NOT pull in
everything while still remaining parallel and unordered?

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241111/4987d5c1/attachment.htm>

From swen at openjdk.org  Mon Nov 11 13:47:13 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 13:47:13 GMT
Subject: RFR: 8343925: [BACKOUT] JDK-8342650 Move getChars to DecimalDigits
In-Reply-To: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
References: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
Message-ID: <cgttipFhQtSzQI5bdeiNXNmrkm0XThnCC3lTysLTq54=.128e4e44-4c0a-4b41-8ed8-b35df16da957@github.com>

On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash, 
> 
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more testing is needed, so let's roll it back first.

It has been verified that it is caused by unsafe offset overflow. The problem has been reproduced and fixed. I submitted PR #22014. Would you consider fixing it this way?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22012#issuecomment-2468215673

From pminborg at openjdk.org  Mon Nov 11 13:47:17 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Nov 2024 13:47:17 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying sizes
Message-ID: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>

This PR proposes to add a new `MemorySegment::fill" benchmark where the byte size of the segments varies.

-------------

Commit messages:
 - Use static arrays
 - Revert changes from other branch
 - Add benchmark
 - Add benchmarks

Changes: https://git.openjdk.org/jdk/pull/22010/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22010&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343933
  Stats: 150 lines in 1 file changed: 150 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22010/head:pull/22010

PR: https://git.openjdk.org/jdk/pull/22010

From davidalayachew at gmail.com  Mon Nov 11 13:52:59 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 11 Nov 2024 08:52:59 -0500
Subject: Question about Streams, Gatherers, and fetching too many elements
In-Reply-To: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
Message-ID: <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>

And just to avoid the obvious question, I can hold about 30 batches in
memory before the Out of Memory error occurs. So this is not an issue of my
batch size being too high.

But just to confirm, I set the batch size to 1, and it still ran into an
out of memory error. So I feel fairly confident saying that the Gatherer is
trying to grab all available data before sending any of it downstream.

On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
wrote:

> Hello Core Libs Dev Team,
>
> I was trying out Gatherers for a project at work, and ran into a rather
> sad scenario.
>
> I need to process a large file in batches. Each batch is small enough that
> I can hold it in memory, but I cannot hold the entire file (and thus, all
> of the batches) in memory at once.
>
> Looking at the Gatherers API, I saw windowFixed and thought that it would
> be a great match for my use case.
>
> However, when trying it out, I was disappointed to see that it ran out of
> memory very quickly. Here is my attempt at using it.
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .forEach(eachList -> println(eachList.getFirst()))
> ;
>
> As you can see, I am just splitting the file into batches, and printing
> out the first of each batch. This is purely for example's sake, of course.
> I had planned on building even more functionality on top of this, but I
> couldn't even get past this example.
>
> But anyways, not even a single one of them printed out. Which leads me to
> believe that it's pulling all of them in the Gatherer.
>
> I can get it to run successfully if I go sequentially, but not parallel.
> Parallel gives me that out of memory error.
>
> Is there any way for me to be able to have the Gatherer NOT pull in
> everything while still remaining parallel and unordered?
>
> Thank you for your time and help.
> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241111/34389450/attachment.htm>

From alanb at openjdk.org  Mon Nov 11 13:55:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Nov 2024 13:55:11 GMT
Subject: RFR: 8343925: [BACKOUT] JDK-8342650 Move getChars to DecimalDigits
In-Reply-To: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
References: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
Message-ID: <bu8XuiaVzMlTsPF7U_y0WYtVx6RUUR1FsM-1zOM81OI=.697ef960-6699-4e64-b94a-87ad255a7762@github.com>

On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash, 
> 
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more testing is needed, so let's roll it back first.

Changes in this area need to be very carefully reviewed and tested. I think continue with the current plan to blackout the original change and seeing wider review and testing for the REDO.

Chen is testing the blackout now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22012#issuecomment-2468230634

From duke at openjdk.org  Mon Nov 11 14:03:54 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 11 Nov 2024 14:03:54 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes
In-Reply-To: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
Message-ID: <W7euqwoe20eli8vDQajFmYSC_fh6iJdNn643TsVPMYQ=.e892d5ff-d1e2-4749-ae33-41aa8191d0c1@github.com>

On Mon, 11 Nov 2024 11:55:27 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte size of the segments varies.

Thanks @minborg for this :) Please remember to add the misprediction count if you can - or just avoid the bulk methods instead i.e. having a `nextMemorySegment()` benchmark method which make the fill to observe the different segments.

Having separate call-sites which observe always the same type(s) "could" be too lucky (and gentle) for the runtime (and its CHA)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2468247252

From rgiulietti at openjdk.org  Mon Nov 11 14:07:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 11 Nov 2024 14:07:31 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
Message-ID: <os_i2UbFm71sKzSWTx0Wop4j6YxKKa5SSQonlMfUP1Q=.d56186af-9c2b-4db7-89ec-aee03158f79f@github.com>

On Wed, 30 Oct 2024 05:25:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 431:

> 429:      * @see    java.lang.Float#valueOf(String)
> 430:      */
> 431:     public static Float16 valueOf(String s) throws NumberFormatException {

The current implementation throws when the input is `"NaN"`, with or without an optional sign.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1836721773

From jpai at openjdk.org  Mon Nov 11 14:10:05 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 11 Nov 2024 14:10:05 GMT
Subject: RFR: 8343925: [BACKOUT] JDK-8342650 Move getChars to DecimalDigits
In-Reply-To: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
References: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
Message-ID: <NY-ADZz0L3EPACho8mW3ZFf1KYd1J86JWhVRjtlAgLU=.1d0e53e0-d573-4b60-bc0c-01b09b5ad861@github.com>

On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash, 
> 
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more testing is needed, so let's roll it back first.

I have verified that this backout matches a `git revert` of the commit that introduced the change in https://bugs.openjdk.org/browse/JDK-8342650. So on that front, this backout looks OK to me.
Alan has noted that Chen is running some tests with this backout. So please wait for that review, before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22012#pullrequestreview-2427380530

From alanb at openjdk.org  Mon Nov 11 14:19:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Nov 2024 14:19:17 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
Message-ID: <vuzTesVqSBmTN3Vlx4fwBFLrCsVUd3CXESzvJ70T3QA=.8609d69e-70fa-4ab7-8bba-446f1615f7e3@github.com>

On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8340133-2
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.
>  - Cleaning up the concise message:
>    - using 2 spaces instead of 4,
>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>  - Using an enum instead of booleans, as suggested.
>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>  - Adjusting the concise help based on review suggestions.
>  - Cleanup.
>  - Adjusting/improving the concise help.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/414bcbf6...b4d7b493

src/java.base/share/classes/sun/launcher/LauncherHelper.java line 598:

> 596:     static void printConciseUsageMessage(boolean printToStderr) {
> 597:         initOutput(printToStderr);
> 598:         ostream.println(SharedSecrets.getJavaLangAccess().shortVersionString());

What is the reason for printing the short version string at the start of the short usage message?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1836738224

From alanb at openjdk.org  Mon Nov 11 14:29:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Nov 2024 14:29:59 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <vuzTesVqSBmTN3Vlx4fwBFLrCsVUd3CXESzvJ70T3QA=.8609d69e-70fa-4ab7-8bba-446f1615f7e3@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <vuzTesVqSBmTN3Vlx4fwBFLrCsVUd3CXESzvJ70T3QA=.8609d69e-70fa-4ab7-8bba-446f1615f7e3@github.com>
Message-ID: <_wL5ioaJSVkua-Tt7hgek_mgkW3ZQYYqITkCLJunUaM=.9ebf630c-6d5b-408f-9c9c-7cb22fff1818@github.com>

On Mon, 11 Nov 2024 14:16:25 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8340133-2
>>  - Using correct pplaceholders.
>>  - Adjusting text as suggested.
>>  - Cleaning up the concise message:
>>    - using 2 spaces instead of 4,
>>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>>  - Using an enum instead of booleans, as suggested.
>>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>>  - Adjusting the concise help based on review suggestions.
>>  - Cleanup.
>>  - Adjusting/improving the concise help.
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/7f4880aa...b4d7b493
>
> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 598:
> 
>> 596:     static void printConciseUsageMessage(boolean printToStderr) {
>> 597:         initOutput(printToStderr);
>> 598:         ostream.println(SharedSecrets.getJavaLangAccess().shortVersionString());
> 
> What is the reason for printing the short version string at the start of the short usage message?

In passing, it may be better to pick "short" or "concise", right now it's a mix in the method and resource keys.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1836751174

From alanb at openjdk.org  Mon Nov 11 14:30:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Nov 2024 14:30:00 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
Message-ID: <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>

On Mon, 11 Nov 2024 08:13:18 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8340133-2
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.
>  - Cleaning up the concise message:
>    - using 2 spaces instead of 4,
>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>  - Using an enum instead of booleans, as suggested.
>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>  - Adjusting the concise help based on review suggestions.
>  - Cleanup.
>  - Adjusting/improving the concise help.
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/7f4880aa...b4d7b493

src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:

> 239: \  -jar <jarfile>.jar         to execute the main class of a JAR archive\n\
> 240: \  -m <module>[/<mainclass>]  to execute the main class of a module\n\
> 241: \  <sourcefile>.java          to compile and execute a source-file program\n\n\

I'm not sure about the description of <mainclass>. It uses "compiled class", maybe you means "compiled main class" or something else to connect it <mainclass>?

"-jar <jarfile>.jar" may be confusing because the "java -help" uses "-java <jarfile">". I think the usages need to be the same.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1836748117

From alanb at openjdk.org  Mon Nov 11 14:34:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 11 Nov 2024 14:34:26 GMT
Subject: RFR: 8343925: [BACKOUT] JDK-8342650 Move getChars to DecimalDigits
In-Reply-To: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
References: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
Message-ID: <MuHBKrbd_ri1PKpsKZWDbXEJR-7dnE60ecz36M1rJhA=.e0e3a10b-93bc-47d7-8afa-51f6b1c1d450@github.com>

On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash, 
> 
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more testing is needed, so let's roll it back first.

Thanks for the BACKOUT, looks right.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22012#pullrequestreview-2427435024

From pminborg at openjdk.org  Mon Nov 11 14:50:57 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Nov 2024 14:50:57 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes [v2]
In-Reply-To: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
Message-ID: <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>

> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte size of the segments varies.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Add mixed test
 - Merge branch 'master' into ms-fill-bench-sizes
 - Use static arrays
 - Revert changes from other branch
 - Add benchmark
 - Add benchmarks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22010/files
  - new: https://git.openjdk.org/jdk/pull/22010/files/8760cc87..7734ee3b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22010&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22010&range=00-01

  Stats: 12724 lines in 321 files changed: 9622 ins; 1868 del; 1234 mod
  Patch: https://git.openjdk.org/jdk/pull/22010.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22010/head:pull/22010

PR: https://git.openjdk.org/jdk/pull/22010

From pminborg at openjdk.org  Mon Nov 11 14:54:54 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 11 Nov 2024 14:54:54 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes
In-Reply-To: <W7euqwoe20eli8vDQajFmYSC_fh6iJdNn643TsVPMYQ=.e892d5ff-d1e2-4749-ae33-41aa8191d0c1@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <W7euqwoe20eli8vDQajFmYSC_fh6iJdNn643TsVPMYQ=.e892d5ff-d1e2-4749-ae33-41aa8191d0c1@github.com>
Message-ID: <dTZCfuCQ_r9UKBOZ7Vk-43OyCSxV2_OdSzdVWreD-ok=.2219f126-4941-4ae9-b438-a56bd886cf00@github.com>

On Mon, 11 Nov 2024 13:59:38 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> Thanks @minborg for this :) Please remember to add the misprediction count if you can and avoid the bulk methods by having a `nextMemorySegment()` benchmark method which make a single fill call site to observe the different segments (types).
> 
> Having separate call-sites which observe always the same type(s) "could" be too lucky (and gentle) for the runtime (and CHA) and would favour to have a single address entry (or few ones, if we include any optimization for the fill size) in the Branch Target Buffer of the cpu.

I've added a "mixed" benchmark. I am not sure I understood all of your comments but given my changes, maybe you could elaborate a bit more?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2468362180

From liach at openjdk.org  Mon Nov 11 14:56:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 11 Nov 2024 14:56:27 GMT
Subject: RFR: 8343925: [BACKOUT] JDK-8342650 Move getChars to DecimalDigits
In-Reply-To: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
References: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
Message-ID: <gRODkIBUMIqyBaCmZzWWfAJV5lP9_iN8flNfpfeiw18=.6410e22d-dd6e-43a5-9c2e-91a7191c2690@github.com>

On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash, 
> 
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more testing is needed, so let's roll it back first.

CI results look good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22012#pullrequestreview-2427501471

From viktor.klang at oracle.com  Mon Nov 11 14:59:15 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 11 Nov 2024 14:59:15 +0000
Subject: Question about Streams, Gatherers, and fetching too many elements
In-Reply-To: <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
Message-ID: <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David,

This is the effect of how parallel streams are implemented, where different stages, which are not representible as a join-less Spliterator are executed as a series of "islands" where the next isn't started until the former has completed.

If you think about it, parallelization of a Stream works best when the entire data set can be split amongst a set of worker threads, and that sort of implies that you want eager pre-fetch of data, so if your dataset does not fit in memory, that is likely to lead to less desirable outcomes.

What I was able to do for Gatherers is to implement "gather(?) + collect(?)"-fusion so any number of consecutive gather(?)-operations immediately followed by a collect(?) is run in the same "island".

So with that said, you could try something like the following:

static <T> Collector<T, ?, Void> forEach(Consumer<? super T> each) {
    return Collector.of(() -> null, (v, e) -> each.accept(e), (l, r) -> l, (v) -> null, Collector.Characteristics.IDENTITY_FINISH);
}


stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.collect(forEach(eachList -> println(eachList.getFirst())));


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Monday, 11 November 2024 14:52
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: Question about Streams, Gatherers, and fetching too many elements

And just to avoid the obvious question, I can hold about 30 batches in memory before the Out of Memory error occurs. So this is not an issue of my batch size being too high.

But just to confirm, I set the batch size to 1, and it still ran into an out of memory error. So I feel fairly confident saying that the Gatherer is trying to grab all available data before sending any of it downstream.

On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Hello Core Libs Dev Team,

I was trying out Gatherers for a project at work, and ran into a rather sad scenario.

I need to process a large file in batches. Each batch is small enough that I can hold it in memory, but I cannot hold the entire file (and thus, all of the batches) in memory at once.

Looking at the Gatherers API, I saw windowFixed and thought that it would be a great match for my use case.

However, when trying it out, I was disappointed to see that it ran out of memory very quickly. Here is my attempt at using it.

stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.forEach(eachList -> println(eachList.getFirst()))
;

As you can see, I am just splitting the file into batches, and printing out the first of each batch. This is purely for example's sake, of course. I had planned on building even more functionality on top of this, but I couldn't even get past this example.

But anyways, not even a single one of them printed out. Which leads me to believe that it's pulling all of them in the Gatherer.

I can get it to run successfully if I go sequentially, but not parallel. Parallel gives me that out of memory error.

Is there any way for me to be able to have the Gatherer NOT pull in everything while still remaining parallel and unordered?

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241111/1bcee417/attachment.htm>

From duke at openjdk.org  Mon Nov 11 15:00:31 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Mon, 11 Nov 2024 15:00:31 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes [v2]
In-Reply-To: <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>
Message-ID: <fNepuywZT8lhiKQMej7fEwfkiNgHGQda5rE9sYfnsyk=.5741df84-748a-468f-a933-cb704447d0a1@github.com>

On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Add mixed test
>  - Merge branch 'master' into ms-fill-bench-sizes
>  - Use static arrays
>  - Revert changes from other branch
>  - Add benchmark
>  - Add benchmarks

test/micro/org/openjdk/bench/java/lang/foreign/SegmentBulkRandomFill.java line 169:

> 167:     public void mixedSegmentFillUnsafe() {
> 168:         for (int i = 0; i < INSTANCES; i++) {
> 169:             MIXED_SEGMENTS[i].fill((byte) 0);

loop unrolling can defeat a bit the purpose of messing up with branch misprediction here so...one solution is to avoid loop unrolling OR

create a 

@CompilerControl(DONTINLINE)
static void fillSegment(MemorySegment ms, byte value) {
    memorySegment.fill(value);
}

which makes sure (at the cost of a very predictable call to the `fillSegment` method) that:
- the inlining depth of fill is controlled and not dependent by the depth of the JMH infra caller
- the call site for fill is always the same (in term of the address in the compiled blob)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22010#discussion_r1836806492

From vklang at openjdk.org  Mon Nov 11 15:15:19 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Nov 2024 15:15:19 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v21]
In-Reply-To: <CZgxCjEdct918hzacDCL9MkR1LfyAo2kj2gPFUdySgs=.7324a202-e7f0-45f0-b0cb-5626e164937a@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <CZgxCjEdct918hzacDCL9MkR1LfyAo2kj2gPFUdySgs=.7324a202-e7f0-45f0-b0cb-5626e164937a@github.com>
Message-ID: <sIjQeR8Z1D6AEHVLezAzcHTo6gDdk7_yiYiIxiNqLGI=.829bfe2d-e6a3-4934-8961-0e7bcfa9f360@github.com>

On Sun, 10 Nov 2024 17:51:43 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 40 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Minor improvements
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Add CLEANED runState
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - More shutdown streamlining
>  - Don't report termination while cancellations in progress
>  - Reduce read contention
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Reduce shutdown overhead and contention
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/c6713e65...4db28137

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 414:

> 412:      * roles, as lockable, versioned counters. Field runState also
> 413:      * includes monotonic event bits (SHUTDOWN, STOP, CLEANED (when
> 414:      * all queues are knowm to be empty after stopping) and

Suggestion:

     * all queues are known to be empty after stopping) and

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 662:

> 660:      * tasks until runState is marked as CLEANED (staggering queues
> 661:      * and backing off on interference to avoid contention while doing
> 662:      * so-- see method cleanQueues). These actions race with

Suggestion:

     * so--see method cleanQueues). These actions race with

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1836824631
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1836828143

From swen at openjdk.org  Mon Nov 11 15:17:21 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Mon, 11 Nov 2024 15:17:21 GMT
Subject: Integrated: 8343925: [BACKOUT] JDK-8342650 Move getChars to
 DecimalDigits
In-Reply-To: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
References: <AagMC3VB6IVFHoO9uD-XNMJqCndqLAF_rxQ7c9yOwMk=.a281e9a4-c436-43aa-9cd1-e617c9006658@github.com>
Message-ID: <VFYeVh1tnvLYT7OTupmJOwxqifcwUh51OtQ6E0IfXDg=.8da5b76f-8cfd-4fb5-a77a-a7e7a2ebb0f7@github.com>

On Mon, 11 Nov 2024 12:34:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> 8343925 Feedback PR #21593 test/jdk/java/util/BitSet/HugeToString.java crash, 
> 
> I can't reproduce the problem on a MacBook M1 Max, but I agree that more testing is needed, so let's roll it back first.

This pull request has now been integrated.

Changeset: b0a371b0
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/b0a371b0850b8f467ed985ef39a6fce476b62acf
Stats:     757 lines in 12 files changed: 352 ins; 381 del; 24 mod

8343925: [BACKOUT] JDK-8342650 Move getChars to DecimalDigits

Reviewed-by: jpai, alanb, liach

-------------

PR: https://git.openjdk.org/jdk/pull/22012

From sgehwolf at openjdk.org  Mon Nov 11 15:19:55 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Nov 2024 15:19:55 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <JA5e0849G0dyo3VHxy3PJv8gP24EhBf7TQFXLPS3X6I=.22497b11-a860-4719-97c6-7908ac2f194e@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <fAhfiQBSc7J2VaTEK1tu8_Il0EOCaxp9-fCV_36f9Co=.6dcb0be9-55d6-4520-b8aa-40b768591a99@github.com>
 <JA5e0849G0dyo3VHxy3PJv8gP24EhBf7TQFXLPS3X6I=.22497b11-a860-4719-97c6-7908ac2f194e@github.com>
Message-ID: <tYp5FF2B1fHT6rn48SqtB9XcHtc-ti6Uu4wiFCaNEKU=.5ada151b-8deb-455f-95cd-01c5e68497d0@github.com>

On Mon, 11 Nov 2024 10:20:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> > In the above script, a containerized process (/bin/sh) is moved to cgroup /test before /jdk/bin/java gets executed. Java inherits cgroup /test from its parent process, its _root will be /docker/<CONTAINER_ID>, cgroup_path will be /test.
>
> OK, but why is https://bugs.openjdk.org/browse/JDK-8322420 not in effect in such a case?

Answering my own question. Because the `set_subsystem_path()` function for cg v1 in this unusual setup returns `null`.


[0.001s][trace][os,container] OSContainer::init: Initializing Container Support
[0.001s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
[0.002s][debug][os,container] Detected cgroups hybrid or legacy hierarchy, using cgroups v1 controllers
[0.002s][trace][os,container] Adjusting controller path for memory: (null)
[0.002s][debug][os,container] read_string: subsystem path is null
[0.002s][trace][os,container] Memory Limit failed: -2
[0.002s][debug][os,container] read_string: subsystem path is null
[0.002s][trace][os,container] Memory Limit failed: -2
[0.002s][trace][os,container] No lower limit found for memory in hierarchy /sys/fs/cgroup/memory, adjusting to original path /test
[0.002s][debug][os,container] OSContainer::init: is_containerized() = true because all controllers are mounted read-only (container case)
[0.003s][trace][os,container] Path to /cpu.cfs_quota_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_quota_us
[0.003s][trace][os,container] CPU Quota is: -1
[0.003s][trace][os,container] Path to /cpu.cfs_period_us is /sys/fs/cgroup/cpu,cpuacct/cpu.cfs_period_us
[0.003s][trace][os,container] CPU Period is: 100000
[0.003s][trace][os,container] OSContainer::active_processor_count: 12
[0.003s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 12
[0.003s][trace][os,container] total physical memory: 67163226112
[0.003s][debug][os,container] read_string: subsystem path is null
[0.003s][trace][os,container] Memory Limit failed: -2
[0.005s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 12
[0.021s][trace][os,container] CgroupSubsystem::active_processor_count (cached): 12
openjdk 24-internal 2025-03-18
OpenJDK Runtime Environment (build 24-internal-adhoc.sgehwolf.jdk-jdk)
OpenJDK 64-Bit Server VM (build 24-internal-adhoc.sgehwolf.jdk-jdk, mixed mode, sharing)


On cg v2, on the other hand, `set_subsystem_path()` will never set the path to a `null` value.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468417142

From sgehwolf at openjdk.org  Mon Nov 11 15:50:57 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 11 Nov 2024 15:50:57 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
Message-ID: <bBVzzCrsP8nVqUByNn81U6OJ5MkQuaCw-BlHsvJ2SMk=.ee20c671-08a3-4e1e-97af-da321d50ce76@github.com>

On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343191
>  - patch reimplemented
>  - fix the logic that skips duplicate controller's mount points
>  - 8343191: Cgroup v1 subsystem fails to set subsystem path

So on cg v1 you start out and end with a `subsystem_path() == null` and on cg v2 you start out and end with a `subsystem_path() == /../../../../../../test`. In both cases the memory limit of 400m won't be detected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468488527

From dl at openjdk.org  Mon Nov 11 15:58:25 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 11 Nov 2024 15:58:25 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v22]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <3NG4gxSQ58Wl3HNszoPhfByicvcBlVU-v5SkyMSyOTo=.873b7f9b-0106-409d-bed4-bfab2025173a@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 41 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Minor improvements
 - Merge branch 'openjdk:master' into JDK-8336707
 - Add CLEANED runState
 - Merge branch 'openjdk:master' into JDK-8336707
 - More shutdown streamlining
 - Don't report termination while cancellations in progress
 - Reduce read contention
 - Merge branch 'openjdk:master' into JDK-8336707
 - ... and 31 more: https://git.openjdk.org/jdk/compare/2831441d...7d15d64f

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/4db28137..7d15d64f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=20-21

  Stats: 5444 lines in 83 files changed: 4777 ins; 470 del; 197 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From dl at openjdk.org  Mon Nov 11 16:01:08 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 11 Nov 2024 16:01:08 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v23]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <CLmygqYoeZOZmurSxx614f27pisbP8aQRo_4pY6hbos=.4534f60e-b331-46dd-ac5b-3f60c06bc171@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with two additional commits since the last revision:

 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
 - Reconcile internal docs; renamings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/7d15d64f..fd19351b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=22
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=21-22

  Stats: 57 lines in 1 file changed: 15 ins; 0 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From vklang at openjdk.org  Mon Nov 11 16:20:05 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Nov 2024 16:20:05 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v23]
In-Reply-To: <CLmygqYoeZOZmurSxx614f27pisbP8aQRo_4pY6hbos=.4534f60e-b331-46dd-ac5b-3f60c06bc171@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <CLmygqYoeZOZmurSxx614f27pisbP8aQRo_4pY6hbos=.4534f60e-b331-46dd-ac5b-3f60c06bc171@github.com>
Message-ID: <FSYlQ8nZo8JZVu_A0aeDpZk1_NK2MQswyWcZk8AeUiI=.6e3e8427-4e73-4ca9-a861-ea5e4bda98ca@github.com>

On Mon, 11 Nov 2024 16:01:08 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
>  - Reconcile internal docs; renamings

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 417:

> 415:      * * STOP: no more tasks run, and deregister all workers
> 416:      * * CLEANED: all unexecuted tasks have been cancelled
> 417:      * * TERMINATED: all qorkers deregistered and all queues cleaned

Suggestion:

     * * TERMINATED: all workers deregistered and all queues cleaned

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 663:

> 661:      * * A call to shutdownNow, in which case all workers are
> 662:      *   interrupted.  ensuring that the queues array is stable,
> 663:      *   so will not miss any of them.

Suggestion:

     *   interrupted, and ensuring that the array of queues is stable,
     *   so will not miss any of them.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 676:

> 674:      * cancel (benefitting from parallelism) versus contention and
> 675:      * interference when many threads try to poll remaining queues,
> 676:      * while also avoiding unnecessary rechedcks, by using

Suggestion:

     * while also avoiding unnecessary rechecks, by using

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 688:

> 686:      * before executing task bodies, and ensures interrupts while
> 687:      * terminating. Even so, there are no guarantees because tasks may
> 688:      * internally enter unbounded loops.

Good point to make

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 874:

> 872:      * cancellation by others, which can occur along several different
> 873:      * paths. The inability to rely on caller-runs may also require
> 874:      * extra signalling (and resulting scanning and contention) so is

Suggestion:

     * extra signalling (resulting in increased scanning and contention) so is

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1836899379
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1836903791
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1836908015
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1836908858
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1836910984

From duke at openjdk.org  Mon Nov 11 16:24:14 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Mon, 11 Nov 2024 16:24:14 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v8]
In-Reply-To: <ELfo-c5mx1cvcf49gJTt_L_-kxq-QWZdN5QlEsdZH0Q=.3e46bd59-e684-411d-8497-5dc3701ae594@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <ELfo-c5mx1cvcf49gJTt_L_-kxq-QWZdN5QlEsdZH0Q=.3e46bd59-e684-411d-8497-5dc3701ae594@github.com>
Message-ID: <WBokGEaU5LSxFw5ubkEdb-ivgnSqWkOjo3FFoomeb7s=.a12123ed-6c6f-4974-8320-b20729501e61@github.com>

On Tue, 22 Oct 2024 12:49:08 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Round out the documentation of the new methods to explain the supported and unsupported cases

I think I'm just needing two reviewers now (and a sponsor after that). It's close!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2468558562

From dl at openjdk.org  Mon Nov 11 16:39:47 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 11 Nov 2024 16:39:47 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v24]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <XvZ2q1QD4p4mN4DLaJZUvt_JVS3EbVSRQU90n9SmPtY=.137be678-a4c6-43d3-baa3-3e33324dd102@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/fd19351b..e1460f57

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=23
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=22-23

  Stats: 11 lines in 1 file changed: 5 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From schernyshev at openjdk.org  Mon Nov 11 16:50:43 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 11 Nov 2024 16:50:43 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path
In-Reply-To: <tYp5FF2B1fHT6rn48SqtB9XcHtc-ti6Uu4wiFCaNEKU=.5ada151b-8deb-455f-95cd-01c5e68497d0@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <fAhfiQBSc7J2VaTEK1tu8_Il0EOCaxp9-fCV_36f9Co=.6dcb0be9-55d6-4520-b8aa-40b768591a99@github.com>
 <JA5e0849G0dyo3VHxy3PJv8gP24EhBf7TQFXLPS3X6I=.22497b11-a860-4719-97c6-7908ac2f194e@github.com>
 <tYp5FF2B1fHT6rn48SqtB9XcHtc-ti6Uu4wiFCaNEKU=.5ada151b-8deb-455f-95cd-01c5e68497d0@github.com>
Message-ID: <lbsefy-eQLRFBhscMO5EfdFjdf53cGoKcchPjEgjOA0=.8359bf4d-8640-4679-bec6-7d8f28e3d5b0@github.com>

On Mon, 11 Nov 2024 15:16:15 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> On cg v2, on the other hand, `set_subsystem_path()` will never set the path to a `null` value.

Exactly. That's why JDK-8322420 is not in effect and also [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) does not fix it on Java side (path stays uninitialized in certain conditions).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468614420

From andrew at openjdk.org  Mon Nov 11 16:50:44 2024
From: andrew at openjdk.org (Andrew John Hughes)
Date: Mon, 11 Nov 2024 16:50:44 GMT
Subject: RFR: 8334048: -Xbootclasspath can not read some ZIP64 zip files
 [v4]
In-Reply-To: <_oGktmgDyMxSetVyuY5eZwOwr6lVDVuJTrk-vNXj0b8=.042f429e-a760-45fe-b5c2-68dc16afa42e@github.com>
References: <Rtnk9XTzvzS3oDbsKaMH-EgqU6JdCoaCBjlOqxwqPJU=.eaa8a0cf-4cfc-46c8-b448-511bf7c3823e@github.com>
 <Gn8hZZh6sOzHO2mttoFY9einys2nCWrpew9NPH2Ltvs=.60ba4237-9ffd-438e-bab7-ee9653a3731f@github.com>
 <N5Ztdj9jf2GmhTm8Ejpdc5zPvFVCocPEnXXm6FLFYJA=.92279f5b-2567-464e-b374-0b7a4b1f657e@github.com>
 <_oGktmgDyMxSetVyuY5eZwOwr6lVDVuJTrk-vNXj0b8=.042f429e-a760-45fe-b5c2-68dc16afa42e@github.com>
Message-ID: <WrJc6e7EJoLGpN9C4IIkYzZHDCRAoaUxDtCX92a4duc=.19183edb-7f1f-45d9-b0e1-66af68f0945c@github.com>

On Tue, 10 Sep 2024 05:46:46 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I pushed the review suggestions.  There were two GitHub Actions failures on `macos-aarch64`, but they look to be occurrences of this existing bug: https://bugs.openjdk.org/browse/JDK-8247940.
>
> Hello @fitzsim, I plan to take a look at this change and also consult with others familiar with the bootclasspath area as well as jar/zip area. I am just noting this now to let you know that the PR hasn't been neglected and I think it will take a while for this to be reviewed given the nature and area of this change.

> Sounds good @jaikiran.
> 
> I can provide some background about this pull request; it was the result of discussions on a related jdk8u-dev pull request ([openjdk/jdk8u-dev#452](https://github.com/openjdk/jdk8u-dev/pull/452)).
> 
> Red Hat has been shipping the `zip_util.c` change proposed here, authored by @gnu-andrew, as a patch to our Red Hat Enterprise Linux `java-1.8.0-openjdk` packages since mid-2020. In that release all `ZIP` files the `JDK` uses are processed by `zip_util.c` unless someone is using the demo `Java` implementation. We have had no field reports of issues with the patch.
> 
> @gnu-andrew and I would like to upstream `ZIP64` support to `jdk8u`, but the `zip_util.c` patch only exists within Red Hat's package repository, not anywhere upstream from where it could be backported.
> 
> When I checked for the most recent branch that still shipped `zip_util.c`, I discovered that even mainline still ships it, albeit now only for use in `-Xbootclasspath` handling. So I split the `zip_util.c` patch out and added some tests to demonstrate the bug itself and that there should be no regressions, and filed this pull request.
> 
> If this is accepted into mainline and gets some broader testing with no issue, then I would like to backport it to 21, 17, 11, and 8.

Just to add to this, while the `zip_util.c` changes are unique to our 8u patch, they are a conversion to C of the equivalent Java changes made in [JDK-8186464](https://bugs.openjdk.org/browse/JDK-8186464), with the intention to backport that change to 8u without the risk of [JDK-8145260](https://bugs.openjdk.org/browse/JDK-8145260), which introduces the Java-based implementation. So if there is a risk in this patch, it is likely a risk of a mistake in the translation to C rather than the general gist of the changes, which are present in the JDK's Java zip code.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19678#issuecomment-2468614066

From mcimadamore at openjdk.org  Mon Nov 11 17:27:39 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Nov 2024 17:27:39 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes [v2]
In-Reply-To: <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>
Message-ID: <KidZ040zqUD0-BDCiIjzgZKviUJFZQY4Cu4M7g32mBE=.ea8b28c4-81bd-4f7d-9219-9ca0c054e76d@github.com>

On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Add mixed test
>  - Merge branch 'master' into ms-fill-bench-sizes
>  - Use static arrays
>  - Revert changes from other branch
>  - Add benchmark
>  - Add benchmarks

IIUC, this benchmark is designed to test what happens in the case where a bulk operation is executed on a segment whose type is not known e.g. through type profiling (e.g. polluted case). Note that in this case (MIXED) the fact that we can't rely on which segment it is (and hence on whether it has a certain scope or not, and what the base object is) would greatly dominate the cost of branch misprediction, which I saw mentioned here. In extreme cases of profile pollution it is very possible for a method to be optimized under the assumption that e.g. the method is always executed on off-heap segments, and then hit an on-heap segment, which will perform horribly.

We have test cases such as these in `LoopOverPolluted[Segments/Buffer]`. It makes sense to test something similar for bulk access too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2468683925

From davidalayachew at gmail.com  Mon Nov 11 17:32:04 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 11 Nov 2024 12:32:04 -0500
Subject: Question about Streams, Gatherers, and fetching too many elements
In-Reply-To: <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>

Thanks for the workaround. It's running beautifully.

Is there a future where this island concept is extended to the rest of
streams? Tbh, I don't fully understand it.

On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Hi David,
>
> This is the effect of how parallel streams are implemented, where
> different stages, which are not representible as a join-less Spliterator
> are executed as a series of "islands" where the next isn't started until
> the former has completed.
>
> If you think about it, parallelization of a Stream works best when the
> entire data set can be split amongst a set of worker threads, and that sort
> of implies that you want eager pre-fetch of data, so if your dataset does
> not fit in memory, that is likely to lead to less desirable outcomes.
>
> What I was able to do for Gatherers is to implement "gather(?) +
> collect(?)"-fusion so any number of consecutive gather(?)-operations
> immediately followed by a collect(?) is run in the same "island".
>
> So with that said, you could try something like the following:
>
> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>     *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> }
>
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .collect(forEach(eachList -> println(eachList.getFirst())));
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 14:52
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> elements
>
> And just to avoid the obvious question, I can hold about 30 batches in
> memory before the Out of Memory error occurs. So this is not an issue of my
> batch size being too high.
>
> But just to confirm, I set the batch size to 1, and it still ran into an
> out of memory error. So I feel fairly confident saying that the Gatherer is
> trying to grab all available data before sending any of it downstream.
>
> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Core Libs Dev Team,
>
> I was trying out Gatherers for a project at work, and ran into a rather
> sad scenario.
>
> I need to process a large file in batches. Each batch is small enough that
> I can hold it in memory, but I cannot hold the entire file (and thus, all
> of the batches) in memory at once.
>
> Looking at the Gatherers API, I saw windowFixed and thought that it would
> be a great match for my use case.
>
> However, when trying it out, I was disappointed to see that it ran out of
> memory very quickly. Here is my attempt at using it.
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .forEach(eachList -> println(eachList.getFirst()))
> ;
>
> As you can see, I am just splitting the file into batches, and printing
> out the first of each batch. This is purely for example's sake, of course.
> I had planned on building even more functionality on top of this, but I
> couldn't even get past this example.
>
> But anyways, not even a single one of them printed out. Which leads me to
> believe that it's pulling all of them in the Gatherer.
>
> I can get it to run successfully if I go sequentially, but not parallel.
> Parallel gives me that out of memory error.
>
> Is there any way for me to be able to have the Gatherer NOT pull in
> everything while still remaining parallel and unordered?
>
> Thank you for your time and help.
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241111/9e870315/attachment.htm>

From mcimadamore at openjdk.org  Mon Nov 11 17:32:13 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Mon, 11 Nov 2024 17:32:13 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v13]
In-Reply-To: <USOSWDBf9RVnSHwWTBLioLapegwVCQDYJ6N25uFTOXk=.2601aac7-1bc3-45aa-bc36-30e01f900961@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <e5AoQnwnl2vLztV4xKNjhSxusEDjOk7cCb_4RwVdVk4=.003bb6ac-f1eb-40ed-a25c-dae005cbc727@github.com>
 <LawuEa23JaOsGyhzvMd2OBz8CsLM9svCKcIRvPANiMk=.3f16cca7-2188-4cd5-8045-fdd19f5fb965@github.com>
 <USOSWDBf9RVnSHwWTBLioLapegwVCQDYJ6N25uFTOXk=.2601aac7-1bc3-45aa-bc36-30e01f900961@github.com>
Message-ID: <iPnni7OibP4hXdq5zUM7SEtkugZcE4LnZHF3R_Gj6N8=.9a6df19f-80f8-4ca1-ba57-c63cffb75f7a@github.com>

On Wed, 6 Nov 2024 15:25:07 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Maybe we should also check that padding layouts have natural alignment? The alignment of padding layouts can affect the alignment of the enclosing container.

This makes sense, but I wonder if that would require a change in the javadoc?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2468691923

From aivanov at openjdk.org  Mon Nov 11 17:43:07 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Mon, 11 Nov 2024 17:43:07 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <voi4oro4vOIyFaia1dfCKyovboT8UjVLSHBqvJ-DVC0=.f60fe7a4-ad64-4ca0-a3b6-7698a683cb13@github.com>
 <jG_yLvruXSUTFFRF2T5hzldzvw9n1V5VrcjMCq8Y_P4=.751b17c3-2e32-4f55-9054-a324925677f6@github.com>
 <kyA1GJELUFRbfhGxl6jy2eitBCaaei03atxUfepOL8M=.f10a5ad6-d2e7-4264-b706-3ce88aa273fa@github.com>
 <YPssTfGfA48FZ4OdLb3CZvvnOvPd7oYo8P35MuDmh0g=.2163f154-48e9-4b99-b186-ef0a7236d9fd@github.com>
 <eWDjntQN3rupDYhzwWrKrHwCMIgDvgMxysEYnoBJCzE=.7f5761b6-6c3c-469b-9eac-b5e47fb33ad2@github.com>
 <KK8dWzpfIuvXAH0o4iLbLBsh8lEN9-dEGdIYYa0sfrY=.147ec06d-3f55-47e3-9f19-88fef2dedab9@github.com>
 <Dc1jk0KHJNOAblqGZJ517LuTAwNBupOSYcE2n9ZvK18=.73067a49-83d0-48e8-b8fb-0c23410cdf86@github.com>
 <IH261yKqYCgkLLC0UtoNSV5zVPWIpV3BmDL_5dDXXJE=.078563d6-25c5-4bac-9d4f-21c5c2eac04b@github.com>
Message-ID: <VilcXY4GAxFg7sMG9MUvtI6XuOGtJLr1uokZFIV1ipc=.1ad3e90d-fd00-49f4-9468-24651fa74cd5@github.com>

On Fri, 8 Nov 2024 21:01:57 GMT, Phil Race <prr at openjdk.org> wrote:

>>> I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test.
>> 
>> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>> 
>> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
>> 
>> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198
>
>> > I'd not looked at this test before but when I do the thing I noticed is that createPrivateValue is no longer used. But I don't see a problem with keeping the rest of the test.
>> 
>> @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>> 
>> The [`MultiUIDefaults` class](https://github.com/openjdk/jdk/blob/master/src/java.desktop/share/classes/javax/swing/MultiUIDefaults.java) is used in `UIManager`:
>> 
>> https://github.com/openjdk/jdk/blob/c82ad845e101bf5d97c0744377d68002907d4a0e/src/java.desktop/share/classes/javax/swing/UIManager.java#L198
> 
> I think I was just saying there appeared to be dead code in the test.

> > @prrace Do I understand correctly that _?`createPrivateValue` is no longer used?_ means `MultiUIDefaults` is never used with `ProxyLazyValue`?
>
> I think I was just saying there appeared to be dead code in the test.

Hmm? `createPrivateValue` had been called from the `main` method, so it had been used in the test until it was removed in https://github.com/openjdk/jdk/commit/9eb275c4aaf9a88127c5c33e0bf7ca35125f29ea

Since `MultiUIDefaults` is still used in `UIManager` and we're keeping the test, I'm for keeping a test for `createPrivateValue` too.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1837009964

From schernyshev at openjdk.org  Mon Nov 11 18:31:16 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Mon, 11 Nov 2024 18:31:16 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <bBVzzCrsP8nVqUByNn81U6OJ5MkQuaCw-BlHsvJ2SMk=.ee20c671-08a3-4e1e-97af-da321d50ce76@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <bBVzzCrsP8nVqUByNn81U6OJ5MkQuaCw-BlHsvJ2SMk=.ee20c671-08a3-4e1e-97af-da321d50ce76@github.com>
Message-ID: <P4oda35gwgw-76EC-1VxU9Bpaen7hylVFwf5BEynroY=.d7658a3e-ec22-43cc-b419-91ee62f71397@github.com>

On Mon, 11 Nov 2024 15:48:48 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> So on cg v1 you start out and end with a `subsystem_path() == null` and on cg v2 you start out and end with a `subsystem_path() == /../../../../../../test`. In both cases the memory limit of 400m won't be detected.

Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2468791946

From eirbjo at openjdk.org  Mon Nov 11 19:13:16 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 11 Nov 2024 19:13:16 GMT
Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fourth
 Preview)
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <BRuybt3X6-ujFzY7RTSVjx2tOwM100T8KxjGIV1u8tk=.d748ae99-d82d-4ea1-8f5e-065738d77773@github.com>

On Wed, 6 Nov 2024 15:47:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Changes for [JEP draft: Structured Concurrency (Fourth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 645:

> 643:          *
> 644:          * <p> This Joiner can also be used for <em>fan-in</em> scenarios where subtasks
> 645:          * for forked to handle incoming connections and the number of subtasks is unbounded.

Sentence does not read well. Should 'for' have been 'are'?

Suggestion:

         * are forked to handle incoming connections and the number of subtasks is unbounded.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21934#discussion_r1837091844

From viktor.klang at oracle.com  Mon Nov 11 19:34:37 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Mon, 11 Nov 2024 19:34:37 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
Message-ID: <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>

You're most welcome!

In a potential future where all intermediate operations are Gatherer-based, and all terminal operations are Collector-based, it would just work as expected. But with that said, I'm not sure it is practically achievable because some operations might not have the same performance-characteristics as before.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Monday, 11 November 2024 18:32
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Thanks for the workaround. It's running beautifully.

Is there a future where this island concept is extended to the rest of streams? Tbh, I don't fully understand it.

On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi David,

This is the effect of how parallel streams are implemented, where different stages, which are not representible as a join-less Spliterator are executed as a series of "islands" where the next isn't started until the former has completed.

If you think about it, parallelization of a Stream works best when the entire data set can be split amongst a set of worker threads, and that sort of implies that you want eager pre-fetch of data, so if your dataset does not fit in memory, that is likely to lead to less desirable outcomes.

What I was able to do for Gatherers is to implement "gather(?) + collect(?)"-fusion so any number of consecutive gather(?)-operations immediately followed by a collect(?) is run in the same "island".

So with that said, you could try something like the following:

static <T> Collector<T, ?, Void> forEach(Consumer<? super T> each) {
    return Collector.of(() -> null, (v, e) -> each.accept(e), (l, r) -> l, (v) -> null, Collector.Characteristics.IDENTITY_FINISH);
}


stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.collect(forEach(eachList -> println(eachList.getFirst())));


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Monday, 11 November 2024 14:52
To: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question about Streams, Gatherers, and fetching too many elements

And just to avoid the obvious question, I can hold about 30 batches in memory before the Out of Memory error occurs. So this is not an issue of my batch size being too high.

But just to confirm, I set the batch size to 1, and it still ran into an out of memory error. So I feel fairly confident saying that the Gatherer is trying to grab all available data before sending any of it downstream.

On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Hello Core Libs Dev Team,

I was trying out Gatherers for a project at work, and ran into a rather sad scenario.

I need to process a large file in batches. Each batch is small enough that I can hold it in memory, but I cannot hold the entire file (and thus, all of the batches) in memory at once.

Looking at the Gatherers API, I saw windowFixed and thought that it would be a great match for my use case.

However, when trying it out, I was disappointed to see that it ran out of memory very quickly. Here is my attempt at using it.

stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.forEach(eachList -> println(eachList.getFirst()))
;

As you can see, I am just splitting the file into batches, and printing out the first of each batch. This is purely for example's sake, of course. I had planned on building even more functionality on top of this, but I couldn't even get past this example.

But anyways, not even a single one of them printed out. Which leads me to believe that it's pulling all of them in the Gatherer.

I can get it to run successfully if I go sequentially, but not parallel. Parallel gives me that out of memory error.

Is there any way for me to be able to have the Gatherer NOT pull in everything while still remaining parallel and unordered?

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241111/629d5327/attachment-0001.htm>

From vklang at openjdk.org  Mon Nov 11 20:00:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Nov 2024 20:00:16 GMT
Subject: Integrated: 8342707: Prepare Gatherers for graduation from Preview
In-Reply-To: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
References: <Izr-3foxrw3a1NSy_lDSLfyWzlJyx8qW2O_cnvrQnto=.670b312a-67b4-44da-8d01-d828276810f8@github.com>
Message-ID: <Ng_UXdk-ROCyhjZ8Re--lZErpjzKSb7cAB14fcFuj3I=.d2e537d4-fc92-4c1f-ae5f-2e67635ff42d@github.com>

On Thu, 24 Oct 2024 15:09:00 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> Make final adjustments to drop PreviewFeature and updating the @ since markers.

This pull request has now been integrated.

Changeset: ef0dc251
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ef0dc2518e7636cc8a9ca580613ff5edeb4c19fd
Stats:     50 lines in 24 files changed: 0 ins; 19 del; 31 mod

8342707: Prepare Gatherers for graduation from Preview

Reviewed-by: alanb, liach

-------------

PR: https://git.openjdk.org/jdk/pull/21686

From vklang at openjdk.org  Mon Nov 11 21:48:03 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 11 Nov 2024 21:48:03 GMT
Subject: RFR: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <nfBfmcab2DE9yTElqMi2L01jRr_V2F7tYkXrIZQR9hw=.3cf59898-b4fb-4b7d-bc78-37f48f98c279@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

@kabutz In case you missed this:

"?? To flag this PR as ready for integration with the above commit message, type /integrate in a new comment. (Afterwards, your sponsor types /sponsor in a new comment to perform the integration)."

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21783#issuecomment-2469092130

From duke at openjdk.org  Mon Nov 11 21:56:39 2024
From: duke at openjdk.org (duke)
Date: Mon, 11 Nov 2024 21:56:39 GMT
Subject: RFR: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <gi0YaKSeQ3q73dCOh4fZw9ekw4AanULwtJXOyQlWyTQ=.3774f33b-d742-410d-accb-431bf05aef25@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

@kabutz 
Your change (at version 5dc64f7ee613d2738c4abcf97aa79b81e7727f46) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21783#issuecomment-2469120159

From cjplummer at openjdk.org  Mon Nov 11 22:17:18 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Mon, 11 Nov 2024 22:17:18 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <z0A00_ZdmryzLH-V1BjGsQWo40QFepXN9wgHihhQckY=.dc8c0b43-327b-4363-921a-914df05a2192@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2428256817

From davidalayachew at gmail.com  Tue Nov 12 00:53:20 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Mon, 11 Nov 2024 19:53:20 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>

Good to know, ty vm.

At the very least, I have this workaround. This will meet my needs for now.

I guess my final question would be -- is this type of problem better suited
to something besides parallel streams? Maybe an ExecutorService?

Really, all I am doing is taking a jumbo file, splitting it into batches,
and then doing some work on those batches. My IO speeds are pretty fast,
and the compute work is non-trivial, so there is performance being left on
the table if I give up parallelism. And I am in a position where completion
time is very important to us.

I just naturally assumed parallel streams were the right choice because the
compute work is simple. A pure function that I can break out, and then call
in a map. Once I do that, I just call forEach to write the batches back out
to S3. Maybe I should look into a different part of the std lib instead
because I am using the wrong tool for the job? My nose says
ExecutorService, but I figure I should ask before I dive too deep in.


On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com> wrote:

> You're most welcome!
>
> In a potential future where all intermediate operations are
> Gatherer-based, and all terminal operations are Collector-based, it would
> just work as expected. But with that said, I'm not sure it is practically
> achievable because some operations might not have the same
> performance-characteristics as before.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 18:32
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Thanks for the workaround. It's running beautifully.
>
> Is there a future where this island concept is extended to the rest of
> streams? Tbh, I don't fully understand it.
>
> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi David,
>
> This is the effect of how parallel streams are implemented, where
> different stages, which are not representible as a join-less Spliterator
> are executed as a series of "islands" where the next isn't started until
> the former has completed.
>
> If you think about it, parallelization of a Stream works best when the
> entire data set can be split amongst a set of worker threads, and that sort
> of implies that you want eager pre-fetch of data, so if your dataset does
> not fit in memory, that is likely to lead to less desirable outcomes.
>
> What I was able to do for Gatherers is to implement "gather(?) +
> collect(?)"-fusion so any number of consecutive gather(?)-operations
> immediately followed by a collect(?) is run in the same "island".
>
> So with that said, you could try something like the following:
>
> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>     *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> }
>
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .collect(forEach(eachList -> println(eachList.getFirst())));
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 14:52
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> elements
>
> And just to avoid the obvious question, I can hold about 30 batches in
> memory before the Out of Memory error occurs. So this is not an issue of my
> batch size being too high.
>
> But just to confirm, I set the batch size to 1, and it still ran into an
> out of memory error. So I feel fairly confident saying that the Gatherer is
> trying to grab all available data before sending any of it downstream.
>
> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Core Libs Dev Team,
>
> I was trying out Gatherers for a project at work, and ran into a rather
> sad scenario.
>
> I need to process a large file in batches. Each batch is small enough that
> I can hold it in memory, but I cannot hold the entire file (and thus, all
> of the batches) in memory at once.
>
> Looking at the Gatherers API, I saw windowFixed and thought that it would
> be a great match for my use case.
>
> However, when trying it out, I was disappointed to see that it ran out of
> memory very quickly. Here is my attempt at using it.
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .forEach(eachList -> println(eachList.getFirst()))
> ;
>
> As you can see, I am just splitting the file into batches, and printing
> out the first of each batch. This is purely for example's sake, of course.
> I had planned on building even more functionality on top of this, but I
> couldn't even get past this example.
>
> But anyways, not even a single one of them printed out. Which leads me to
> believe that it's pulling all of them in the Gatherer.
>
> I can get it to run successfully if I go sequentially, but not parallel.
> Parallel gives me that out of memory error.
>
> Is there any way for me to be able to have the Gatherer NOT pull in
> everything while still remaining parallel and unordered?
>
> Thank you for your time and help.
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241111/eef61162/attachment.htm>

From swen at openjdk.org  Tue Nov 12 01:30:29 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 01:30:29 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits
Message-ID: <pivaJlw1x5hAenGurJ0Vah2k2bwaHGcl4PeCNv6O6qM=.4504440d-4ca3-451b-bc98-9725873bb3cd@github.com>

This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed.

Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication

HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16

Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
Eliminate duplicate code in BigDecimal

This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe.

In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check.

-------------

Commit messages:
 - fix unsafe address overflow
 - add benchmark
 - remove comments, from @liach
 - Merge remote-tracking branch 'upstream/master' into int_get_chars_dedup_202410
 - fix Helper
 - fix Helper
 - fix Helper
 - unsafe putByte
 - remove digitPair
 - fix import
 - ... and 4 more: https://git.openjdk.org/jdk/compare/5890d943...cd9ba309

Changes: https://git.openjdk.org/jdk/pull/22023/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22023&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342650
  Stats: 757 lines in 12 files changed: 381 ins; 352 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/22023.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22023/head:pull/22023

PR: https://git.openjdk.org/jdk/pull/22023

From dholmes at openjdk.org  Tue Nov 12 01:51:15 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Nov 2024 01:51:15 GMT
Subject: RFR: 8342650: Move getChars to DecimalDigits
In-Reply-To: <pivaJlw1x5hAenGurJ0Vah2k2bwaHGcl4PeCNv6O6qM=.4504440d-4ca3-451b-bc98-9725873bb3cd@github.com>
References: <pivaJlw1x5hAenGurJ0Vah2k2bwaHGcl4PeCNv6O6qM=.4504440d-4ca3-451b-bc98-9725873bb3cd@github.com>
Message-ID: <rmv_wkBzE99RkxL5zQWyVXOKER7CQ0_NWKfFzND5viE=.00195093-d32c-4677-8b1a-304232d764d4@github.com>

On Tue, 12 Nov 2024 01:25:16 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> This PR is a resubmission after PR #21593 was rolled back, and the unsafe offset overflow issue has been fixed.
> 
> Move getChars methods of StringLatin1 and StringUTF16 to DecimalDigits to reduce duplication
> 
> HexDigits and OctalDigits also include getCharsLatin1 and getCharsUTF16
> 
> Putting these two methods into DecimalDigits can avoid the need to expose them in JavaLangAccess
> Eliminate duplicate code in BigDecimal
> 
> This PR will improve the performance of Integer/Long.toString and StringBuilder.append(int/long) scenarios. This is because Unsafe.putByte is used to eliminate array bounds checks, and of course this elimination is safe.
> 
> In previous versions, in Integer/Long.toString and StringBuilder.append(int/long) scenarios, -COMPACT_STRING performed better than +COMPACT_STRING. This is because StringUTF16.getChars uses StringUTF16.putChar, which is similar to Unsafe.putChar, and there is no bounds check.

@wenshao you need a new JBS issue to complete this work under.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22023#issuecomment-2469426151

From pchilanomate at openjdk.org  Tue Nov 12 02:59:59 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 02:59:59 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:

 - Merge branch 'master' into JDK-8338383
 - Test StopThreadTest.java: fix operator in condition + improve names
 - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
 - Merge branch 'master' into JDK-8338383
 - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
 - Add ObjectWaiter::at_monitorenter
 - Use get_method_name + copyright revert in jvmtiThreadState.cpp
 - Merge branch 'master' into JDK-8338383
 - Add @requires vm.continuations to CancelTimerWithContention.java
 - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
 - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

-------------

Changes: https://git.openjdk.org/jdk/pull/21565/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21565&range=04
  Stats: 9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 mod
  Patch: https://git.openjdk.org/jdk/pull/21565.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21565/head:pull/21565

PR: https://git.openjdk.org/jdk/pull/21565

From pchilanomate at openjdk.org  Tue Nov 12 03:04:35 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 03:04:35 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <b5MrSDTiXfMTA2UztpWjFYP1Vfu5SAe6OOhnv2tgVI4=.ebe93ebe-1e63-44d4-8b90-922648b83bbf@github.com>

On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

I merged with master, including the changes for [JEP 450](https://github.com/openjdk/jdk/pull/20677), and run it through tiers1-8 in mach5 with no related failures. I would like to integrate tomorrow if I could get some re-approvals. Also, I filed JDK-8343957 to possibly improve the naming of `_lock_id/owner_from` as discussed in some of the comments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2469493942

From darcy at openjdk.org  Tue Nov 12 05:42:46 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 05:42:46 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v12]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <-Z6SXvJemmUz2irQjJSco1JmpoeUIMf32SBdSNf1n84=.925ac4b7-fb0f-4fd0-b2bf-b345ea31600d@github.com>

> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.

Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:

 - Test update and minor bug fix.
 - Merge branch 'master' into JDK-8341260
 - Add Float16 -> string conversion from Raffaello.
 - Merge branch 'master' into JDK-8341260
 - Merge branch 'master' into JDK-8341260
 - Respond to review feedback.
 - Add support for proper String -> Float16 conversion.
 - Merge branch 'master' into JDK-8341260
 - Improve specification per code review feedback.
 - Add tests, improve hashing spec.
 - ... and 11 more: https://git.openjdk.org/jdk/compare/f69b3a3a...8af04c4d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/7c50bbe0..8af04c4d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=10-11

  Stats: 205741 lines in 2051 files changed: 129905 ins; 52738 del; 23098 mod
  Patch: https://git.openjdk.org/jdk/pull/21574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21574/head:pull/21574

PR: https://git.openjdk.org/jdk/pull/21574

From darcy at openjdk.org  Tue Nov 12 05:42:47 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 05:42:47 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <os_i2UbFm71sKzSWTx0Wop4j6YxKKa5SSQonlMfUP1Q=.d56186af-9c2b-4db7-89ec-aee03158f79f@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
 <os_i2UbFm71sKzSWTx0Wop4j6YxKKa5SSQonlMfUP1Q=.d56186af-9c2b-4db7-89ec-aee03158f79f@github.com>
Message-ID: <FDq3PJ9Vmr03-KIVN8YlWzI4vqgKrH86luWfr-XMQUg=.f66cf820-0233-415c-967d-47395ec16818@github.com>

On Mon, 11 Nov 2024 14:03:54 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 431:
> 
>> 429:      * @see    java.lang.Float#valueOf(String)
>> 430:      */
>> 431:     public static Float16 valueOf(String s) throws NumberFormatException {
> 
> The current implementation throws when the input is `"NaN"`, with or without an optional sign.

Thanks for catching that; fix and tests added in subsequent push.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1837508472

From darcy at openjdk.org  Tue Nov 12 05:50:47 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 05:50:47 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v12]
In-Reply-To: <-Z6SXvJemmUz2irQjJSco1JmpoeUIMf32SBdSNf1n84=.925ac4b7-fb0f-4fd0-b2bf-b345ea31600d@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <-Z6SXvJemmUz2irQjJSco1JmpoeUIMf32SBdSNf1n84=.925ac4b7-fb0f-4fd0-b2bf-b345ea31600d@github.com>
Message-ID: <1vr3JDGO_0lrQRsdw1wNxt8qnSecL5i5yrRa50QMHVo=.54b9f9cb-1665-45b4-a69e-c68a195dadba@github.com>

On Tue, 12 Nov 2024 05:42:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Test update and minor bug fix.
>  - Merge branch 'master' into JDK-8341260
>  - Add Float16 -> string conversion from Raffaello.
>  - Merge branch 'master' into JDK-8341260
>  - Merge branch 'master' into JDK-8341260
>  - Respond to review feedback.
>  - Add support for proper String -> Float16 conversion.
>  - Merge branch 'master' into JDK-8341260
>  - Improve specification per code review feedback.
>  - Add tests, improve hashing spec.
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/aaa007cb...8af04c4d

Updated the implementation with Float16 -> string conversion code from @rgiulietti and added various supporting tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2469662058

From dholmes at openjdk.org  Tue Nov 12 07:09:12 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 12 Nov 2024 07:09:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <3vfCjVBL-b8oC8v_8fW5QdXjAT1ssSjfPgFoNL1fNu0=.d7efc5eb-3e84-42b5-b8ce-9c9cc11900bf@github.com>

On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

Still good. Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2428723863

From swen at openjdk.org  Tue Nov 12 07:53:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 07:53:44 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow
Message-ID: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>

In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

-------------

Commit messages:
 - fix unsafe address overflow

Changes: https://git.openjdk.org/jdk/pull/22027/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343984
  Stats: 17 lines in 9 files changed: 0 ins; 0 del; 17 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From swen at openjdk.org  Tue Nov 12 07:53:45 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 07:53:45 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <DAezQSy8R0shDTX5eo0F9PE-eelF6XXotAGMMPuosmk=.221dbe26-d2b3-431d-851a-4e688ee737d4@github.com>

On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

There are two other possible address overflow issues that are difficult to fix:

java.util.zip.CRC32C::updateBytes
jdk.internal.util.ArraysSupport::mismatch

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469804720

From pminborg at openjdk.org  Tue Nov 12 08:18:31 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 08:18:31 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com>

On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35:

> 33:     public static char getChar(byte[] val, int index) {
> 34:         return unsafe.getChar(val,
> 35:                 (long) ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L);

This expression already contains `2L` which is a `long`. So, isn't the result of the multiplications of type `long`, and consequently, isn't the entire expression calculated with `long` precision as it is?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837653228

From swen at openjdk.org  Tue Nov 12 08:26:44 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 08:26:44 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v2]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <qgHai7eV85bqeSjvXJKESE_DxTra7VyA4mcOkE3GKmU=.14febcfe-281b-40ec-b91c-d02e1da9ed41@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  revert, from @minborg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/8087831c..b9294369

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From swen at openjdk.org  Tue Nov 12 08:26:46 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 08:26:46 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v2]
In-Reply-To: <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <9K4lLRbHYMRCcy1Q0c6ADdAPVJyiQDwxJ41LeubLMqo=.89dd5f07-b921-49bc-a528-aa17c72b3d8a@github.com>
Message-ID: <SH0n4NOq6honMDzHgKibB892wJhYWSL7J4tzrs9GfBY=.5a954b9b-8c8f-4d83-83e8-b3b594fb493c@github.com>

On Tue, 12 Nov 2024 08:15:33 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   revert, from @minborg
>
> src/java.base/share/classes/sun/nio/cs/StringUTF16.java line 35:
> 
>> 33:     public static char getChar(byte[] val, int index) {
>> 34:         return unsafe.getChar(val,
>> 35:                 (long) ARRAY_BYTE_BASE_OFFSET + ARRAY_BYTE_INDEX_SCALE * index * 2L);
> 
> This expression already contains `2L` which is a `long`. So, isn't the result of the multiplications of type `long`, and consequently, isn't the entire expression calculated with `long` precision as it is?

You are right, there is no need to add an explicit type conversion here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837663142

From pminborg at openjdk.org  Tue Nov 12 08:47:48 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 08:47:48 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v2]
In-Reply-To: <qgHai7eV85bqeSjvXJKESE_DxTra7VyA4mcOkE3GKmU=.14febcfe-281b-40ec-b91c-d02e1da9ed41@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <qgHai7eV85bqeSjvXJKESE_DxTra7VyA4mcOkE3GKmU=.14febcfe-281b-40ec-b91c-d02e1da9ed41@github.com>
Message-ID: <_prE4LHsGuZK3LlsVUCgGOCjPIlLQ8XRfgZG37p9LGo=.32f61ce8-642f-46d9-b597-d4bcc1118ed9@github.com>

On Tue, 12 Nov 2024 08:26:44 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   revert, from @minborg

It would be good to add some tests to ensure `long` precision is used.

src/jdk.hotspot.agent/share/classes/sun/jvm/hotspot/utilities/HeapHprofBinWriter.java line 1006:

> 1004:     }
> 1005: 
> 1006:     private void writeBooleanArray(TypeArray array, int length) throws IOException {

Note that the copyright year needs updating.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/ByteVector.java line 4104:

> 4102:     @ForceInline
> 4103:     static long byteArrayAddress(byte[] a, int index) {
> 4104:         return (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index;

These classes are generated via the `X-Vector.java.template` in the `java.incubator.vector` package.  So, you only need to change one file here.

![image](https://github.com/user-attachments/assets/2dbda48c-ae17-4809-a46f-62065ee9eab3)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469916847
PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837687593
PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837685399

From duke at openjdk.org  Tue Nov 12 08:56:23 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 12 Nov 2024 08:56:23 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes [v2]
In-Reply-To: <KidZ040zqUD0-BDCiIjzgZKviUJFZQY4Cu4M7g32mBE=.ea8b28c4-81bd-4f7d-9219-9ca0c054e76d@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>
 <KidZ040zqUD0-BDCiIjzgZKviUJFZQY4Cu4M7g32mBE=.ea8b28c4-81bd-4f7d-9219-9ca0c054e76d@github.com>
Message-ID: <trzOd6Q1iZYvCHwIXgQpDfzJitDa93iBdtB0e9h4UsA=.592432f3-c01c-4b80-b5a9-9bc83e314938@github.com>

On Mon, 11 Nov 2024 17:23:56 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

>> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Add mixed test
>>  - Merge branch 'master' into ms-fill-bench-sizes
>>  - Use static arrays
>>  - Revert changes from other branch
>>  - Add benchmark
>>  - Add benchmarks
>
> IIUC, this benchmark is designed to test what happens in the case where a bulk operation is executed on a segment whose type is not known e.g. through type profiling (e.g. polluted case). Note that in this case (MIXED) the fact that we can't rely on which segment it is (and hence on whether it has a certain scope or not, and what the base object is) would greatly dominate the cost of branch misprediction, which I saw mentioned here. In extreme cases of profile pollution it is very possible for a method to be optimized under the assumption that e.g. the method is always executed on off-heap segments, and then hit an on-heap segment, which will perform horribly.
> 
> We have test cases such as these in `LoopOverPolluted[Segments/Buffer]`. It makes sense to test something similar for bulk access too.

@mcimadamore I've added a suggestion (at https://github.com/openjdk/jdk/pull/22010#discussion_r1836806492) on how to make sure that the type profile is polluted and shared by all the `fill` invocations (although only perfasm + perfnorm or TypeProfile logging will tell us if it has worked as expected) - sadly I had to rely on DONTINLINE :"( 
Said that, resetting the "inlining budget"  with a not inlined frame is still brittle and should be verified by adding profiling or printinlining inspection (or just perfasm, searching for callq/call, manually)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2469936358

From swen at openjdk.org  Tue Nov 12 08:59:30 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 08:59:30 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v3]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  from @minborg

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/b9294369..c719c7d1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=01-02

  Stats: 8 lines in 8 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From alanb at openjdk.org  Tue Nov 12 09:06:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 09:06:30 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v3]
In-Reply-To: <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
Message-ID: <EqegOGMDco6H1rHwIzD5VMscYRKNfmI97cgGk5-kBHs=.56f471bf-0d27-4023-bfc4-a0b366664449@github.com>

On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @minborg

src/java.base/share/classes/java/lang/StringLatin1.java line 836:

> 834:         UNSAFE.putByte(val, address    , (byte)(c1));
> 835:         UNSAFE.putByte(val, address + 1, (byte)(c2));
> 836:         UNSAFE.putByte(val, address + 2, (byte)(c3));

While you are here, I wonder if this should be renamed to offset to make it clearer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1837720784

From pminborg at openjdk.org  Tue Nov 12 09:12:05 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 09:12:05 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v3]
In-Reply-To: <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <zlbkB5MLihzlX6Yinqbugo2mj3c__KaC96RdPZ3Pppk=.066e19f0-57d9-4ccd-8432-796bd4160c6a@github.com>
Message-ID: <RQC57LlR6hYt0xtByw8ExA7DcJLMYFAKSfRT4TYXCoc=.fcbbaa7b-793a-4058-a192-6292527d01c2@github.com>

On Tue, 12 Nov 2024 08:59:30 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   from @minborg

The generation of Java files works a bit differently from other places in the JDK (e.g. NIO). Now that the template has been changed, you also need to manually run the script `gen-src.sh` in order to regenerate the classes. So, they will then show up like they did in an earlier commit but share a single source of truth.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2469971317

From sgehwolf at openjdk.org  Tue Nov 12 09:37:12 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 09:37:12 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <P4oda35gwgw-76EC-1VxU9Bpaen7hylVFwf5BEynroY=.d7658a3e-ec22-43cc-b419-91ee62f71397@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <bBVzzCrsP8nVqUByNn81U6OJ5MkQuaCw-BlHsvJ2SMk=.ee20c671-08a3-4e1e-97af-da321d50ce76@github.com>
 <P4oda35gwgw-76EC-1VxU9Bpaen7hylVFwf5BEynroY=.d7658a3e-ec22-43cc-b419-91ee62f71397@github.com>
Message-ID: <yLiMe2CJsd6KN-d2CpEiyJReXxCQz7Mh1XpA7Bg1Wt4=.c287092b-8570-4ede-9f48-fad96eb84e61@github.com>

On Mon, 11 Nov 2024 18:28:11 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> > So on cg v1 you start out and end with a `subsystem_path() == null` and on cg v2 you start out and end with a `subsystem_path() == /../../../../../../test`. In both cases the memory limit of 400m won't be detected.
> 
> Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry.

The bug suggests it's a cg v1 only problem, but I'm able to reproduce in cg v2 too. We should handle both cases more gracefully.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2470033800

From swen at openjdk.org  Tue Nov 12 09:55:17 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 09:55:17 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v4]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <1bBT7IyN6vjZdTpD2gEs-yLSrR-QnRDabKs9TeQmcSs=.c9b61faf-0606-439e-b6de-1186c21d2b4f@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with two additional commits since the last revision:

 - re gen-src
 - rename address to offset, from @AlanBateman

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/c719c7d1..4e007699

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=02-03

  Stats: 11 lines in 7 files changed: 0 ins; 0 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From epeter at openjdk.org  Tue Nov 12 10:07:25 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 12 Nov 2024 10:07:25 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes
In-Reply-To: <dTZCfuCQ_r9UKBOZ7Vk-43OyCSxV2_OdSzdVWreD-ok=.2219f126-4941-4ae9-b438-a56bd886cf00@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <W7euqwoe20eli8vDQajFmYSC_fh6iJdNn643TsVPMYQ=.e892d5ff-d1e2-4749-ae33-41aa8191d0c1@github.com>
 <dTZCfuCQ_r9UKBOZ7Vk-43OyCSxV2_OdSzdVWreD-ok=.2219f126-4941-4ae9-b438-a56bd886cf00@github.com>
Message-ID: <IFiH8Qsk8kBvBon_mr1zdLhsGUwh6t8BODyeIPDX-XY=.9c53463d-d6e8-4512-bab1-f45ec1c23407@github.com>

On Mon, 11 Nov 2024 14:51:06 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> Thanks @minborg for this :) Please remember to add the misprediction count if you can and avoid the bulk methods by having a `nextMemorySegment()` benchmark method which make a single fill call site to observe the different segments (types).
>> 
>> Having separate call-sites which observe always the same type(s) "could" be too lucky (and gentle) for the runtime (and CHA) and would favour to have a single address entry (or few ones, if we include any optimization for the fill size) in the Branch Target Buffer of the cpu.
>
>> Thanks @minborg for this :) Please remember to add the misprediction count if you can and avoid the bulk methods by having a `nextMemorySegment()` benchmark method which make a single fill call site to observe the different segments (types).
>> 
>> Having separate call-sites which observe always the same type(s) "could" be too lucky (and gentle) for the runtime (and CHA) and would favour to have a single address entry (or few ones, if we include any optimization for the fill size) in the Branch Target Buffer of the cpu.
> 
> I've added a "mixed" benchmark. I am not sure I understood all of your comments but given my changes, maybe you could elaborate a bit more?

@minborg sent me some logs from his machine, and I'm analyzing them now.

Basically, I'm trying to see why your Java code is a bit faster than the Loop code.

----------------

  44.77%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
  24.43%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
  21.80%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946

There seem to be 3 hot regions.

**main-loop** (region has 44.77%):

             ;; B33: #  out( B33 B34 ) &lt;- in( B32 B33 ) Loop( B33-B33 inner main of N116 strip mined) Freq: 4.62951e+10                                                          
   0.50%  ?   0x00000001149a23c0:   sxtw        x20, w4                                                                                                                             
          ?   0x00000001149a23c4:   add x22, x16, x20                                                                                                                               
   0.02%  ?   0x00000001149a23c8:   str q16, [x22]                                                                                                                                  
  16.33%  ?   0x00000001149a23cc:   str q16, [x22, #16]             ;*invokevirtual putByte {reexecute=0 rethrow=0 return_oop=0}                                                    
          ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putByteInternal at 15 (line 534)                                     
          ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putByte at 6 (line 522)                                              
          ?                                                             ; - java.lang.invoke.VarHandleSegmentAsBytes::set at 38 (line 114)                                             
          ?                                                             ; - java.lang.invoke.LambdaForm$DMH/0x000000013a4d5800::invokeStatic at 20                                     
          ?                                                             ; - java.lang.invoke.LambdaForm$MH/0x000000013a4d8070::invoke at 37                                            
          ?                                                             ; - java.lang.invoke.VarHandleGuards::guard_LJI_V at 134 (line 1017)                                           
          ?                                                             ; - jdk.internal.foreign.AbstractMemorySegmentImpl::set at 10 (line 670)                                       
          ?                                                             ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 44 (line 101)            
          ?   0x00000001149a23d0:   add w4, w4, #0x20                                                                                                                               
   0.06%  ?   0x00000001149a23d4:   cmp w4, w10                                                                                                                                     
          ?   0x00000001149a23d8:   b.lt        0x00000001149a23c0  // b.tstop;*ifge {reexecute=0 rethrow=0 return_oop=0}


**post-loops**: the "vectorized post-loop" and the "single iteration post-loop" (region has 24.43%):
vectorized post-loop (inner post)

             ?   ? ;; B14: #    out( B14 B15 ) &lt;- in( B35 B14 ) Loop( B14-B14 inner post of N1915) Freq: 174420
   2.20%     ??  ?  0x00000001149a224c:   sxtw  x5, w4
   0.88%     ??  ?  0x00000001149a2250:   str   q16, [x16, x5]              ;*invokevirtual putByte {reexecute=0 rethrow=0 return_oop=0}
             ??  ?                                                            ; - jdk.internal.misc.ScopedMemoryAccess::putByteInternal at 15 (line 534)
             ??  ?                                                            ; - jdk.internal.misc.ScopedMemoryAccess::putByte at 6 (line 522)
             ??  ?                                                            ; - java.lang.invoke.VarHandleSegmentAsBytes::set at 38 (line 114)
             ??  ?                                                            ; - java.lang.invoke.LambdaForm$DMH/0x000000013a4d5800::invokeStatic at 20
             ??  ?                                                            ; - java.lang.invoke.LambdaForm$MH/0x000000013a4d8070::invoke at 37
             ??  ?                                                            ; - java.lang.invoke.VarHandleGuards::guard_LJI_V at 134 (line 1017)
             ??  ?                                                            ; - jdk.internal.foreign.AbstractMemorySegmentImpl::set at 10 (line 670)
             ??  ?                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 44 (line 101)
             ??  ?  0x00000001149a2254:   add   w4, w4, #0x10
             ??  ?  0x00000001149a2258:   cmp   w4, w10
             ??  ?  0x00000001149a225c:   b.lt  0x00000001149a224c  // b.tstop;*ifge {reexecute=0 rethrow=0 return_oop=0}
             ?   ?                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 33 (line 100)
             ?   ? ;; B15: #    out( B16 ) &lt;- in( B14 )  Freq: 87210.2
   0.34%     ?   ?  0x00000001149a2260:   add   x10, x19, x5
             ?   ?  0x00000001149a2264:   add   x22, x10, #0x10             ;*ladd {reexecute=0 rethrow=0 return_oop=0}
             ?   ?                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 52 (line 100)
             ?   ? ;; B16: #    out( B20 B17 ) &lt;- in( B39 B15 B36 ) top-of-loop Freq: 174421
   0.78%     ?   ?  0x00000001149a2268:   cmp   w4, w3
             ? ? ?  0x00000001149a226c:   b.ge  0x00000001149a2294  // b.tcont
             ? ? ? ;; B17: #    out( B42 B18 ) &lt;- in( B16 )  Freq: 87210.3
             ? ? ?  0x00000001149a2270:   cmp   w4, w2
             ? ? ?  0x00000001149a2274:   b.cs  0x00000001149a24a4  // b.hs, b.nlast
             ? ? ?                                                            ;*aload {reexecute=0 rethrow=0 return_oop=0}
             ? ? ?                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 36 (line 101)

scalar post loop:

             ? ? ? ;; B18: #    out( B18 B19 ) &lt;- in( B17 B18 ) Loop( B18-B18 inner post of N1402) Freq: 174420
   0.56%     ? ???  0x00000001149a2278:   sxtw  x10, w4
   5.47%     ? ???  0x00000001149a227c:   strb  wzr, [x16, x10, lsl #0]     ;*invokevirtual putByte {reexecute=0 rethrow=0 return_oop=0}
             ? ???                                                            ; - jdk.internal.misc.ScopedMemoryAccess::putByteInternal at 15 (line 534)
             ? ???                                                            ; - jdk.internal.misc.ScopedMemoryAccess::putByte at 6 (line 522)
             ? ???                                                            ; - java.lang.invoke.VarHandleSegmentAsBytes::set at 38 (line 114)
             ? ???                                                            ; - java.lang.invoke.LambdaForm$DMH/0x000000013a4d5800::invokeStatic at 20
             ? ???                                                            ; - java.lang.invoke.LambdaForm$MH/0x000000013a4d8070::invoke at 37
             ? ???                                                            ; - java.lang.invoke.VarHandleGuards::guard_LJI_V at 134 (line 1017)
             ? ???                                                            ; - jdk.internal.foreign.AbstractMemorySegmentImpl::set at 10 (line 670)
             ? ???                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 44 (line 101)
             ? ???  0x00000001149a2280:   add   w4, w4, #0x1
             ? ???  0x00000001149a2284:   cmp   w4, w3
             ? ???  0x00000001149a2288:   b.lt  0x00000001149a2278  // b.tstop

Not sure why we have this below... probably the check that leads to the post-loop?

             ? ? ? ;; B19: #    out( B20 ) &lt;- in( B18 )  Freq: 87210.2
   8.88%     ? ? ?  0x00000001149a228c:   add   x10, x10, x19
             ? ? ?  0x00000001149a2290:   add   x22, x10, #0x1              ;*ifge {reexecute=0 rethrow=0 return_oop=0}
             ? ? ?                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 33 (line 100)
             ? ? ? ;; B20: #    out( B2 B21 ) &lt;- in( B23 B19 B16 )  Freq: 174760
   0.78%     ? ? ?  0x00000001149a2294:   cmp   x22, x7
             ?   ?  0x00000001149a2298:   b.ge  0x00000001149a219c  // b.tcont


**pre-loop** (region has 21.80%):

             ;; B27: #  out( B29 B28 ) &lt;- in( B26 B28 ) Loop( B27-B28 inner pre of N1402) Freq: 348842
   0.10%   ?  0x00000001149a2364:   sxtw        x22, w10
   6.01%   ?  0x00000001149a2368:   strb        wzr, [x16, x22, lsl #0]     ;*invokevirtual putByte {reexecute=0 rethrow=0 return_oop=0}
           ?                                                            ; - jdk.internal.misc.ScopedMemoryAccess::putByteInternal at 15 (line 534)
           ?                                                            ; - jdk.internal.misc.ScopedMemoryAccess::putByte at 6 (line 522)
           ?                                                            ; - java.lang.invoke.VarHandleSegmentAsBytes::set at 38 (line 114)
           ?                                                            ; - java.lang.invoke.LambdaForm$DMH/0x000000013a4d5800::invokeStatic at 20
           ?                                                            ; - java.lang.invoke.LambdaForm$MH/0x000000013a4d8070::invoke at 37
           ?                                                            ; - java.lang.invoke.VarHandleGuards::guard_LJI_V at 134 (line 1017)
           ?                                                            ; - jdk.internal.foreign.AbstractMemorySegmentImpl::set at 10 (line 670)
           ?                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 44 (line 101)
   0.08%   ?  0x00000001149a236c:   add w4, w10, #0x1
   0.56%   ?  0x00000001149a2370:   cmp w4, w20
   0.04%  ??  0x00000001149a2374:   b.ge        0x00000001149a2380  // b.tcont;*ifge {reexecute=0 rethrow=0 return_oop=0}
          ??                                                            ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop at 33 (line 100)
          ?? ;; B28: #  out( B27 ) &lt;- in( B27 )  Freq: 174421
   5.61%  ??  0x00000001149a2378:   mov w10, w4
          ??  0x00000001149a237c:   b   0x00000001149a2364

with a strange extra add that has some strange looking percentage (profile inaccuracy?):

   7.88%  ?   0x00000001149a2380:   add w10, w10, #0x20


**Summary**:

pre-loop:             22%, byte-store
main-loop:            40%  2x 16-byte-vector-store (profiling is a bit contradictory here - is it 16% or 44%?)
vectorized post-loop: 4%   1x 16-byte-vector-store (not super sure about profiling, but could be accurate)
post-loop:            12%  byte-store

The numbers don't quite add up - but they are still somewhat telling - and I think probably accurate enough to see what happens.

Basically: we waste a lot of time in the pre and post-loop: getting alignment and then finishing off at the end.

-------------------

And to compare:

  58.00%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava, version 5, compile id 848
  29.83%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava, version 5, compile id 848

We have 2 hot regions.

**main** (58%):

             ;; B40: #  out( B40 B41 ) &lt;- in( B39 B40 ) Loop( B40-B40 inner main of N140 strip mined) Freq: 2.13696e+08
   0.26%  ?   0x000000011800f900:   add x4, x1, w3, sxtw
          ?  ;; merged str pair
          ?   0x000000011800f904:   stp xzr, xzr, [x4]
          ?   0x000000011800f908:   str xzr, [x4, #16]              ;*invokevirtual putLongUnaligned {reexecute=0 rethrow=0 return_oop=0}
          ?                                                             ; - jdk.internal.misc.Unsafe::putLongUnaligned at 10 (line 3677)
          ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putLongUnalignedInternal at 17 (line 2605)
          ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putLongUnaligned at 8 (line 2593)
          ?                                                             ; - jdk.internal.foreign.SegmentBulkOperations::fill at 133 (line 78)
          ?                                                             ; - jdk.internal.foreign.AbstractMemorySegmentImpl::fill at 2 (line 184)
          ?                                                             ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava at 14 (line 83)
          ?   0x000000011800f90c:   add w3, w3, #0x20               ;*iinc {reexecute=0 rethrow=0 return_oop=0}
          ?                                                             ; - jdk.internal.foreign.SegmentBulkOperations::fill at 136 (line 77)
          ?                                                             ; - jdk.internal.foreign.AbstractMemorySegmentImpl::fill at 2 (line 184)
          ?                                                             ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava at 14 (line 83)
  21.73%  ?   0x000000011800f910:   str xzr, [x4, #24]              ;*invokevirtual putLongUnaligned {reexecute=0 rethrow=0 return_oop=0}
          ?                                                             ; - jdk.internal.misc.Unsafe::putLongUnaligned at 10 (line 3677)
          ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putLongUnalignedInternal at 17 (line 2605)
          ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putLongUnaligned at 8 (line 2593)
          ?                                                             ; - jdk.internal.foreign.SegmentBulkOperations::fill at 133 (line 78)
          ?                                                             ; - jdk.internal.foreign.AbstractMemorySegmentImpl::fill at 2 (line 184)
          ?                                                             ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava at 14 (line 83)
   0.17%  ?   0x000000011800f914:   cmp w3, w2
   2.58%  ?   0x000000011800f918:   b.lt        0x000000011800f900  // b.tstop;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
                                                                        ; - jdk.internal.foreign.SegmentBulkOperations::fill at 98 (line 77)
                                                                        ; - jdk.internal.foreign.AbstractMemorySegmentImpl::fill at 2 (line 184)
                                                                        ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava at 14 (line 83)
             ;; B41: #  out( B39 B42 ) &lt;- in( B40 )  Freq: 3.29583e+06
  26.13%      0x000000011800f91c:   ldr x2, [x28, #48]              ; ImmutableOopMap {r12=Oop r14=Oop c_rarg1=Derived_oop_r14 r15=Oop r16=Oop }

**Rest**:
vectorized post-loop

                ;; B2: #        out( B2 B3 ) &lt;- in( B42 B2 ) Loop( B2-B2 inner post of N1701) Freq: 50831.6
   3.01%  ?      0x000000011800f728:   str      xzr, [x1, w3, sxtw]         ;*invokevirtual putLongUnaligned {reexecute=0 rethrow=0 return_oop=0}
          ?                                                                ; - jdk.internal.misc.Unsafe::putLongUnaligned at 10 (line 3677)
          ?                                                                ; - jdk.internal.misc.ScopedMemoryAccess::putLongUnalignedInternal at 17 (line 2605)
          ?                                                                ; - jdk.internal.misc.ScopedMemoryAccess::putLongUnaligned at 8 (line 2593)
          ?                                                                ; - jdk.internal.foreign.SegmentBulkOperations::fill at 133 (line 78)
          ?                                                                ; - jdk.internal.foreign.AbstractMemorySegmentImpl::fill at 2 (line 184)
          ?                                                                ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava at 14 (line 83)
          ?      0x000000011800f72c:   add      w3, w3, #0x8                ;*iinc {reexecute=0 rethrow=0 return_oop=0}
          ?                                                                ; - jdk.internal.foreign.SegmentBulkOperations::fill at 136 (line 77)
          ?                                                                ; - jdk.internal.foreign.AbstractMemorySegmentImpl::fill at 2 (line 184)
          ?                                                                ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava at 14 (line 83)
          ?      0x000000011800f730:   cmp      w3, w10
          ?      0x000000011800f734:   b.lt     0x000000011800f728  // b.tstop;*if_icmpge {reexecute=0 rethrow=0 return_oop=0}
                                                                           ; - jdk.internal.foreign.SegmentBulkOperations::fill at 98 (line 77)
                                                                           ; - jdk.internal.foreign.AbstractMemorySegmentImpl::fill at 2 (line 184)
                                                                           ; - org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillJava at 14 (line 83)
                ;; B3: #        out( B5 B4 ) &lt;- in( B2 B43 B44 ) top-of-loop Freq: 51627.8

... and then the rest of the code I speculate is your **long-int-short-byte wind-down code**.

-----------------------

**Conclusion:**

Java: spends about 58% in well vectorized main-loop code (2x super-unrolled, i.e. 2x 16-byte-vectors)
Loop: only spends about 40% in main loop (also 2x 16-byte vectors) - the rest is spent in pre/post-loops


Hmm. This really makes me want to ditch the alignment-code - it may hurt more than we gain from it :thinking: 
And we should also consider such "wind-down" code: going from 16-element vectors to 8, 4, 2, 1 elements. Of course that is extra code and extra compile time...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2470102192

From aboldtch at openjdk.org  Tue Nov 12 10:16:15 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Tue, 12 Nov 2024 10:16:15 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <bpk-IWu7LnUBHxulw1MpQd9rNMI5fdo6AN7TTy4HdQo=.c1821677-7733-42d5-9c08-42979ed5ccaa@github.com>

On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

Marked as reviewed by aboldtch (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21565#pullrequestreview-2429155294

From duke at openjdk.org  Tue Nov 12 10:21:44 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 12 Nov 2024 10:21:44 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes
In-Reply-To: <IFiH8Qsk8kBvBon_mr1zdLhsGUwh6t8BODyeIPDX-XY=.9c53463d-d6e8-4512-bab1-f45ec1c23407@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <W7euqwoe20eli8vDQajFmYSC_fh6iJdNn643TsVPMYQ=.e892d5ff-d1e2-4749-ae33-41aa8191d0c1@github.com>
 <dTZCfuCQ_r9UKBOZ7Vk-43OyCSxV2_OdSzdVWreD-ok=.2219f126-4941-4ae9-b438-a56bd886cf00@github.com>
 <IFiH8Qsk8kBvBon_mr1zdLhsGUwh6t8BODyeIPDX-XY=.9c53463d-d6e8-4512-bab1-f45ec1c23407@github.com>
Message-ID: <m381WCEOX_ncir0r0odlKS54fTP5-5J6-QnMOX8ZDyQ=.2cd821e3-15e3-4299-af2d-707708a625d8@github.com>

On Tue, 12 Nov 2024 10:03:50 GMT, Emanuel Peter <epeter at openjdk.org> wrote:

>>> Thanks @minborg for this :) Please remember to add the misprediction count if you can and avoid the bulk methods by having a `nextMemorySegment()` benchmark method which make a single fill call site to observe the different segments (types).
>>> 
>>> Having separate call-sites which observe always the same type(s) "could" be too lucky (and gentle) for the runtime (and CHA) and would favour to have a single address entry (or few ones, if we include any optimization for the fill size) in the Branch Target Buffer of the cpu.
>> 
>> I've added a "mixed" benchmark. I am not sure I understood all of your comments but given my changes, maybe you could elaborate a bit more?
>
> @minborg sent me some logs from his machine, and I'm analyzing them now.
> 
> Basically, I'm trying to see why your Java code is a bit faster than the Loop code.
> 
> ----------------
> 
>   44.77%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
>   24.43%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
>   21.80%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
> 
> There seem to be 3 hot regions.
> 
> **main-loop** (region has 44.77%):
> 
>              ;; B33: #  out( B33 B34 ) &lt;- in( B32 B33 ) Loop( B33-B33 inner main of N116 strip mined) Freq: 4.62951e+10                                                          
>    0.50%  ?   0x00000001149a23c0:   sxtw        x20, w4                                                                                                                             
>           ?   0x00000001149a23c4:   add x22, x16, x20                                                                                                                               
>    0.02%  ?   0x00000001149a23c8:   str q16, [x22]                                                                                                                                  
>   16.33%  ?   0x00000001149a23cc:   str q16, [x22, #16]             ;*invokevirtual putByte {reexecute=0 rethrow=0 return_oop=0}                                                    
>           ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putByteInternal at 15 (line 534)                                     
>           ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putByte at 6 (line 522)                                              
>           ?                                                             ; - java.lang.invoke.VarHandleSegmentAsBytes::set at 38 (line 114)                                             
>           ?                                                             ; - java.lang.invoke.LambdaForm$DMH/0x000000013a4d5800::invokeStatic at 20                                     
>           ?                                                             ; - java.lang.invoke.LambdaForm$MH/0x000000013a4d8070::invoke at 37                                            
>           ?   ...

@eme64  not an expert with ARM, but profiling skidding due to modern big pipelined OOO CPUs is rather frequent

> with a strange extra add that has some strange looking percentage (profile inaccuracy?):

you should check some instr below it to get the real culprit

More info on this topic are:
- https://travisdowns.github.io/blog/2019/08/20/interrupts.html for x86
- https://easyperf.net/blog/2018/06/08/Advanced-profiling-topics-PEBS-and-LBR#processor-event-based-sampling-pebs
- https://ieeexplore.ieee.org/document/10068807 - Intel and AMD PEBS/IBS paper

If you uses Intel/AMD and PEBS/IBS (if supported by your cpu) you can run perfasm to use precise events via `perfasm:events=cycles:P` IIRC (or adding more Ps? @shipilev likely knows) which should have way less skidding and will simplify these analysis.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2470134089

From epeter at openjdk.org  Tue Nov 12 10:34:31 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 12 Nov 2024 10:34:31 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes
In-Reply-To: <m381WCEOX_ncir0r0odlKS54fTP5-5J6-QnMOX8ZDyQ=.2cd821e3-15e3-4299-af2d-707708a625d8@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <W7euqwoe20eli8vDQajFmYSC_fh6iJdNn643TsVPMYQ=.e892d5ff-d1e2-4749-ae33-41aa8191d0c1@github.com>
 <dTZCfuCQ_r9UKBOZ7Vk-43OyCSxV2_OdSzdVWreD-ok=.2219f126-4941-4ae9-b438-a56bd886cf00@github.com>
 <IFiH8Qsk8kBvBon_mr1zdLhsGUwh6t8BODyeIPDX-XY=.9c53463d-d6e8-4512-bab1-f45ec1c23407@github.com>
 <m381WCEOX_ncir0r0odlKS54fTP5-5J6-QnMOX8ZDyQ=.2cd821e3-15e3-4299-af2d-707708a625d8@github.com>
Message-ID: <uCkBG_lxXi_MniMMrA1svb2SXAal0LtmGAEiku6wcKU=.29a335d8-360c-452a-8347-8e5edc010f05@github.com>

On Tue, 12 Nov 2024 10:17:45 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> @minborg sent me some logs from his machine, and I'm analyzing them now.
>> 
>> Basically, I'm trying to see why your Java code is a bit faster than the Loop code.
>> 
>> ----------------
>> 
>>   44.77%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
>>   24.43%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
>>   21.80%                c2, level 4  org.openjdk.bench.java.lang.foreign.SegmentBulkRandomFill::heapSegmentFillLoop, version 4, compile id 946
>> 
>> There seem to be 3 hot regions.
>> 
>> **main-loop** (region has 44.77%):
>> 
>>              ;; B33: #  out( B33 B34 ) &lt;- in( B32 B33 ) Loop( B33-B33 inner main of N116 strip mined) Freq: 4.62951e+10                                                          
>>    0.50%  ?   0x00000001149a23c0:   sxtw        x20, w4                                                                                                                             
>>           ?   0x00000001149a23c4:   add x22, x16, x20                                                                                                                               
>>    0.02%  ?   0x00000001149a23c8:   str q16, [x22]                                                                                                                                  
>>   16.33%  ?   0x00000001149a23cc:   str q16, [x22, #16]             ;*invokevirtual putByte {reexecute=0 rethrow=0 return_oop=0}                                                    
>>           ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putByteInternal at 15 (line 534)                                     
>>           ?                                                             ; - jdk.internal.misc.ScopedMemoryAccess::putByte at 6 (line 522)                                              
>>           ?                                                             ; - java.lang.invoke.VarHandleSegmentAsBytes::set at 38 (line 114)                                             
>>           ?                                                             ; - java.lang.invoke.LambdaForm$DMH/0x000000013a4d5800::invokeStatic at 20                                     
>>           ?                                                             ; - java.lang.invoke.LambdaForm$MH/0x000000013a4d8070::invoke at 37           ...
>
> @eme64  not an expert with ARM, but profiling skidding due to modern big pipelined OOO CPUs is rather frequent
> 
>> with a strange extra add that has some strange looking percentage (profile inaccuracy?):
> 
> you should check some instr below it to get the real culprit
> 
> More info on this topic are:
> - https://travisdowns.github.io/blog/2019/08/20/interrupts.html for x86
> - https://easyperf.net/blog/2018/06/08/Advanced-profiling-topics-PEBS-and-LBR#processor-event-based-sampling-pebs
> - https://ieeexplore.ieee.org/document/10068807 - Intel and AMD PEBS/IBS paper
> 
> If you uses Intel/AMD and PEBS/IBS (if supported by your cpu) you can run perfasm using precise events via `perfasm:events=cycles:P` IIRC (or adding more Ps? @shipilev likely knows) which should have way less skidding and will simplify these analysis.

@franz1981 right. That is what I thought. I'm usually working on x64, and am not used to all the skidding of ARM.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2470162785

From epeter at openjdk.org  Tue Nov 12 10:34:33 2024
From: epeter at openjdk.org (Emanuel Peter)
Date: Tue, 12 Nov 2024 10:34:33 GMT
Subject: RFR: 8343933: Add a MemorySegment::fill benchmark with varying
 sizes [v2]
In-Reply-To: <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>
References: <5XL0CiRmvkwkI8IIxhu7YIsZbOSkzaTmwEz7eE9dskk=.8b24aba1-fc89-4bfc-b07f-bee8252f680b@github.com>
 <--6e3qPu6Tpi124aWKd3Ug8O35P6N0sqqgjzTcUPekA=.6f6c82b9-7921-494c-a6cc-2272ac90ddcd@github.com>
Message-ID: <YUVydm6G8O7JzkfWHFCW5XJZMeNitIWcDxXVAmHROX8=.7705cc37-822d-4202-b4b2-6c89ce53b0b8@github.com>

On Mon, 11 Nov 2024 14:50:57 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR proposes to add a new `MemorySegment::fill" benchmark where the byte size of the segments varies.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Add mixed test
>  - Merge branch 'master' into ms-fill-bench-sizes
>  - Use static arrays
>  - Revert changes from other branch
>  - Add benchmark
>  - Add benchmarks

But I think the full count is done per block in profiling - and that should be reasonably accurate - though hard to attribute where in the block it came from exactly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22010#issuecomment-2470164128

From sgehwolf at openjdk.org  Tue Nov 12 11:05:34 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 11:05:34 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early
Message-ID: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>

Please review this fix to how patched modules are being handled when linking from the run-time image. During review of [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out that module patching should be detected earlier and the link should get aborted in that case.

This patch implements it, by looking at the `jdk.module.patch.0` property like [other code in the JDK](https://github.com/openjdk/jdk/blob/2c1e4c381615ce52276f4bf331a1e7a845af4b6e/src/hotspot/share/cds/cdsConfig.cpp#L282) does. After this patch module patching is being detected before any archives are being read or the actual linking process starts (contrary to the previous solution).

Testing:
- [x] GHA testing (mac aarch64 test failures are infra related)
- [x] Local testing of existing test, which covers it

Thoughts?

-------------

Commit messages:
 - 8343839: Detect patched modules and abort run-time image link early

Changes: https://git.openjdk.org/jdk/pull/22037/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22037&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343839
  Stats: 23 lines in 7 files changed: 7 ins; 13 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22037/head:pull/22037

PR: https://git.openjdk.org/jdk/pull/22037

From swen at openjdk.org  Tue Nov 12 11:24:24 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 11:24:24 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  rename address to offset, from @AlanBateman

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/4e007699..f8f58546

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=03-04

  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From aturbanov at openjdk.org  Tue Nov 12 11:26:34 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Nov 2024 11:26:34 GMT
Subject: RFR: 8344023: Unnecessary Hashtable usage in
 LdapClient.defaultBinaryAttrs
Message-ID: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>

Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is fully initialized in `<clinit>` block.
It means we can replace legacy synchronized `Hashtable` with immutable set.

-------------

Commit messages:
 - [PATCH] Unnecessary Hashtable usage in LdapClient.defaultBinaryAttrs

Changes: https://git.openjdk.org/jdk/pull/21903/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21903&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344023
  Stats: 29 lines in 1 file changed: 1 ins; 9 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/21903.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21903/head:pull/21903

PR: https://git.openjdk.org/jdk/pull/21903

From alanb at openjdk.org  Tue Nov 12 11:28:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 11:28:43 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early
In-Reply-To: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
Message-ID: <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>

On Tue, 12 Nov 2024 11:00:36 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this fix to how patched modules are being handled when linking from the run-time image. During review of [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out that module patching should be detected earlier and the link should get aborted in that case.
> 
> This patch implements it, by looking at the `jdk.module.patch.0` property like [other code in the JDK](https://github.com/openjdk/jdk/blob/2c1e4c381615ce52276f4bf331a1e7a845af4b6e/src/hotspot/share/cds/cdsConfig.cpp#L282) does. After this patch module patching is being detected before any archives are being read or the actual linking process starts (contrary to the previous solution).
> 
> Testing:
> - [x] GHA testing (mac aarch64 test failures are infra related)
> - [x] Local testing of existing test, which covers it
> 
> Thoughts?

src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625:

> 623:             // Do not permit linking from run-time image when the current image
> 624:             // is being patched
> 625:             if (jdk.internal.misc.VM.getSavedProperties().get("jdk.module.patch.0") != null) {

I don't think we should introduce this dependency. Instead, I think we should look at adding a property such as jdk.patched, with a boolean value, to indicate if the current runtime is patched or not. This could be useful for java -XshowSettings output too.

src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 128:

> 126: \ --keep-packaged-modules is not supported
> 127: err.runtime.link.modified.file={0} has been modified
> 128: err.runtime.link.patched.module=The current runtime includes module patches.\

Not sure about "module patches", its more that the current runtime has been patched with --patch-module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1837935419
PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1837936172

From viktor.klang at oracle.com  Tue Nov 12 11:36:09 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 12 Nov 2024 11:36:09 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
Message-ID: <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>

Have you considered Gatherers.mapConcurrent(?)?


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Tuesday, 12 November 2024 01:53
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Good to know, ty vm.

At the very least, I have this workaround. This will meet my needs for now.

I guess my final question would be -- is this type of problem better suited to something besides parallel streams? Maybe an ExecutorService?

Really, all I am doing is taking a jumbo file, splitting it into batches, and then doing some work on those batches. My IO speeds are pretty fast, and the compute work is non-trivial, so there is performance being left on the table if I give up parallelism. And I am in a position where completion time is very important to us.

I just naturally assumed parallel streams were the right choice because the compute work is simple. A pure function that I can break out, and then call in a map. Once I do that, I just call forEach to write the batches back out to S3. Maybe I should look into a different part of the std lib instead because I am using the wrong tool for the job? My nose says ExecutorService, but I figure I should ask before I dive too deep in.


On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
You're most welcome!

In a potential future where all intermediate operations are Gatherer-based, and all terminal operations are Collector-based, it would just work as expected. But with that said, I'm not sure it is practically achievable because some operations might not have the same performance-characteristics as before.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Monday, 11 November 2024 18:32
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Thanks for the workaround. It's running beautifully.

Is there a future where this island concept is extended to the rest of streams? Tbh, I don't fully understand it.

On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi David,

This is the effect of how parallel streams are implemented, where different stages, which are not representible as a join-less Spliterator are executed as a series of "islands" where the next isn't started until the former has completed.

If you think about it, parallelization of a Stream works best when the entire data set can be split amongst a set of worker threads, and that sort of implies that you want eager pre-fetch of data, so if your dataset does not fit in memory, that is likely to lead to less desirable outcomes.

What I was able to do for Gatherers is to implement "gather(?) + collect(?)"-fusion so any number of consecutive gather(?)-operations immediately followed by a collect(?) is run in the same "island".

So with that said, you could try something like the following:

static <T> Collector<T, ?, Void> forEach(Consumer<? super T> each) {
    return Collector.of(() -> null, (v, e) -> each.accept(e), (l, r) -> l, (v) -> null, Collector.Characteristics.IDENTITY_FINISH);
}


stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.collect(forEach(eachList -> println(eachList.getFirst())));


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Monday, 11 November 2024 14:52
To: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question about Streams, Gatherers, and fetching too many elements

And just to avoid the obvious question, I can hold about 30 batches in memory before the Out of Memory error occurs. So this is not an issue of my batch size being too high.

But just to confirm, I set the batch size to 1, and it still ran into an out of memory error. So I feel fairly confident saying that the Gatherer is trying to grab all available data before sending any of it downstream.

On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Hello Core Libs Dev Team,

I was trying out Gatherers for a project at work, and ran into a rather sad scenario.

I need to process a large file in batches. Each batch is small enough that I can hold it in memory, but I cannot hold the entire file (and thus, all of the batches) in memory at once.

Looking at the Gatherers API, I saw windowFixed and thought that it would be a great match for my use case.

However, when trying it out, I was disappointed to see that it ran out of memory very quickly. Here is my attempt at using it.

stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.forEach(eachList -> println(eachList.getFirst()))
;

As you can see, I am just splitting the file into batches, and printing out the first of each batch. This is purely for example's sake, of course. I had planned on building even more functionality on top of this, but I couldn't even get past this example.

But anyways, not even a single one of them printed out. Which leads me to believe that it's pulling all of them in the Gatherer.

I can get it to run successfully if I go sequentially, but not parallel. Parallel gives me that out of memory error.

Is there any way for me to be able to have the Gatherer NOT pull in everything while still remaining parallel and unordered?

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241112/b5886a8f/attachment-0001.htm>

From pminborg at openjdk.org  Tue Nov 12 11:37:17 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 11:37:17 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <RWhDwE0NcEu8f3DzeNV422vYWAea3tdbO6RfOO4Ymlk=.be849fcc-e951-4c57-9d07-c5388bc57d12@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

LGTM. If there are no additional tests, please label the JBS issue appropriately (i.e `noreg-*`)

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2429343536

From duke at openjdk.org  Tue Nov 12 11:37:19 2024
From: duke at openjdk.org (kabutz)
Date: Tue, 12 Nov 2024 11:37:19 GMT
Subject: Integrated: 8343250: ArrayBlockingQueue serialization not thread safe
In-Reply-To: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
References: <5bMJ9UEN3SiF1LOpmFFWFMNNwv120TlfkFrBkLGSiLw=.6e41cbfc-0a11-4470-9512-616e07b0ddeb@github.com>
Message-ID: <xQMHcy-it7eeaHVfSDqQglCQmSH6_RlF4S6OyPwvMfA=.7968052d-a251-4490-aff6-0451e3731aeb@github.com>

On Wed, 30 Oct 2024 08:54:55 GMT, kabutz <duke at openjdk.org> wrote:

> The ArrayBlockingQueue has had a readObject() method since Java 7, which checks invariants of the deserialized object. However, it does not have a writeObject() method. This means that the ArrayBlockingQueue could be modified whilst it is being written, resulting in broken invariants. The readObject() method's invariant checking is not exhaustive, which means that it is possible to end up with ArrayBlockingQueue instances that contain null values, leading to a difference between "size()" and how many objects would be returned with "poll()".
> 
> The ABQ should get a writeObject() method that is locking on the same locks as the rest of the class.

This pull request has now been integrated.

Changeset: 57292276
Author:    Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
Committer: Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5729227651969f542f040e5d0bfbf9b0b99b5698
Stats:     18 lines in 1 file changed: 18 ins; 0 del; 0 mod

8343250: ArrayBlockingQueue serialization not thread safe

Reviewed-by: rriggs, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21783

From asotona at openjdk.org  Tue Nov 12 12:04:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 12 Nov 2024 12:04:52 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v8]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <dAysFRhzl5k_OY54-VsCdMGAavFsoCYpmrXLPJJeaS4=.2b1021da-f853-49b6-97e3-1d88e41df373@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
   #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
   #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
   #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
   #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
   #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
   #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
   #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
   #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
   #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
   #	src/java.base/share/classes/java/lang/classfile/Instruction.java
   #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/DynamicConstantPoolEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/FieldRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/InterfaceMethodRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/LoadableConstantEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/MethodRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ModuleEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PackageEntry.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/NewMultiArrayInstruction.java
 - Updated copyright years
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
   #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - bumped @since tag
 - 8334714: Class-File API leaves preview

-------------

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=07
  Stats: 800 lines in 165 files changed: 0 ins; 488 del; 312 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

PR: https://git.openjdk.org/jdk/pull/19826

From alanb at openjdk.org  Tue Nov 12 12:13:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 12:13:23 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2429423006

From rgiulietti at openjdk.org  Tue Nov 12 12:14:32 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 12 Nov 2024 12:14:32 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v12]
In-Reply-To: <-Z6SXvJemmUz2irQjJSco1JmpoeUIMf32SBdSNf1n84=.925ac4b7-fb0f-4fd0-b2bf-b345ea31600d@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <-Z6SXvJemmUz2irQjJSco1JmpoeUIMf32SBdSNf1n84=.925ac4b7-fb0f-4fd0-b2bf-b345ea31600d@github.com>
Message-ID: <yk6rtdSZjCwPVmMHk8QepxwXTDBYd_g-Z3CfoUuyWGg=.11451d27-9370-4367-8d0d-6717552f213b@github.com>

On Tue, 12 Nov 2024 05:42:46 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 21 additional commits since the last revision:
> 
>  - Test update and minor bug fix.
>  - Merge branch 'master' into JDK-8341260
>  - Add Float16 -> string conversion from Raffaello.
>  - Merge branch 'master' into JDK-8341260
>  - Merge branch 'master' into JDK-8341260
>  - Respond to review feedback.
>  - Add support for proper String -> Float16 conversion.
>  - Merge branch 'master' into JDK-8341260
>  - Improve specification per code review feedback.
>  - Add tests, improve hashing spec.
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/f3d339e1...8af04c4d

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 242:

> 240:      * The behavior of this class is analogous to {@link
> 241:      * Float#toHexString(float)} except that an exponent value of
> 242:      * {@code "p14"} is used for subnormal {@code Float16} values.

Suggestion:

     * {@code "p-14"} is used for subnormal {@code Float16} values.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 434:

> 432:      */
> 433:     public static Float16 valueOf(String s) throws NumberFormatException {
> 434:         s = s.trim(); // Legacy behavior from analagous methods on

Suggestion:

        s = s.trim(); // Legacy behavior from analogous methods on

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 991:

> 989:      *
> 990:      * The handling of signed zeros, NaNs, infinities, and other
> 991:      * special cases by this method is analagous to the handling of

Suggestion:

     * special cases by this method is analogous to the handling of

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 1013:

> 1011:      *
> 1012:      * The handling of signed zeros, NaNs, infinities, and other
> 1013:      * special cases by this method is analagous to the handling of

Suggestion:

     * special cases by this method is analogous to the handling of

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1837987951
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1837992200
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1837990836
PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1837991474

From swen at openjdk.org  Tue Nov 12 12:20:10 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 12:20:10 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <toDl2zq66ni0iW4AVMTMCNLjRclBgaqs93EvF8BTBKs=.f438c6e5-1c3a-4793-a061-08813ae69c8b@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

I want to add such a test case, but I am worried that it will consume too many resources during the build process.


/**
 * @test
 * @bug 8343984
 * @summary Test that the append capacity is close to Integer.MaxValue
 * @run main/othervm -Xms6g -Xmx6g HugeAppend
 */

public final class HugeAppend {
    public static void main(String[] args) {
        StringBuilder buf = new StringBuilder();
        int loop4 = Integer.MAX_VALUE / 4;
        for (int i = 0; i < loop4; i++) {
            buf.append(true);
        }

        buf.setLength(0);
        int loop5 = Integer.MAX_VALUE / 5;
        for (int i = 0; i < loop5; i++) {
            buf.append(false);
        }
    }
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470377122

From pminborg at openjdk.org  Tue Nov 12 12:20:10 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 12 Nov 2024 12:20:10 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

> I want to add such a test case, but I am worried that it will consume too many resources during the build process.
> 
> ```java
> /**
>  * @test
>  * @bug 8343984
>  * @summary Test that the append capacity is close to Integer.MaxValue
>  * @run main/othervm -Xms6g -Xmx6g HugeAppend
>  */
> 
> public final class HugeAppend {
>     public static void main(String[] args) {
>         StringBuilder buf = new StringBuilder();
>         int loop4 = Integer.MAX_VALUE / 4;
>         for (int i = 0; i < loop4; i++) {
>             buf.append(true);
>         }
> 
>         buf.setLength(0);
>         int loop5 = Integer.MAX_VALUE / 5;
>         for (int i = 0; i < loop5; i++) {
>             buf.append(false);
>         }
>     }
> }
> ```

Yeah. I think it is reasonable to leave out such tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470383131

From rgiulietti at openjdk.org  Tue Nov 12 12:52:21 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 12 Nov 2024 12:52:21 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <FDq3PJ9Vmr03-KIVN8YlWzI4vqgKrH86luWfr-XMQUg=.f66cf820-0233-415c-967d-47395ec16818@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
 <os_i2UbFm71sKzSWTx0Wop4j6YxKKa5SSQonlMfUP1Q=.d56186af-9c2b-4db7-89ec-aee03158f79f@github.com>
 <FDq3PJ9Vmr03-KIVN8YlWzI4vqgKrH86luWfr-XMQUg=.f66cf820-0233-415c-967d-47395ec16818@github.com>
Message-ID: <prIBfV-9SjZpGexOOnhVQ9FicA40RjBigJnT102gkcU=.eaf23bc3-fcef-4b6f-96b7-22840dc5f9e1@github.com>

On Tue, 12 Nov 2024 05:38:23 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 431:
>> 
>>> 429:      * @see    java.lang.Float#valueOf(String)
>>> 430:      */
>>> 431:     public static Float16 valueOf(String s) throws NumberFormatException {
>> 
>> The current implementation throws when the input is `"NaN"`, with or without an optional sign.
>
> Thanks for catching that; fix and tests added in subsequent push.

Single digit inputs, e.g., `Float16.valueOf"2")` throw as well.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1838046684

From mullan at openjdk.org  Tue Nov 12 13:01:33 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 13:01:33 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits:

 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=09
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From asotona at openjdk.org  Tue Nov 12 13:05:42 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 12 Nov 2024 13:05:42 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v7]
In-Reply-To: <doMm2Xlr7u8znabCBkNwAE7ildmYuQyCriNDZLwGZtc=.00a16391-f2a5-43c7-a56d-3158799f13ba@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <9o9mcedTfNNbKd8QvsUVwIFAYC3-y5gPTlGMSYAt4Fk=.ff44e4fb-33d6-404c-8148-21d094f26615@github.com>
 <doMm2Xlr7u8znabCBkNwAE7ildmYuQyCriNDZLwGZtc=.00a16391-f2a5-43c7-a56d-3158799f13ba@github.com>
Message-ID: <0mCmNTLH8wzdrq-q-p790HZXvCaD7gpQkveAfOeCsqk=.4a86b328-842f-4853-8966-e3837f079b9a@github.com>

On Mon, 21 Oct 2024 15:53:18 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java
>>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java
>>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java
>>    #	src/java.base/share/classes/java/lang/classfile/cons...
>
> src/java.base/share/classes/java/lang/classfile/ClassFile.java line 1:
> 
>> 1: /*
> 
> It?should?probably be?possible for?`ClassFile?::verify(?)` to?be?able to?verify the?bytecode of?`java.lang.Object`, `java.lang.Class`, `java.lang.String`, and?`java.lang.Throwable`, as?the?main?reason the?HotSpot?verifier skips?those is?that?there?s circular?verification bootstrap?dependencies between?those, but?the?Class?File API?verifier uses?the?offline `ClassHierarchyResolver`?instead for?determining assignability?checks.
> 
> https://github.com/openjdk/jdk/blob/18bcbf7941f7567449983b3f317401efb3e34d39/src/java.base/share/classes/jdk/internal/classfile/impl/verifier/VerifierImpl.java#L144-L150

VerifierImpl should be the best possible 1:1 transcription of the HotSpot verifier (for easy maintenance). I also have to suppress itching to rewrite it ;) Fortunately why would someone need to verify Object, Class, String or Throwable.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1838065287

From jlahoda at openjdk.org  Tue Nov 12 13:11:52 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Nov 2024 13:11:52 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <_wL5ioaJSVkua-Tt7hgek_mgkW3ZQYYqITkCLJunUaM=.9ebf630c-6d5b-408f-9c9c-7cb22fff1818@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <vuzTesVqSBmTN3Vlx4fwBFLrCsVUd3CXESzvJ70T3QA=.8609d69e-70fa-4ab7-8bba-446f1615f7e3@github.com>
 <_wL5ioaJSVkua-Tt7hgek_mgkW3ZQYYqITkCLJunUaM=.9ebf630c-6d5b-408f-9c9c-7cb22fff1818@github.com>
Message-ID: <X3eBPJicNF2jf_bWT-H2vJIG7LO9dFQtjq8KyB_Uqms=.3ceffefd-2e6f-4add-a776-595c08d04fd6@github.com>

On Mon, 11 Nov 2024 14:25:57 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/LauncherHelper.java line 598:
>> 
>>> 596:     static void printConciseUsageMessage(boolean printToStderr) {
>>> 597:         initOutput(printToStderr);
>>> 598:         ostream.println(SharedSecrets.getJavaLangAccess().shortVersionString());
>> 
>> What is the reason for printing the short version string at the start of the short usage message?
>
> In passing, it may be better to pick "short" or "concise", right now it's a mix in the method and resource keys.

The idea behind printing the short version is to identify what tool is speaking. It can be removed, if desired.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1838074640

From jlahoda at openjdk.org  Tue Nov 12 13:17:13 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Nov 2024 13:17:13 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v8]
In-Reply-To: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
Message-ID: <eIEgRZ2s1iXAt0zCF2uZSnIN8nUIWC1w4GmuXTn5C8s=.efdcdce8-33a3-45f9-8bff-58b512a61826@github.com>

> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
> 
> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
> 
> openjdk 24-internal 2025-03-18
> 
> Usage: java [java options...] <application> [application arguments...]
> 
> Where <application> is one of:
>   <mainclass>                to execute the main method of a compiled class
>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>   -m <module>[/<mainclass>]  to execute the main class of a module
>   <sourcefile>.java          to compile and execute a source-file program
> 
> Where key java options include:
>   --class-path <class path>
>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>   --module-path <module path>
>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
> 
> For additional help on usage:           java --help
> For an interactive Java environment:    jshell
> 
> 
> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
> 
> What do you think?
> 
> Thanks!

Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:

  Reflecting review feedback:
  - using "conciseVersionString" intead of "shortVersionString"
  - using <jarfile>.jar <jarfile>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21411/files
  - new: https://git.openjdk.org/jdk/pull/21411/files/b4d7b493..e9e9ad4b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=06-07

  Stats: 8 lines in 5 files changed: 0 ins; 0 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/21411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21411/head:pull/21411

PR: https://git.openjdk.org/jdk/pull/21411

From jlahoda at openjdk.org  Tue Nov 12 13:23:05 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Nov 2024 13:23:05 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <X3eBPJicNF2jf_bWT-H2vJIG7LO9dFQtjq8KyB_Uqms=.3ceffefd-2e6f-4add-a776-595c08d04fd6@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <vuzTesVqSBmTN3Vlx4fwBFLrCsVUd3CXESzvJ70T3QA=.8609d69e-70fa-4ab7-8bba-446f1615f7e3@github.com>
 <_wL5ioaJSVkua-Tt7hgek_mgkW3ZQYYqITkCLJunUaM=.9ebf630c-6d5b-408f-9c9c-7cb22fff1818@github.com>
 <X3eBPJicNF2jf_bWT-H2vJIG7LO9dFQtjq8KyB_Uqms=.3ceffefd-2e6f-4add-a776-595c08d04fd6@github.com>
Message-ID: <5WLImJZVliyCfPwtyv65k7gGHlMrw2D85MjTvY2erKQ=.f7b61835-fe85-4d7a-8362-405ef09209fd@github.com>

On Tue, 12 Nov 2024 13:09:25 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> In passing, it may be better to pick "short" or "concise", right now it's a mix in the method and resource keys.
>
> The idea behind printing the short version is to identify what tool is speaking. It can be removed, if desired.

`shortVersionString` changed to `conciseVersionString` in:
https://github.com/openjdk/jdk/pull/21411/commits/e9e9ad4bdd0a11244cb1ef84fdeea036e94718c7

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1838087547

From jlahoda at openjdk.org  Tue Nov 12 13:23:09 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Nov 2024 13:23:09 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
Message-ID: <Kz6_ldAA8-ja4XI3g-iRPGYEVTKVxBeJ2MWQNmfiMag=.2974ce91-a0a0-4eb9-a6b5-5caa503797b6@github.com>

On Mon, 11 Nov 2024 14:23:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8340133-2
>>  - Using correct pplaceholders.
>>  - Adjusting text as suggested.
>>  - Cleaning up the concise message:
>>    - using 2 spaces instead of 4,
>>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>>  - Using an enum instead of booleans, as suggested.
>>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>>  - Adjusting the concise help based on review suggestions.
>>  - Cleanup.
>>  - Adjusting/improving the concise help.
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/8eae78c8...b4d7b493
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:
> 
>> 239: \  -jar <jarfile>.jar         to execute the main class of a JAR archive\n\
>> 240: \  -m <module>[/<mainclass>]  to execute the main class of a module\n\
>> 241: \  <sourcefile>.java          to compile and execute a source-file program\n\n\
> 
> I'm not sure about the description of <mainclass>. It uses "compiled class", maybe you meant "compiled main class" or something else to connect it "<mainclass>"?
> 
> "-jar <jarfile>.jar" may be confusing because the "java -help" uses "-java <jarfile">". I think the usages need to be the same.

Used `a compiled main class` and `<jarfile>` (without `.jar`) as suggested in:
https://github.com/openjdk/jdk/pull/21411/commits/e9e9ad4bdd0a11244cb1ef84fdeea036e94718c7

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1838089070

From liach at openjdk.org  Tue Nov 12 13:44:26 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Nov 2024 13:44:26 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v8]
In-Reply-To: <dAysFRhzl5k_OY54-VsCdMGAavFsoCYpmrXLPJJeaS4=.2b1021da-f853-49b6-97e3-1d88e41df373@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <dAysFRhzl5k_OY54-VsCdMGAavFsoCYpmrXLPJJeaS4=.2b1021da-f853-49b6-97e3-1d88e41df373@github.com>
Message-ID: <zE-a5zjlSVA2KDXFqL-_-k_Y5I_EnCXcZRIUZRZ4upA=.a5d62180-10ef-4099-8aa2-febc1443ef6b@github.com>

On Tue, 12 Nov 2024 12:04:52 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
>    #	src/java.base/share/classes/java/lang/classfil...

The latest merge of PreviewFeature.java looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2429630362

From swen at openjdk.org  Tue Nov 12 13:48:35 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 13:48:35 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
Message-ID: <IxQspJjd_7i-U-w_ros1GPC9YVmXJf-hoIXhIM-8ZwQ=.26bc602d-e995-4989-9d92-a7f096bbac25@github.com>

On Tue, 12 Nov 2024 11:24:24 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   rename address to offset, from @AlanBateman

macos-aarch64 build error, I have been encountering this problem for the past two days. How do I solve it?

Run # On macOS we need to install some dependencies for testing
  # On macOS we need to install some dependencies for testing
  brew install make
  sudo xcode-select --switch /Applications/Xcode_14.3.1.app/Contents/Developer
  # This will make GNU make available as 'make' and not only as 'gmake'
  echo '/usr/local/opt/make/libexec/gnubin' >> $GITHUB_PATH
  shell: /bin/bash --noprofile --norc -e -o pipefail {0}
  env:
    MSYS[2](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:2)_PATH_TYPE: minimal
    CHERE_INVOKING: 1
==> Downloading https://ghcr.io/v2/homebrew/core/make/manifests/4.4.1-1
==> Fetching make
==> Downloading https://ghcr.io/v2/homebrew/core/make/blobs/sha256:94[3](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:3)77dc5a364da305c75fd7aa923a[4](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:4)2897993de9edd1eb074428e13c3f2aaf93
==> Pouring make--4.4.1.arm64_sonoma.bottle.1.tar.gz
==> Caveats
GNU "make" has been installed as "gmake".
If you need to use it as "make", you can add a "gnubin" directory
to your PATH from your bashrc like:

    PATH="/opt/homebrew/opt/make/libexec/gnubin:$PATH"
==> Summary
?  /opt/homebrew/Cellar/make/4.4.1: 1[7](https://github.com/wenshao/jdk/actions/runs/11796223660/job/32858583043#step:7:7) files, 1.3MB
xcode-select: error: invalid developer directory '/Applications/Xcode_14.3.1.app/Contents/Developer'
Error: Process completed with exit code 1.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470568595

From ihse at openjdk.org  Tue Nov 12 13:51:58 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Tue, 12 Nov 2024 13:51:58 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
Message-ID: <nA0Jr6c5gyUUFecOiOnCOG6y01YPvwc61mTl-RY2FJs=.ed92ae27-a7f6-4cb6-8100-c404b57b4e76@github.com>

On Mon, 11 Nov 2024 14:23:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8340133-2
>>  - Using correct pplaceholders.
>>  - Adjusting text as suggested.
>>  - Cleaning up the concise message:
>>    - using 2 spaces instead of 4,
>>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>>  - Using an enum instead of booleans, as suggested.
>>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>>  - Adjusting the concise help based on review suggestions.
>>  - Cleanup.
>>  - Adjusting/improving the concise help.
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/59b0cde0...b4d7b493
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:
> 
>> 239: \  -jar <jarfile>.jar         to execute the main class of a JAR archive\n\
>> 240: \  -m <module>[/<mainclass>]  to execute the main class of a module\n\
>> 241: \  <sourcefile>.java          to compile and execute a source-file program\n\n\
> 
> I'm not sure about the description of <mainclass>. It uses "compiled class", maybe you meant "compiled main class" or something else to connect it "<mainclass>"?
> 
> "-jar <jarfile>.jar" may be confusing because the "java -help" uses "-java <jarfile">". I think the usages need to be the same.

@AlanBateman I'd like to respectfully disagree that this was an improvement. If consistency was the important objection here, maybe it would have been better to update "java -help" to include the `.jar`?

In particular, losing the `.java` extension is problematic. I believe that this is essential to the launcher in how it determines if I am trying to launch a class or a source-file program. I just recently tried renaming my `HelloWorld.java` to `HelloWorld.java.old`, but when I ran `java HelloWorld.java.old` I got a warning implying that java thought I was trying to run the class `old` in the package `HelloWorld.java`.

I guess a better solution for the launcher would be to check if the argument given could match an existing text file, even if it looks like a fully qualified class name (but that does not exist). In fact, that might probably be worth a bug report of its own.

But I insist that as long as the current behavior stands, where the trailing `.java` is essential for the launcher to understand that it is launching a source-file program, then the `.java` literal should be a part of the help.

And, for the sake of consistency, that would also imply that the `.jar` suffix should be kept. (I don't know if the launcher would accept like `-jar foo.jar.old`..?)

I still recall how I **struggled** when learning Java that I should do `javac HelloWorld`**`.java`** but not `java HelloWorld`**`.class`**. By explicitly stating `.jar` and `.java` where those are expected, we indirectly underscore the important fact that the class specifications should be made **without** any extension.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1838130624

From vklang at openjdk.org  Tue Nov 12 13:53:22 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Nov 2024 13:53:22 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
Message-ID: <NjR8Ph_wiD7dpYXpf_aZAWwg_8A6EJ5Fhs349qAK5kE=.91e4d7de-0ace-4cf6-847f-5f1b71aa9e72@github.com>

On Mon, 4 Nov 2024 16:14:35 GMT, kabutz <duke at openjdk.org> wrote:

>> Sure, where should I add that test?
>
>> @kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.
> 
> Indeed, I didn't check what happens when we create a spliterator on an empty collection.

@kabutz Let me know how you want to proceed. ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2470581899

From sgehwolf at openjdk.org  Tue Nov 12 13:54:25 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 13:54:25 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early
In-Reply-To: <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
 <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
Message-ID: <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>

On Tue, 12 Nov 2024 11:24:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Instead, I think we should look at adding a property such as jdk.patched

You mean a new standard property - observable with `System.getProperty("jdk.patched")` as well - which would also show up with `java -XshowSettings:properties`? Is that the direction you are envisioning?

> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 128:
> 
>> 126: \ --keep-packaged-modules is not supported
>> 127: err.runtime.link.modified.file={0} has been modified
>> 128: err.runtime.link.patched.module=The current runtime includes module patches.\
> 
> Not sure about "module patches", its more that the current runtime has been patched with --patch-module.

OK.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1838137581
PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1838139017

From alanb at openjdk.org  Tue Nov 12 14:07:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 14:07:53 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
Message-ID: <A0B6qDEx6Ib2WKeIxBs-f9fIGTMedalFjvxCIvXQ74g=.2cb99e10-4e92-4225-bcb3-22273c1106a4@github.com>

On Mon, 11 Nov 2024 14:23:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 11 additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8340133-2
>>  - Using correct pplaceholders.
>>  - Adjusting text as suggested.
>>  - Cleaning up the concise message:
>>    - using 2 spaces instead of 4,
>>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>>  - Using an enum instead of booleans, as suggested.
>>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>>  - Adjusting the concise help based on review suggestions.
>>  - Cleanup.
>>  - Adjusting/improving the concise help.
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/d7e57952...b4d7b493
>
> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:
> 
>> 239: \  -jar <jarfile>.jar         to execute the main class of a JAR archive\n\
>> 240: \  -m <module>[/<mainclass>]  to execute the main class of a module\n\
>> 241: \  <sourcefile>.java          to compile and execute a source-file program\n\n\
> 
> I'm not sure about the description of <mainclass>. It uses "compiled class", maybe you meant "compiled main class" or something else to connect it "<mainclass>"?
> 
> "-jar <jarfile>.jar" may be confusing because the "java -help" uses "-java <jarfile">". I think the usages need to be the same.

> @AlanBateman I'd like to respectfully disagree that this was an improvement. If consistency was the important objection here, maybe it would have been better to update "java -help" to include the .jar?

I assume your disagreement is with Jan's latest update rather than my comment. My comment was just pointing out that it's confusing to use `-jar <jarfile>.jar` in one case and `-jar <jarfile>` in the other.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1838159799

From davidalayachew at gmail.com  Tue Nov 12 14:08:35 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 12 Nov 2024 09:08:35 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>

Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
as I thought of it.


I hand-waved away the idea because I thought that the method would turn the
stream pipeline parallel, thus, recreating the same problem I currently
have of parallelism causing all of the elements to be fetched ahead of
time, causing an OOME.


It did NOT occur to me that the pipeline would stay sequential, and just
kick these off sequentially, but have them executing in parallel. I can't
see why I came to that incorrect conclusion. I have read the javadocs of
this method several times. Though, to be fair, I came to the same,
incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
until someone pointed out what the documentation was actually saying that I
realized it's true properties.

Thanks. That definitely solves at least part of my problem. Obviously, I
would prefer to write to S3 in parallel too, but at the very least, the
calculation part is being done in parallel. And worst case scenario, I can
be really bad and just do the write to S3 in the mapConcurrent, and then
just return the metadata of each write, and just bundle that up with
collect.


And that's ignoring the fact that I can just use the workaround too.


Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
from a performance perspective, but is rather unintuitive to me from a
usability perspective. We are told how Streams can process unbounded data
sets, but when it tries to do a findAny() with parallel(), it runs into an
OOME because it fetched all the data ahead of time. In fact, almost of the
terminal operations will hit an OOME in the exact same way if they are
parallel and have a big enough data set. It's definitely not the end of the
world, but it seems that I have to fit everything into a Collector and/or a
Gatherer if I want to avoid pre-fetching everything.

On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Have you considered Gatherers.mapConcurrent(?)?
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Tuesday, 12 November 2024 01:53
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> Good to know, ty vm.
>
> At the very least, I have this workaround. This will meet my needs for now.
>
> I guess my final question would be -- is this type of problem better
> suited to something besides parallel streams? Maybe an ExecutorService?
>
> Really, all I am doing is taking a jumbo file, splitting it into batches,
> and then doing some work on those batches. My IO speeds are pretty fast,
> and the compute work is non-trivial, so there is performance being left on
> the table if I give up parallelism. And I am in a position where completion
> time is very important to us.
>
> I just naturally assumed parallel streams were the right choice because
> the compute work is simple. A pure function that I can break out, and then
> call in a map. Once I do that, I just call forEach to write the batches
> back out to S3. Maybe I should look into a different part of the std lib
> instead because I am using the wrong tool for the job? My nose says
> ExecutorService, but I figure I should ask before I dive too deep in.
>
>
> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> You're most welcome!
>
> In a potential future where all intermediate operations are
> Gatherer-based, and all terminal operations are Collector-based, it would
> just work as expected. But with that said, I'm not sure it is practically
> achievable because some operations might not have the same
> performance-characteristics as before.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 18:32
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Thanks for the workaround. It's running beautifully.
>
> Is there a future where this island concept is extended to the rest of
> streams? Tbh, I don't fully understand it.
>
> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi David,
>
> This is the effect of how parallel streams are implemented, where
> different stages, which are not representible as a join-less Spliterator
> are executed as a series of "islands" where the next isn't started until
> the former has completed.
>
> If you think about it, parallelization of a Stream works best when the
> entire data set can be split amongst a set of worker threads, and that sort
> of implies that you want eager pre-fetch of data, so if your dataset does
> not fit in memory, that is likely to lead to less desirable outcomes.
>
> What I was able to do for Gatherers is to implement "gather(?) +
> collect(?)"-fusion so any number of consecutive gather(?)-operations
> immediately followed by a collect(?) is run in the same "island".
>
> So with that said, you could try something like the following:
>
> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>     *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> }
>
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .collect(forEach(eachList -> println(eachList.getFirst())));
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 14:52
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> elements
>
> And just to avoid the obvious question, I can hold about 30 batches in
> memory before the Out of Memory error occurs. So this is not an issue of my
> batch size being too high.
>
> But just to confirm, I set the batch size to 1, and it still ran into an
> out of memory error. So I feel fairly confident saying that the Gatherer is
> trying to grab all available data before sending any of it downstream.
>
> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Core Libs Dev Team,
>
> I was trying out Gatherers for a project at work, and ran into a rather
> sad scenario.
>
> I need to process a large file in batches. Each batch is small enough that
> I can hold it in memory, but I cannot hold the entire file (and thus, all
> of the batches) in memory at once.
>
> Looking at the Gatherers API, I saw windowFixed and thought that it would
> be a great match for my use case.
>
> However, when trying it out, I was disappointed to see that it ran out of
> memory very quickly. Here is my attempt at using it.
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .forEach(eachList -> println(eachList.getFirst()))
> ;
>
> As you can see, I am just splitting the file into batches, and printing
> out the first of each batch. This is purely for example's sake, of course.
> I had planned on building even more functionality on top of this, but I
> couldn't even get past this example.
>
> But anyways, not even a single one of them printed out. Which leads me to
> believe that it's pulling all of them in the Gatherer.
>
> I can get it to run successfully if I go sequentially, but not parallel.
> Parallel gives me that out of memory error.
>
> Is there any way for me to be able to have the Gatherer NOT pull in
> everything while still remaining parallel and unordered?
>
> Thank you for your time and help.
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241112/f2542012/attachment-0001.htm>

From liach at openjdk.org  Tue Nov 12 14:17:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Nov 2024 14:17:27 GMT
Subject: RFR: 8162500: Receiver annotations of inner classes of local
 classes not found at runtime
In-Reply-To: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
References: <S9HalqsoGigIMj1yak18jq-P9wfRJQmOlGGYmkGP2LE=.afecc1f4-226b-4c7a-aa58-ed540a402c28@github.com>
Message-ID: <9C8zywh6zM7DyUimOzhLYjGkYkEWIS42WLIxG6Ratcg=.b3262bc0-d4e2-46c8-93da-494adc119afd@github.com>

On Tue, 16 Jul 2024 18:02:57 GMT, Chen Liang <liach at openjdk.org> wrote:

> In annotated types, local and inner class types should be annotated as "top-level" types. For example, in the test here
> 
>     public static Class<?> getLocalsMember() {
>         class Local {
>             class Member {
>                 @Annot(2635) Member(@Annot(2732) Local Local.this) {}
>             }
>         }
>         return Local.Member.class;
>     }
> 
> 
> The `Local` occurrences cannot be qualified with the enclosing class type, even if the local class may be compiled to capture the enclosing class.
> 
> However, core reflection had a bug where it looks for an enclosing class instead of a declaring class; this meant that for said `Local`, core reflection was treating the outer class as the top-level in type annotations, while the top level should be the local class instead. This patch fixes this bug.

Keep alive.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20200#issuecomment-2470649028

From kevinw at openjdk.org  Tue Nov 12 14:18:27 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Nov 2024 14:18:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
Message-ID: <k5Fku2GFLG_4KD-l9l4gX4gnu8qrfvtTcWWNxvZQTus=.b710907b-e5a3-4516-bdbf-047a74a5eacd@github.com>

On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429727015

From vklang at openjdk.org  Tue Nov 12 14:18:29 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Nov 2024 14:18:29 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v24]
In-Reply-To: <XvZ2q1QD4p4mN4DLaJZUvt_JVS3EbVSRQU90n9SmPtY=.137be678-a4c6-43d3-baa3-3e33324dd102@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <XvZ2q1QD4p4mN4DLaJZUvt_JVS3EbVSRQU90n9SmPtY=.137be678-a4c6-43d3-baa3-3e33324dd102@github.com>
Message-ID: <NsnmmK9lrbjTuhhZ7vnZvetJZwqF0DJ8bxmfXzBsh8E=.464f9e79-652d-4e11-a33a-9b94f948a846@github.com>

On Mon, 11 Nov 2024 16:39:47 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1870:

> 1868:         else if ((phase = w.phase) != 0 && (phase & IDLE) != 0)
> 1869:             releaseWaiters();              // ensure released
> 1870:         if (w == null || w.source != DROPPED) {

@DougLea If this isn't intended to be an `else-if` I'd recommend adding a line of whitespace between it and the line above.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1877:

> 1875:                                        (LMASK & c)))));
> 1876:         }
> 1877:         if (phase != 0 && w != null && (runState & STOP) == 0L) {

@DougLea If this isn't intended to be an else-if I'd recommend adding a line of whitespace between it and the line above.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1888:

> 1886:             unlockRunState();
> 1887:         }
> 1888:         if ((tryTerminate(false, false) & STOP) == 0L &&

@DougLea If this isn't intended to be an else-if I'd recommend adding a line of whitespace between it and the line above.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1838177673
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1838178044
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1838179809

From swen at openjdk.org  Tue Nov 12 14:22:11 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 14:22:11 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
 <6oLW76lwfUSTt2s40UvAeKqadewY7-_Bl8EoTk9Hkko=.2b081d05-ecbf-4348-8fd2-1151abd8cdb9@github.com>
Message-ID: <GeWLCVVrOttuWEvm0HtRxLT1GKyE7-QK4QOe4jfDeg8=.2494cc13-0aeb-47bc-a473-3f85c0540661@github.com>

On Tue, 12 Nov 2024 12:18:03 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> I want to add such a test case, but I am worried that it will consume too many resources during the build process.
> 
> ```java
> /**
>  * @test
>  * @bug 8343984
>  * @summary Test that the append capacity is close to Integer.MaxValue
>  * @run main/othervm -Xms6g -Xmx6g HugeAppend
>  */
> 
> public final class HugeAppend {
>     public static void main(String[] args) {
>         StringBuilder buf = new StringBuilder();
>         int loop4 = Integer.MAX_VALUE / 4;
>         for (int i = 0; i < loop4; i++) {
>             buf.append(true);
>         }
> 
>         buf.setLength(0);
>         int loop5 = Integer.MAX_VALUE / 5;
>         for (int i = 0; i < loop5; i++) {
>             buf.append(false);
>         }
>     }
> }
> ```

In the master branch, this test will succeed in jtreg

* jtreg

make test TEST="jtreg:test/jdk/java/util/BitSet/HugeToString.java"


* result

==============================
Test summary
==============================
   TEST                                              TOTAL  PASS  FAIL ERROR   
   jtreg:test/jdk/java/util/BitSet/HugeToString.java     1     1     0     0   
==============================
TEST SUCCESS


But running it directly will cause JVM Crash

 ~/git/jdk_x/build/macosx-aarch64-server-release/images/jdk/bin/java -Xms6g -Xmx6g HugeAppend

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470661592

From rriggs at openjdk.org  Tue Nov 12 14:25:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 14:25:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v10]
In-Reply-To: <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <2SGEfFmEGoUI8URR826fqe3BH7gmw9_0sCZpB7pjFtQ=.7ad8ac5d-5654-4518-a584-1fdd27478a5d@github.com>
Message-ID: <T-riVwSNCriZvC4nhb9XDviF7n0SacK4KEJz3f8t2b0=.93469aae-25e3-4e33-9232-7b3337219821@github.com>

On Tue, 12 Nov 2024 13:01:33 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 229 commits:
> 
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - ... and 219 more: https://git.openjdk.org/jdk/compare/2ec35808...b7b95a40

Good to go!

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429741829

From alanb at openjdk.org  Tue Nov 12 14:33:07 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 14:33:07 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early
In-Reply-To: <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
 <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
 <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
Message-ID: <xN7uGi3rA6o-GskzEnRHsyR6iIOplY6lfMi-FIIdjiI=.b61ac634-ceb2-49ec-a7cb-94676afe4aec@github.com>

On Tue, 12 Nov 2024 13:51:17 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/JlinkTask.java line 625:
>> 
>>> 623:             // Do not permit linking from run-time image when the current image
>>> 624:             // is being patched
>>> 625:             if (jdk.internal.misc.VM.getSavedProperties().get("jdk.module.patch.0") != null) {
>> 
>> I don't think we should introduce this dependency. Instead, I think we should look at adding a property such as jdk.patched, with a boolean value, to indicate if the current runtime is patched or not. This could be useful for java -XshowSettings output too.
>
>> Instead, I think we should look at adding a property such as jdk.patched
> 
> You mean a new standard property - observable with `System.getProperty("jdk.patched")` as well - which would also show up with `java -XshowSettings:properties`? Is that the direction you are envisioning?

Yes, I'm wondering if a JDK-specific (rather than standard) property could be more widely useful as it would allow observability tools to know that the JDK has been patched. It would be good to get wider input on this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1838203008

From dfuchs at openjdk.org  Tue Nov 12 14:34:15 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 12 Nov 2024 14:34:15 GMT
Subject: RFR: 8344023: Unnecessary Hashtable usage in
 LdapClient.defaultBinaryAttrs
In-Reply-To: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
References: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
Message-ID: <ZPCxIr4RFyglj75ANTTzApOLM25AUhsLN_0sV_D490A=.554aa687-d0be-448e-90da-b28cc3122163@github.com>

On Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is fully initialized in `<clinit>` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.

Looks worthwhile and reasonable. What tests did you run?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21903#pullrequestreview-2429771866

From sgehwolf at openjdk.org  Tue Nov 12 14:38:22 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 14:38:22 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early
In-Reply-To: <xN7uGi3rA6o-GskzEnRHsyR6iIOplY6lfMi-FIIdjiI=.b61ac634-ceb2-49ec-a7cb-94676afe4aec@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
 <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
 <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
 <xN7uGi3rA6o-GskzEnRHsyR6iIOplY6lfMi-FIIdjiI=.b61ac634-ceb2-49ec-a7cb-94676afe4aec@github.com>
Message-ID: <SVayUy5v_C1hf___r1Gd025k8csoFaWeIlxtjkiEVAg=.6d65e3ae-a7e0-4e93-9606-03a3d213a794@github.com>

On Tue, 12 Nov 2024 14:29:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Instead, I think we should look at adding a property such as jdk.patched
>> 
>> You mean a new standard property - observable with `System.getProperty("jdk.patched")` as well - which would also show up with `java -XshowSettings:properties`? Is that the direction you are envisioning?
>
> Yes, I'm wondering if a JDK-specific (rather than standard) property could be more widely useful as it would allow observability tools to know that the JDK has been patched. It would be good to get wider input on this.

OK, thanks. I'll start a thread on core-libs-dev about this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1838212838

From rriggs at openjdk.org  Tue Nov 12 14:42:06 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 14:42:06 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process and
 java.lang.Runtime.exec
Message-ID: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>

Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.

-------------

Depends on: https://git.openjdk.org/jdk/pull/21498

Commit messages:
 - Simplify the generation of the exception message.
 - Remove security manager impl in java.lang.Process and java.lang.Runtime.exec

Changes: https://git.openjdk.org/jdk/pull/22024/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22024&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343958
  Stats: 166 lines in 5 files changed: 0 ins; 106 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/22024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22024/head:pull/22024

PR: https://git.openjdk.org/jdk/pull/22024

From vklang at openjdk.org  Tue Nov 12 14:44:50 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Nov 2024 14:44:50 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v24]
In-Reply-To: <XvZ2q1QD4p4mN4DLaJZUvt_JVS3EbVSRQU90n9SmPtY=.137be678-a4c6-43d3-baa3-3e33324dd102@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <XvZ2q1QD4p4mN4DLaJZUvt_JVS3EbVSRQU90n9SmPtY=.137be678-a4c6-43d3-baa3-3e33324dd102@github.com>
Message-ID: <rpNe-5W7fgZ0KgVlmSDSNUjozsXZ2mqrQBq5-NUhnh8=.b3b3e01e-527d-4066-b30b-3ce758d34548@github.com>

On Mon, 11 Nov 2024 16:39:47 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Address review comments

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2078:

> 2076:         w.phase = p;
> 2077:         if (!compareAndSetCtl(pc, qc))        // try to enqueue
> 2078:             return w.phase = phase;           // back out on possible signal

@DougLea We don't back out the stackPred change here, is that still valid? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1838226013

From mullan at openjdk.org  Tue Nov 12 14:44:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 14:44:55 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:

 - Merge
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

-------------

Changes: https://git.openjdk.org/jdk/pull/21498/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21498&range=10
  Stats: 68915 lines in 1889 files changed: 2475 ins; 62597 del; 3843 mod
  Patch: https://git.openjdk.org/jdk/pull/21498.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21498/head:pull/21498

PR: https://git.openjdk.org/jdk/pull/21498

From kevinw at openjdk.org  Tue Nov 12 14:48:36 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Tue, 12 Nov 2024 14:48:36 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <qw2I4_NVSBXQhXFeevleFvLgLEvPhUspdKzt2D4vSxo=.4251f226-49c6-450c-95f1-5bbd252554a2@github.com>

On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by kevinw (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429813961

From alanb at openjdk.org  Tue Nov 12 14:53:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 14:53:26 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec
In-Reply-To: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
Message-ID: <c1cKdLsVdx2co3B1wUYoSCQefz9fH_16eep0MTW1gww=.eaa51f37-b4b4-4eed-8858-37bd7f7389c2@github.com>

On Tue, 12 Nov 2024 01:41:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.

src/java.base/share/classes/java/lang/ProcessBuilder.java line 1111:

> 1109:                 + (dir == null ? "" : " (in directory \"" + dir + "\")")
> 1110:                 + e.getMessage(),
> 1111:                 e);

Can you check the format of the exception? It looks like original put ": " before the exception message. With the change it looks like it will immediately follow without spacing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838239493

From rriggs at openjdk.org  Tue Nov 12 14:55:29 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 14:55:29 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <yAGTVrMWpR2BOpXL3-RivxcpB7UUrza89gERwz1BarA=.70d7df81-ea72-4379-848b-6438759d92a3@github.com>

On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429830332

From schernyshev at openjdk.org  Tue Nov 12 15:03:36 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 12 Nov 2024 15:03:36 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <SEqkoSF-Pa3JKDay_7yFrwxbQ_v51Cdn964bvVrGpfY=.e76dc454-0226-4917-9e71-1b8d01b92a8a@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <XgUP3oTSxxBjeS0CJNMhixZP45NYBdsAOepkDuQvhz8=.66911e34-2b98-4e04-a0bc-f4b9ffed6c4b@github.com>
 <f-tvktrcHPdR9Tp1zRrI7rU7VPuQoaZrYKkZKZp0FD0=.185be49b-bba4-40ea-96c3-2cdad18fc06a@github.com>
 <SEqkoSF-Pa3JKDay_7yFrwxbQ_v51Cdn964bvVrGpfY=.e76dc454-0226-4917-9e71-1b8d01b92a8a@github.com>
Message-ID: <Lr-9yFtZLqJHHcItKkdkJq-dylhZ_8KqbKXRNBbpa5g=.a16eb44b-904a-45fe-8896-87a9ce29b7b1@github.com>

On Mon, 11 Nov 2024 10:23:02 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue.

Example for NPE:


public class Test {
    public static void main(String[] args) {
        java.lang.management.ManagementFactory.getPlatformMBeanServer();
        System.out.println("PASSED.");
    }
}

Script (cg v1):

sudo docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --volume=./classes:/classes:ro --memory 400m ubuntu:latest \
    sh -c "sleep 10 ; /jdk/bin/java -cp .:/classes Test" &
sleep 10;
HOSTPID=$(sudo ps -ef | awk '/jdk/bin/java/ && !/docker/ && !/awk/ { print $2 }')
echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs > /dev/null
sleep 10

Result (cg v1 before patch):

Exception in thread "main" java.lang.NullPointerException
	at java.base/java.util.Objects.requireNonNull(Objects.java:220)
	at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:296)
	at java.base/java.nio.file.Path.of(Path.java:148)
	at java.base/java.nio.file.Paths.get(Paths.java:69)
	at java.base/jdk.internal.platform.CgroupUtil.lambda$readStringValue$0(CgroupUtil.java:67)
	at java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
	at java.base/jdk.internal.platform.CgroupUtil.readStringValue(CgroupUtil.java:69)
	at java.base/jdk.internal.platform.CgroupSubsystemController.getStringValue(CgroupSubsystemController.java:65)
	at java.base/jdk.internal.platform.CgroupSubsystemController.getLongValue(CgroupSubsystemController.java:124)
	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getLongValue(CgroupV1Subsystem.java:190)
	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getHierarchical(CgroupV1Subsystem.java:160)
	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.initSubSystem(CgroupV1Subsystem.java:85)
	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getInstance(CgroupV1Subsystem.java:61)
	at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:119)
	at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:89)
	at java.base/jdk.internal.platform.CgroupMetrics.getInstance(CgroupMetrics.java:198)
	at java.base/jdk.internal.platform.SystemMetrics.instance(SystemMetrics.java:29)
	at java.base/jdk.internal.platform.Metrics.systemMetrics(Metrics.java:58)
	at java.base/jdk.internal.platform.Container.metrics(Container.java:43)
	at jdk.management/com.sun.management.internal.OperatingSystemImpl.<init>(OperatingSystemImpl.java:175)
	at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl.getOperatingSystemMXBean(PlatformMBeanProviderImpl.java:316)
	at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl$4.nameToMBeanMap(PlatformMBeanProviderImpl.java:235)
	at java.management/java.lang.management.ManagementFactory.lambda$getPlatformMBeanServer$0(ManagementFactory.java:489)
	at java.base/java.util.stream.ReferencePipeline$7$1FlatMap.accept(ReferencePipeline.java:289)
	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
	at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1788)
	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:636)
	at java.management/java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:490)
	at Test.main(Test.java:3)

After patch:

[0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test]
[0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/]
[0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/]
Nov 12, 2024 1:14:11 PM jdk.internal.platform.cgroupv1.CgroupV1SubsystemController setPath
WARNING: Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test].
PASSED.

In cg v2 the NPE is not observed.


> > Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry.
> 
> The bug suggests it's a cg v1 only problem, but I'm able to reproduce in cg v2 too. We should handle both cases more gracefully.

what gets reproduced in cg v2 is in fact a different issue, the cgroup files are not mapped inside the container.
Nothing can be done in Java to overcome this. There are no files in /sys/fs/cgroup.

The only workaround is --cgroupns=host, then the correct limits are displayed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2470765864

From mullan at openjdk.org  Tue Nov 12 15:05:09 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:09 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
 <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>
Message-ID: <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@github.com>

On Fri, 8 Nov 2024 18:31:13 GMT, Harshitha Onkar <honkar at openjdk.org> wrote:

>> It has a value? when it's mentioned with `@see`, the link is present in the *See Also* section, as you can see in the the specification of [`MouseInfo.getPointerInfo()`](https://docs.oracle.com/en/java/javase/21/docs/api/java.desktop/java/awt/MouseInfo.html#getPointerInfo()).
>> 
>> Without the `@see` tag, one has to read the entire description to find the link.
>> 
>> It looks subtle. We can restore the `@see`-link later if deemed necessary.
>> 
>> Does anyone else have an opinion?
>
> I can add it back if it is more convenient and readable to have the `@see` tag.

This can be taken care of later after integration.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838260852

From mullan at openjdk.org  Tue Nov 12 15:05:14 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:14 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v3]
In-Reply-To: <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
Message-ID: <-KIDgN-bR6eT5GTOj2hiyz0oLJXR7Ewx1taEzXeaRsw=.3d2f141a-8183-4f70-af74-c06b47f29478@github.com>

On Thu, 24 Oct 2024 17:03:25 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 150 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge
>>  - Update @summary to replace "if the right permission is granted" can be replaced with "package java.lang is open to unnamed module".
>>  - Remove println about Security Manager.
>>  - Remove unused static variable NEW_PROXY_IN_PKG.
>>  - Remove static variable `DEFAULT_POLICY` and unused imports.
>>  - Remove hasSM() method and code that calls it, and remove comment about
>>    running test manually with SM.
>>  - clientlibs: import order
>>  - warning-string
>>  - java/net/httpclient/websocket/security/WSURLPermissionTest.java: integrated review feedback in renamed WSSanityTest.java
>>  - ... and 140 more: https://git.openjdk.org/jdk/compare/f7a61fce...cb50dfde
>
> test/jdk/java/beans/Introspector/7084904/Test7084904.java line 31:
> 
>> 29:  * @library ..
>> 30:  * @run main Test7084904
>> 31:  * @author Sergey Malenkov
> 
> The test below `Test4683761.java` removes the `@author` tag. Should it be removed here?

This can be handled later in a more general cleanup task.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838259103

From mullan at openjdk.org  Tue Nov 12 15:05:15 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 15:05:15 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v6]
In-Reply-To: <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <mcc8kgn3jdbDYs3Tjey6zrNyGGLtqyEYW7PJiFEc7gU=.68e483f5-d4b7-49a2-99c9-ba00e648a4dc@github.com>
 <moEZcoiJmzn1gNALg6JLnU2m5GQD2wHAOaCdMX-yPHs=.3ed260f3-b644-4926-9f14-37addc680b65@github.com>
Message-ID: <yml_wtm2Rsmw63hY1b6cxp1EvRCPyJFD7cVRxerdgb4=.6ef7f62e-7ce0-4661-9951-3445f851d94b@github.com>

On Fri, 1 Nov 2024 19:40:03 GMT, Alexey Ivanov <aivanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 200 commits:
>> 
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Modify three RMI tests to work without the security manager:
>>     - test/jdk/java/rmi/registry/classPathCodebase/ClassPathCodebase.java
>>     - test/jdk/java/rmi/registry/readTest/CodebaseTest.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/useCodebaseOnly/UseCodebaseOnly.java
>>    Also remove them from the problem list.
>>  - Remove two obsolete RMI tests:
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/ContextInsulation.java
>>     - test/jdk/sun/rmi/transport/tcp/disableMultiplexing/DisableMultiplexing.java
>>    Adjust two tests to run without the Security Manager:
>>     - test/jdk/java/rmi/server/RMIClassLoader/loadProxyClasses/LoadProxyClasses.java
>>     - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java
>>    Remove all of these tests from the problem list.
>>  - In staticPermissionsOnly(), change "current policy binding" to "current policy" so wording is consistent with the API note that follows.
>>  - Added API Notes to ProtectionDomain clarifying that the current policy always
>>    grants no permissions. A few other small changes to Policy and PD.
>>  - Merge branch 'master' into jep486
>>  - JAXP tests: organize imports of a few tests
>>  - Improve description of Executors.privilegedThreadFactory
>>  - rename TestAppletLoggerContext.java as suggested in util test review
>>  - clientlibs: Javadoc cleanup
>>  - ... and 190 more: https://git.openjdk.org/jdk/compare/158ae51b...7958ee2b
>
> test/jdk/javax/sound/midi/Soundbanks/EmptySoundBankTest.java line 1:
> 
>> 1: /*
> 
> I wonder if we should add an Oracle copyright to the update test file.

I don't think it is necessary for that small of a change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838256317

From viktor.klang at oracle.com  Tue Nov 12 15:06:25 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 12 Nov 2024 15:06:25 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
Message-ID: <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>

>We are told how Streams can process unbounded data sets, but when it tries to do a findAny() with parallel(), it runs into an OOME because it fetched all the data ahead of time. In fact, almost of the terminal operations will hit an OOME in the exact same way if they are parallel and have a big enough data set. It's definitely not the end of the world, but it seems that I have to fit everything into a Collector and/or a Gatherer if I want to avoid pre-fetching everything.

Yeah, I think it is important to distinguish "can process unbounded data sets" from "always able to process unbounded data sets".

Some operations inherently need the end of the stream, so even something somple like: stream.distinct() or stream.sorted() can end up pulling in all data (which of course won't terminate).

Fortunately, I think Gatherers can unlock much more situations where unbounded streams can be processed.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Tuesday, 12 November 2024 15:08
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon as I thought of it.


I hand-waved away the idea because I thought that the method would turn the stream pipeline parallel, thus, recreating the same problem I currently have of parallelism causing all of the elements to be fetched ahead of time, causing an OOME.


It did NOT occur to me that the pipeline would stay sequential, and just kick these off sequentially, but have them executing in parallel. I can't see why I came to that incorrect conclusion. I have read the javadocs of this method several times. Though, to be fair, I came to the same, incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't until someone pointed out what the documentation was actually saying that I realized it's true properties.

Thanks. That definitely solves at least part of my problem. Obviously, I would prefer to write to S3 in parallel too, but at the very least, the calculation part is being done in parallel. And worst case scenario, I can be really bad and just do the write to S3 in the mapConcurrent, and then just return the metadata of each write, and just bundle that up with collect.


And that's ignoring the fact that I can just use the workaround too.


Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me from a performance perspective, but is rather unintuitive to me from a usability perspective. We are told how Streams can process unbounded data sets, but when it tries to do a findAny() with parallel(), it runs into an OOME because it fetched all the data ahead of time. In fact, almost of the terminal operations will hit an OOME in the exact same way if they are parallel and have a big enough data set. It's definitely not the end of the world, but it seems that I have to fit everything into a Collector and/or a Gatherer if I want to avoid pre-fetching everything.

On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Have you considered Gatherers.mapConcurrent(?)?


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Tuesday, 12 November 2024 01:53
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Good to know, ty vm.

At the very least, I have this workaround. This will meet my needs for now.

I guess my final question would be -- is this type of problem better suited to something besides parallel streams? Maybe an ExecutorService?

Really, all I am doing is taking a jumbo file, splitting it into batches, and then doing some work on those batches. My IO speeds are pretty fast, and the compute work is non-trivial, so there is performance being left on the table if I give up parallelism. And I am in a position where completion time is very important to us.

I just naturally assumed parallel streams were the right choice because the compute work is simple. A pure function that I can break out, and then call in a map. Once I do that, I just call forEach to write the batches back out to S3. Maybe I should look into a different part of the std lib instead because I am using the wrong tool for the job? My nose says ExecutorService, but I figure I should ask before I dive too deep in.


On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
You're most welcome!

In a potential future where all intermediate operations are Gatherer-based, and all terminal operations are Collector-based, it would just work as expected. But with that said, I'm not sure it is practically achievable because some operations might not have the same performance-characteristics as before.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Monday, 11 November 2024 18:32
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Thanks for the workaround. It's running beautifully.

Is there a future where this island concept is extended to the rest of streams? Tbh, I don't fully understand it.

On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi David,

This is the effect of how parallel streams are implemented, where different stages, which are not representible as a join-less Spliterator are executed as a series of "islands" where the next isn't started until the former has completed.

If you think about it, parallelization of a Stream works best when the entire data set can be split amongst a set of worker threads, and that sort of implies that you want eager pre-fetch of data, so if your dataset does not fit in memory, that is likely to lead to less desirable outcomes.

What I was able to do for Gatherers is to implement "gather(?) + collect(?)"-fusion so any number of consecutive gather(?)-operations immediately followed by a collect(?) is run in the same "island".

So with that said, you could try something like the following:

static <T> Collector<T, ?, Void> forEach(Consumer<? super T> each) {
    return Collector.of(() -> null, (v, e) -> each.accept(e), (l, r) -> l, (v) -> null, Collector.Characteristics.IDENTITY_FINISH);
}


stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.collect(forEach(eachList -> println(eachList.getFirst())));


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Monday, 11 November 2024 14:52
To: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question about Streams, Gatherers, and fetching too many elements

And just to avoid the obvious question, I can hold about 30 batches in memory before the Out of Memory error occurs. So this is not an issue of my batch size being too high.

But just to confirm, I set the batch size to 1, and it still ran into an out of memory error. So I feel fairly confident saying that the Gatherer is trying to grab all available data before sending any of it downstream.

On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Hello Core Libs Dev Team,

I was trying out Gatherers for a project at work, and ran into a rather sad scenario.

I need to process a large file in batches. Each batch is small enough that I can hold it in memory, but I cannot hold the entire file (and thus, all of the batches) in memory at once.

Looking at the Gatherers API, I saw windowFixed and thought that it would be a great match for my use case.

However, when trying it out, I was disappointed to see that it ran out of memory very quickly. Here is my attempt at using it.

stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.forEach(eachList -> println(eachList.getFirst()))
;

As you can see, I am just splitting the file into batches, and printing out the first of each batch. This is purely for example's sake, of course. I had planned on building even more functionality on top of this, but I couldn't even get past this example.

But anyways, not even a single one of them printed out. Which leads me to believe that it's pulling all of them in the Gatherer.

I can get it to run successfully if I go sequentially, but not parallel. Parallel gives me that out of memory error.

Is there any way for me to be able to have the Gatherer NOT pull in everything while still remaining parallel and unordered?

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241112/27abcd03/attachment-0001.htm>

From vromero at openjdk.org  Tue Nov 12 15:13:41 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Nov 2024 15:13:41 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v4]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <ADVBMFnQnFL-nReDC1yheWqDvNudx-VioTinlWoFWoQ=.d32ccddc-1abe-46e0-912f-380c9c651625@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Vicente Romero has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' into JDK-8343286
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - Merge branch 'master' into JDK-8343286
 - fixing build error
 - 8343286: Redundant cast in polymorphic method call

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/5bfcf8ef..f66ee79d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=02-03

  Stats: 15056 lines in 470 files changed: 11106 ins; 2074 del; 1876 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

PR: https://git.openjdk.org/jdk/pull/21914

From pchilanomate at openjdk.org  Tue Nov 12 15:16:12 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 15:16:12 GMT
Subject: RFR: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning [v5]
In-Reply-To: <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
 <EXWNibjIMTt3m6r7uY2C20eRTQeq1tI9D1hejkAo0Z8=.c1f4d625-91d7-4c35-8d9e-7d2b42a9e634@github.com>
Message-ID: <A_fEv9pCgcr1SaNUUBjzJWqpenFyplpeTeEcW2YurcE=.17d74ae6-cea8-4107-8597-1fcacac27562@github.com>

On Tue, 12 Nov 2024 02:59:59 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

>> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
>> 
>> In order to make the code review easier the changes have been split into the following initial 4 commits:
>> 
>> - Changes to allow unmounting a virtual thread that is currently holding monitors.
>> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
>> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
>> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
>> 
>> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
>> 
>> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
>> 
>> 
>> ## Summary of changes
>> 
>> ### Unmount virtual thread while holding monitors
>> 
>> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
>> 
>> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
>> 
>> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
>> 
>> #### General notes about this part:
>> 
>> - Since virtual th...
>
> Patricio Chilano Mateo has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 90 commits:
> 
>  - Merge branch 'master' into JDK-8338383
>  - Test StopThreadTest.java: fix operator in condition + improve names
>  - Pass -XX:-UseCompactObjectHeaders in test JNIMonitor.java
>  - Merge branch 'master' into JDK-8338383
>  - Fix in JvmtiEnvBase::get_locked_objects_in_frame()
>  - Add ObjectWaiter::at_monitorenter
>  - Use get_method_name + copyright revert in jvmtiThreadState.cpp
>  - Merge branch 'master' into JDK-8338383
>  - Add @requires vm.continuations to CancelTimerWithContention.java
>  - Use JvmtiVTMSTransitionDisabler::VTMS_vthread_mount/unmount
>  - ... and 80 more: https://git.openjdk.org/jdk/compare/babb52a0...0fe60465

Many thanks to all reviewers and contributors of this JEP!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21565#issuecomment-2470802813

From rriggs at openjdk.org  Tue Nov 12 15:17:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 15:17:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <y18nI8ZKAB47qMMhqmhSOhr-kknoaDFEyLm2UHrcK7E=.07f02e84-b49e-485d-82c0-5f8ef3a78718@github.com>

On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2429896801

From aivanov at openjdk.org  Tue Nov 12 15:17:10 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Nov 2024 15:17:10 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <ufxaN4j9f8QT0vD15t3H-3TfFJzFleR3TPfOiM60NO4=.b61703b5-70cb-44e9-99e0-3cc09c86c29b@github.com>
 <huYnFBgwvUhzA4PNlAhN4EfBpFr6uBVhwPkJOrZnKuk=.ba1e8f18-b802-4c9b-b96e-6a41afa08122@github.com>
 <N6XI13dduMYOcgU5sxZEKu28HLp3ZRXsdNX_lYxyJbw=.49c6be3f-774b-48c9-af29-8786cf0c7a89@github.com>
 <BCbTjQ1oRW64L5VkUUSN669QAU7EIG226KB0fJJlSWo=.f5481238-4339-42ac-a0d8-f8ee09a93cbe@github.com>
 <eFoWPizB1Mn9q5EHOg3bcXJdg1_dAg7wY7JidGJX-E4=.b1956494-62fb-44c5-9fb2-c4d24645e069@github.com>
 <s3IyrZIj3_JkFq-vN127awevoKIjWesVk-lywaHmfBU=.202d3063-34a9-4098-9d3e-4421c94bdb58@github.com>
Message-ID: <ZJ2gt2LT5Xcrgjc9gpjOIn87PHt9uFilNQKSplRKd3g=.7da1b1dc-c572-4a7a-a07c-460a38a1f637@github.com>

On Tue, 12 Nov 2024 15:02:12 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I can add it back if it is more convenient and readable to have the `@see` tag.
>
> This can be taken care of later after integration.

Agreed!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21498#discussion_r1838282210

From pchilanomate at openjdk.org  Tue Nov 12 15:27:02 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 12 Nov 2024 15:27:02 GMT
Subject: Integrated: 8338383: Implement JEP 491: Synchronize Virtual Threads
 without Pinning
In-Reply-To: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
References: <kTiJqbs8dtUQovYheYHyj3OvWvitYVk-Ufjvy-msAGQ=.f7710fa7-320e-41dc-8060-a3685ee3967e@github.com>
Message-ID: <EXnxvKvm9l0yuV-jt5tIPzV3JL8hoSSstko26DrlKN0=.fcd823c0-7588-4b2a-8308-3125094a41c6@github.com>

On Thu, 17 Oct 2024 14:28:30 GMT, Patricio Chilano Mateo <pchilanomate at openjdk.org> wrote:

> This is the implementation of JEP 491: Synchronize Virtual Threads without Pinning. See [JEP 491](https://bugs.openjdk.org/browse/JDK-8337395) for further details.
> 
> In order to make the code review easier the changes have been split into the following initial 4 commits:
> 
> - Changes to allow unmounting a virtual thread that is currently holding monitors.
> - Changes to allow unmounting a virtual thread blocked on synchronized trying to acquire the monitor.
> - Changes to allow unmounting a virtual thread blocked in `Object.wait()` and its timed-wait variants.
> - Changes to tests, JFR pinned event, and other changes in the JDK libraries.
> 
> The changes fix pinning issues for all 4 ports that currently implement continuations: x64, aarch64, riscv and ppc. Note: ppc changes were added recently and stand in its own commit after the initial ones.
> 
> The changes fix pinning issues when using `LM_LIGHTWEIGHT`, i.e. the default locking mode, (and `LM_MONITOR` which comes for free), but not when using `LM_LEGACY` mode. Note that the `LockingMode` flag has already been deprecated ([JDK-8334299](https://bugs.openjdk.org/browse/JDK-8334299)), with the intention to remove `LM_LEGACY` code in future releases.
> 
> 
> ## Summary of changes
> 
> ### Unmount virtual thread while holding monitors
> 
> As stated in the JEP, currently when a virtual thread enters a synchronized method or block, the JVM records the virtual thread's carrier platform thread as holding the monitor, not the virtual thread itself. This prevents the virtual thread from being unmounted from its carrier, as ownership information would otherwise go wrong. In order to fix this limitation we will do two things:
> 
> - We copy the oops stored in the LockStack of the carrier to the stackChunk when freezing (and clear the LockStack). We copy the oops back to the LockStack of the next carrier when thawing for the first time (and clear them from the stackChunk). Note that we currently assume carriers don't hold monitors while mounting virtual threads.
> 
> - For inflated monitors we now record the `java.lang.Thread.tid` of the owner in the ObjectMonitor's `_owner` field instead of a JavaThread*. This allows us to tie the owner of the monitor to a `java.lang.Thread` instance, rather than to a JavaThread which is only created per platform thread. The tid is already a 64 bit field so we can ignore issues of the counter wrapping around.
> 
> #### General notes about this part:
> 
> - Since virtual threads don't need to worry about holding monitors anymo...

This pull request has now been integrated.

Changeset: 78b80150
Author:    Patricio Chilano Mateo <pchilanomate at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78b80150e009745b8f28d36c3836f18ad0ca921f
Stats:     9984 lines in 249 files changed: 7169 ins; 1629 del; 1186 mod

8338383: Implement JEP 491: Synchronize Virtual Threads without Pinning

Co-authored-by: Patricio Chilano Mateo <pchilanomate at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Andrew Haley <aph at openjdk.org>
Co-authored-by: Fei Yang <fyang at openjdk.org>
Co-authored-by: Coleen Phillimore <coleenp at openjdk.org>
Co-authored-by: Richard Reingruber <rrich at openjdk.org>
Co-authored-by: Martin Doerr <mdoerr at openjdk.org>
Reviewed-by: aboldtch, dholmes, coleenp, fbredberg, dlong, sspitsyn

-------------

PR: https://git.openjdk.org/jdk/pull/21565

From sgehwolf at redhat.com  Tue Nov 12 15:33:50 2024
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Tue, 12 Nov 2024 16:33:50 +0100
Subject: RFC: Introduce JDK property jdk.patched for indicating
 --patch-module at runtime
Message-ID: <7c5c3044b4d69113892ac6c9970a7d8b0af11900.camel@redhat.com>

Hi,

For JDK-8343839 it would be useful to have some form of API in order to
be able to detect that a currently running Java process has been
launched with '--patch-module'.

Alan Bateman suggested to expose a boolean JDK property to indicate a
runtime that has been launched with --patch-module. In particular, the
suggestion was to use 'jdk.patched' which would be set to true iff
--patch-module is present when the java process launched.

The added benefit would be to have this information available via
serviceability tools as well. For example, -XshowSettings:properties
would be able to show this new property.

Thoughts? Concerns?

Thanks,
Severin



From alanb at openjdk.org  Tue Nov 12 15:33:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 15:33:22 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <5WLImJZVliyCfPwtyv65k7gGHlMrw2D85MjTvY2erKQ=.f7b61835-fe85-4d7a-8362-405ef09209fd@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <vuzTesVqSBmTN3Vlx4fwBFLrCsVUd3CXESzvJ70T3QA=.8609d69e-70fa-4ab7-8bba-446f1615f7e3@github.com>
 <_wL5ioaJSVkua-Tt7hgek_mgkW3ZQYYqITkCLJunUaM=.9ebf630c-6d5b-408f-9c9c-7cb22fff1818@github.com>
 <X3eBPJicNF2jf_bWT-H2vJIG7LO9dFQtjq8KyB_Uqms=.3ceffefd-2e6f-4add-a776-595c08d04fd6@github.com>
 <5WLImJZVliyCfPwtyv65k7gGHlMrw2D85MjTvY2erKQ=.f7b61835-fe85-4d7a-8362-405ef09209fd@github.com>
Message-ID: <xF1reLD_7FI3-zeEKrYPzUM9gm5BcV8VeyTLddyPdnU=.1c9af84a-3b8e-4727-9bc7-5e53c9aec7f3@github.com>

On Tue, 12 Nov 2024 13:18:34 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> The idea behind printing the short version is to identify what tool is speaking. It can be removed, if desired.
>
> `shortVersionString` changed to `conciseVersionString` in:
> https://github.com/openjdk/jdk/pull/21411/commits/e9e9ad4bdd0a11244cb1ef84fdeea036e94718c7

> The idea behind printing the short version is to identify what tool is speaking. It can be removed, if desired.

It may be helpful to some but I'm consider it may be confusing in other cases, esp. because it may include "LTS" in the output. So I think maybe drop this for now, or get wider input on print the version string as the first line, it can always be added later if needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1838309819

From jlahoda at openjdk.org  Tue Nov 12 15:36:50 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 12 Nov 2024 15:36:50 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <A0B6qDEx6Ib2WKeIxBs-f9fIGTMedalFjvxCIvXQ74g=.2cb99e10-4e92-4225-bcb3-22273c1106a4@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
 <A0B6qDEx6Ib2WKeIxBs-f9fIGTMedalFjvxCIvXQ74g=.2cb99e10-4e92-4225-bcb3-22273c1106a4@github.com>
Message-ID: <zVIkkJgsKJjmTkMhdCALT9j40KNVz2ShIwX8HQCSBQE=.c73ba1fe-2bd4-4608-9382-f0796b31505f@github.com>

On Tue, 12 Nov 2024 14:04:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/sun/launcher/resources/launcher.properties line 241:
>> 
>>> 239: \  -jar <jarfile>.jar         to execute the main class of a JAR archive\n\
>>> 240: \  -m <module>[/<mainclass>]  to execute the main class of a module\n\
>>> 241: \  <sourcefile>.java          to compile and execute a source-file program\n\n\
>> 
>> I'm not sure about the description of <mainclass>. It uses "compiled class", maybe you meant "compiled main class" or something else to connect it "<mainclass>"?
>> 
>> "-jar <jarfile>.jar" may be confusing because the "java -help" uses "-java <jarfile">". I think the usages need to be the same.
>
>> @AlanBateman I'd like to respectfully disagree that this was an improvement. If consistency was the important objection here, maybe it would have been better to update "java -help" to include the .jar?
> 
> I assume your disagreement is with Jan's latest update rather than my comment. My comment was just pointing out that it's confusing to use `-jar <jarfile>.jar` in one case and `-jar <jarfile>` in the other.

So, just to double-check: given the request is to make the helps consistent, and dropping the extensions from the concise help is not what was meant, I'll add the extensions both here and to the ordinary help. Correct?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1838316368

From sgehwolf at openjdk.org  Tue Nov 12 15:38:24 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 15:38:24 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early
In-Reply-To: <SVayUy5v_C1hf___r1Gd025k8csoFaWeIlxtjkiEVAg=.6d65e3ae-a7e0-4e93-9606-03a3d213a794@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
 <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
 <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
 <xN7uGi3rA6o-GskzEnRHsyR6iIOplY6lfMi-FIIdjiI=.b61ac634-ceb2-49ec-a7cb-94676afe4aec@github.com>
 <SVayUy5v_C1hf___r1Gd025k8csoFaWeIlxtjkiEVAg=.6d65e3ae-a7e0-4e93-9606-03a3d213a794@github.com>
Message-ID: <rSvHDV3xjCjhplZlgX6sXniK67RXaab2hGdAv69dJFQ=.7a743a41-696c-4d13-8e3e-79c1eee529e9@github.com>

On Tue, 12 Nov 2024 14:34:45 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Yes, I'm wondering if a JDK-specific (rather than standard) property could be more widely useful as it would allow observability tools to know that the JDK has been patched. It would be good to get wider input on this.
>
> OK, thanks. I'll start a thread on core-libs-dev about this.

https://mail.openjdk.org/pipermail/core-libs-dev/2024-November/134623.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1838317379

From duke at openjdk.org  Tue Nov 12 15:44:55 2024
From: duke at openjdk.org (kabutz)
Date: Tue, 12 Nov 2024 15:44:55 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
Message-ID: <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>

On Mon, 4 Nov 2024 16:14:35 GMT, kabutz <duke at openjdk.org> wrote:

>> Sure, where should I add that test?
>
>> @kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.
> 
> Indeed, I didn't check what happens when we create a spliterator on an empty collection.

> @kabutz Let me know how you want to proceed. ?

've made the changes and sent another PR to the branch holding the changes. Hope that's the right way of doing it...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2470874303

From vklang at openjdk.org  Tue Nov 12 15:50:46 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Nov 2024 15:50:46 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
 <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
Message-ID: <Un1lP7dlWLhS1Mw7J8U3JcK3pAnB04X4fNA2APOVktg=.dd9200e8-b65f-4557-94d8-d882f0a357d6@github.com>

On Tue, 12 Nov 2024 15:41:36 GMT, kabutz <duke at openjdk.org> wrote:

>>> @kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.
>> 
>> Indeed, I didn't check what happens when we create a spliterator on an empty collection.
>
>> @kabutz Let me know how you want to proceed. ?
> 
> 've made the changes and sent another PR to the branch holding the changes. Hope that's the right way of doing it...

@kabutz Ah, so then you can close this PR? I'll have a look at the other PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2470891660

From vklang at openjdk.org  Tue Nov 12 15:53:18 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Nov 2024 15:53:18 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
 <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
Message-ID: <cgqNZz0obyJsaixIB9rKbbrJhmZuyyv3inYd5Swh7FQ=.928e7428-3619-4278-a551-bd130632fffd@github.com>

On Tue, 12 Nov 2024 15:41:36 GMT, kabutz <duke at openjdk.org> wrote:

>>> @kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.
>> 
>> Indeed, I didn't check what happens when we create a spliterator on an empty collection.
>
>> @kabutz Let me know how you want to proceed. ?
> 
> 've made the changes and sent another PR to the branch holding the changes. Hope that's the right way of doing it...

@kabutz Might actually be easier to drop the other PR and add the commits to your branch [8343426-cslm-spliterator-bug](https://github.com/kabutz/jdk/tree/8343426-cslm-spliterator-bug) so this PR is updated.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2470897103

From swen at openjdk.org  Tue Nov 12 15:54:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 15:54:00 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v6]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  more fix unsafe address overflow

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/f8f58546..97615464

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=04-05

  Stats: 6 lines in 2 files changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From swen at openjdk.org  Tue Nov 12 15:54:00 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 15:54:00 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
 <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
Message-ID: <NgZerEQu2KGipyyDbIip-FR2tonnWpVra8iR81-Pkso=.c93d1921-3c84-428f-a98e-911baa95f49b@github.com>

On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename address to offset, from @AlanBateman
>
> Marked as reviewed by alanb (Reviewer).

@AlanBateman @minborg 
Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470896128

From lancea at openjdk.org  Tue Nov 12 16:00:20 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 12 Nov 2024 16:00:20 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <T4XvpsK7Crm19k2etafDqv0D5yoZLmLgGNw9Xk2ogdg=.5af67060-a5a1-49a5-8014-4b808b810e4f@github.com>

On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Thank you for all of your hard work on this JEP Sean.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430018834

From duke at openjdk.org  Tue Nov 12 16:02:20 2024
From: duke at openjdk.org (kabutz)
Date: Tue, 12 Nov 2024 16:02:20 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream [v2]
In-Reply-To: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
Message-ID: <2GrrhLc90zA3RSzRzhJuv-RvYBIBDUFn8di6WRZBl8g=.383ebbf8-f33b-42e1-bf93-dc8d239ac9ef@github.com>

> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
> 
> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.

kabutz has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - Merge branch 'openjdk:master' into 8343426-cslm-spliterator-bug
 - Fixed bug in spliterators

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21820/files
  - new: https://git.openjdk.org/jdk/pull/21820/files/28658230..7edb48c8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21820&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21820&range=00-01

  Stats: 218051 lines in 2420 files changed: 138428 ins; 54883 del; 24740 mod
  Patch: https://git.openjdk.org/jdk/pull/21820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21820/head:pull/21820

PR: https://git.openjdk.org/jdk/pull/21820

From coffeys at openjdk.org  Tue Nov 12 16:03:27 2024
From: coffeys at openjdk.org (Sean Coffey)
Date: Tue, 12 Nov 2024 16:03:27 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <S2BNzehI36J_Jflq6pI9AuDrfYsA8dTAeE3jCac-Bh8=.7baf781b-3caa-44cd-acb6-9f75055c353b@github.com>

On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by coffeys (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430024985

From vromero at openjdk.org  Tue Nov 12 16:05:15 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Nov 2024 16:05:15 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v5]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <lZLWIP4VsWUu83ZmAovkduFOZO-Cwzg3G95Ract0A6s=.f030a5df-f7a7-4a05-a749-a351c1128697@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  addressing CSR comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/f66ee79d..7fd18f47

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=03-04

  Stats: 7 lines in 2 files changed: 5 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

PR: https://git.openjdk.org/jdk/pull/21914

From aefimov at openjdk.org  Tue Nov 12 16:05:18 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 12 Nov 2024 16:05:18 GMT
Subject: RFR: 8344023: Unnecessary Hashtable usage in
 LdapClient.defaultBinaryAttrs
In-Reply-To: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
References: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
Message-ID: <-4TM1hNmjnHG1TDnuOIwA7cNroDvfxhFKGUPXMQtitM=.f0d46d77-c009-472f-b37e-f2a6f03a59b3@github.com>

On Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is fully initialized in `<clinit>` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.

The changes look good to me. Also, I've launched existing JNDI/LDAP tests, and no issues related to the change were observed.

-------------

Marked as reviewed by aefimov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21903#pullrequestreview-2430030185

From shade at openjdk.org  Tue Nov 12 16:07:48 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 12 Nov 2024 16:07:48 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
Message-ID: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>

See the bug for more discussion and reproducer. This PR replaces the linked list with an `ArrayList` wrapper that manages synchronization, search and replacements effectively. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we already have, and I think it is safer to continue with it right now.

I'll put performance data in a separate comment.

Additional testing:
 - [x] Original reproducer improves drastically
 - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
 - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
 - [x] `java/lang/ref` tests in release 
 - [ ] `all` tests in fastdebug

-------------

Commit messages:
 - Fix

Changes: https://git.openjdk.org/jdk/pull/22043/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343704
  Stats: 275 lines in 4 files changed: 205 ins; 58 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Tue Nov 12 16:07:48 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 12 Nov 2024 16:07:48 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <54GXnZ74nfNIACF2KBHroHbR-RS4_lWdjI-tDolWkmg=.a345a854-ebaf-4404-bd70-985e1e73a793@github.com>

On Tue, 12 Nov 2024 16:00:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion and reproducer. This PR replaces the linked list with an `ArrayList` wrapper that manages synchronization, search and replacements effectively. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we already have, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [ ] `all` tests in fastdebug

Original reproducer on my M1:


# Before
...
[8.989s][info ][gc       ] GC(50) Pause Young (Normal) (G1 Evacuation Pause) 608M->21M(1011M) 46.562ms
[9.187s][info ][gc       ] GC(51) Pause Young (Normal) (G1 Evacuation Pause) 608M->22M(1011M) 45.286ms
[9.387s][info ][gc       ] GC(52) Pause Young (Normal) (G1 Evacuation Pause) 609M->21M(1011M) 45.636ms
[9.592s][info ][gc       ] GC(53) Pause Young (Normal) (G1 Evacuation Pause) 608M->22M(1015M) 47.514ms
[9.794s][info ][gc       ] GC(54) Pause Young (Normal) (G1 Evacuation Pause) 612M->22M(1015M) 46.807ms
[9.993s][info ][gc       ] GC(55) Pause Young (Normal) (G1 Evacuation Pause) 612M->21M(1015M) 45.964ms

# After
...
[6.964s][info ][gc       ] GC(50) Pause Young (Normal) (G1 Evacuation Pause) 521M->36M(830M) 11.096ms
[7.108s][info ][gc       ] GC(51) Pause Young (Normal) (G1 Evacuation Pause) 521M->36M(830M) 11.380ms
[7.252s][info ][gc       ] GC(52) Pause Young (Normal) (G1 Evacuation Pause) 521M->36M(830M) 11.293ms
[7.397s][info ][gc       ] GC(53) Pause Young (Normal) (G1 Evacuation Pause) 520M->35M(830M) 12.407ms
[7.540s][info ][gc       ] GC(54) Pause Young (Normal) (G1 Evacuation Pause) 520M->37M(830M) 11.096ms


A closest reproducer in form of JMH test also improves:


Benchmark          (count)  (recipFreq)  Mode  Cnt   Score    Error  Units

# Before
CleanerGC.test       16384          N/A  avgt   15   2.170 ?  0.082  ms/op
CleanerGC.test       65536          N/A  avgt   15   2.281 ?  0.104  ms/op
CleanerGC.test      262144          N/A  avgt   15   6.176 ?  0.466  ms/op
CleanerGC.test     1048576          N/A  avgt   15  22.913 ?  5.171  ms/op
CleanerGC.test     4194304          N/A  avgt   15  77.781 ? 14.937  ms/op

# After
CleanerGC.test       16384          N/A  avgt   15   2.169 ? 0.061  ms/op
CleanerGC.test       65536          N/A  avgt   15   2.247 ? 0.083  ms/op
CleanerGC.test      262144          N/A  avgt   15   3.822 ? 0.191  ms/op
CleanerGC.test     1048576          N/A  avgt   15   9.750 ? 0.638  ms/op
CleanerGC.test     4194304          N/A  avgt   15  33.842 ? 5.382  ms/op


Churn benchmark, which covers insertion/removal perf, matches the original implementation closely:


Benchmark          (count)  (recipFreq)  Mode  Cnt   Score    Error  Units

# Before
CleanerChurn.test      N/A          128  avgt    9   7.063 ?  0.262  ns/op
CleanerChurn.test      N/A          256  avgt    9   5.669 ?  0.118  ns/op
CleanerChurn.test      N/A          512  avgt    9   5.025 ?  0.066  ns/op
CleanerChurn.test      N/A         1024  avgt    9   4.714 ?  0.086  ns/op
CleanerChurn.test      N/A         2048  avgt    9   4.595 ?  0.091  ns/op

# After
CleanerChurn.test      N/A          128  avgt    9   7.050 ? 0.847  ns/op
CleanerChurn.test      N/A          256  avgt    9   5.378 ? 0.186  ns/op
CleanerChurn.test      N/A          512  avgt    9   4.896 ? 0.112  ns/op
CleanerChurn.test      N/A         1024  avgt    9   4.712 ? 0.063  ns/op
CleanerChurn.test      N/A         2048  avgt    9   4.671 ? 0.071  ns/op

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2470928360

From aivanov at openjdk.org  Tue Nov 12 16:11:19 2024
From: aivanov at openjdk.org (Alexey Ivanov)
Date: Tue, 12 Nov 2024 16:11:19 GMT
Subject: RFR: 8338411: Implement JEP 486: Permanently Disable the Security
 Manager [v11]
In-Reply-To: <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
 <GIp9IX9i9UsNNTO1pdvMvGhWJfCSgMEi4VGXkOfvGCo=.cfc2c545-7be8-4a60-81a9-4720ea42ea12@github.com>
Message-ID: <y-mlQzl5xkWAglmNtQjN9AQH27dL2Lj1uviN_EQ5wTk=.29bd4e0c-560a-4b39-a743-9aefd78009a4@github.com>

On Tue, 12 Nov 2024 14:44:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
>> 
>> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
>> 
>> The code changes can be broken down into roughly the following categories:
>> 
>> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
>> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
>> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
>> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
>> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
>> 
>> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
>> 
>> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
>> 
>> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, ...
>
> Sean Mullan has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 230 commits:
> 
>  - Merge
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - ... and 220 more: https://git.openjdk.org/jdk/compare/8a2a75e5...7c996a5e

Marked as reviewed by aivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21498#pullrequestreview-2430049235

From duke at openjdk.org  Tue Nov 12 16:12:36 2024
From: duke at openjdk.org (kabutz)
Date: Tue, 12 Nov 2024 16:12:36 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream [v3]
In-Reply-To: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
Message-ID: <nbHSVJw56lW8cmWDlxms_zs1f8YRGU3XICBXBSY55js=.42c0cce9-f5c6-4e95-a107-82209c4dc6ce@github.com>

> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
> 
> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.

kabutz has updated the pull request incrementally with one additional commit since the last revision:

  Removed NPE when set is empty and added TCK test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21820/files
  - new: https://git.openjdk.org/jdk/pull/21820/files/7edb48c8..d167b88f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21820&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21820&range=01-02

  Stats: 43 lines in 2 files changed: 31 ins; 0 del; 12 mod
  Patch: https://git.openjdk.org/jdk/pull/21820.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21820/head:pull/21820

PR: https://git.openjdk.org/jdk/pull/21820

From vromero at openjdk.org  Tue Nov 12 16:15:31 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Tue, 12 Nov 2024 16:15:31 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v6]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <wGw56NfcZDgy2xiyV-UDq8B6SuyT3SbsHB93ebjida0=.1a2e9fca-62a2-4aa1-b32f-12507364e562@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  adding regression test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/7fd18f47..a99c4547

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=04-05

  Stats: 3 lines in 2 files changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

PR: https://git.openjdk.org/jdk/pull/21914

From alanb at openjdk.org  Tue Nov 12 16:25:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 16:25:39 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v6]
In-Reply-To: <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <62AWophiRKc0GQ_HX3qQ57fqjVl4DuJPUfb4nNoLJ8A=.cfde82d0-b1a4-4137-a80b-cd7410312bae@github.com>
Message-ID: <uO1_Z-TC4tXY1a-nkYdwlHSXCdoVaz5t14uPomm6mK4=.7c6ab72b-3ed3-4e5d-8789-34a05eccdb12@github.com>

On Tue, 12 Nov 2024 15:54:00 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more fix unsafe address overflow

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2430082452

From alanb at openjdk.org  Tue Nov 12 16:25:40 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 16:25:40 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v5]
In-Reply-To: <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <s7VKsWoNc0S-aSbEswKMUmW1eGKOkmNgVPIqjKGlptU=.1f3eae30-532e-4ae9-8df6-d10b92946968@github.com>
 <gff-1KXGW_Tr8t6uqR9XVacLSVQfVzKMtKXZ3GTFG5E=.8d114140-335a-4001-b4cf-8c3ab18790dd@github.com>
Message-ID: <ZMXQV7nYoJC83kfU7dqLwH3w1r6tO-vy7RncDn3dvHw=.104a7370-97cf-4472-aba5-8d0e572e4ed3@github.com>

On Tue, 12 Nov 2024 12:10:07 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   rename address to offset, from @AlanBateman
>
> Marked as reviewed by alanb (Reviewer).

> @AlanBateman @minborg Sorry, after you approved it, I found that there are still offset overflows in ZipUtils and UnixUserDefinedFileAttributeView, so I submitted the changes again. Please help review it again.

Looks good, can you bump the copyright header on UnixUserDefinedFileAttributeView too?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2470974166

From rriggs at openjdk.org  Tue Nov 12 16:26:30 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 16:26:30 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
Message-ID: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>

After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
Some refactoring to cleanup the remaining code is expected.

-------------

Depends on: https://git.openjdk.org/jdk/pull/21498

Commit messages:
 - JDK-8344034: Remove security manager dependency in Serialization

Changes: https://git.openjdk.org/jdk/pull/22041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344034
  Stats: 382 lines in 5 files changed: 2 ins; 287 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From swen at openjdk.org  Tue Nov 12 16:30:12 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 16:30:12 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  fix copyright

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/97615464..980cb229

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=05-06

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From swen at openjdk.org  Tue Nov 12 16:40:19 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 16:40:19 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
Message-ID: <Lu3NmaigDUVtank2FwOV3lrNWwTgK_IS1LohnLitRnQ=.63b4dabe-8f94-47c9-a6c4-6faa977c0529@github.com>

On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

@liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471016555

From alanb at openjdk.org  Tue Nov 12 16:46:11 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 16:46:11 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and related
 classes
Message-ID: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>

Removes the SecurityManager usage from Thread + friends.

In Thread, the getContextClassLoader method is no longer caller-sensitive method.

JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.

-------------

Depends on: https://git.openjdk.org/jdk/pull/21498

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22035/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22035&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343981
  Stats: 283 lines in 10 files changed: 0 ins; 228 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/22035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22035/head:pull/22035

PR: https://git.openjdk.org/jdk/pull/22035

From alanb at openjdk.org  Tue Nov 12 16:46:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 16:46:31 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <Lu3NmaigDUVtank2FwOV3lrNWwTgK_IS1LohnLitRnQ=.63b4dabe-8f94-47c9-a6c4-6faa977c0529@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
 <Lu3NmaigDUVtank2FwOV3lrNWwTgK_IS1LohnLitRnQ=.63b4dabe-8f94-47c9-a6c4-6faa977c0529@github.com>
Message-ID: <Bm5lcsyGVXB5eofGWWWkiW1D0Rq63U8odOUyfV-t1X4=.2e113503-0d00-4925-a8f2-e689e492a64f@github.com>

On Tue, 12 Nov 2024 16:37:28 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> @liach provided a new idea, which is to change the type of jdk.internal.misc.Unsafe.ARRAY_XXX_OFFSET from int to long. I think @liach's idea is better, that is the way to completely solve this problem.

I discussed this briefly with him today, he's looking into the implications of doing that.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471038775

From liach at openjdk.org  Tue Nov 12 16:52:23 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Nov 2024 16:52:23 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
Message-ID: <00Pb2OkiKtnrABDOzIvqOFhuNoXn6UyPiy-P1Nu_Nhw=.8bd821bb-2cb6-44da-b39c-72047bad43b1@github.com>

On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

I think this patch can go ahead: the change to internal unsafe will affect many other components and all use sites will get bytecode updates.  The more comprehensive change will need more throughout investigation and testing, while the fixes here are straightforward and easy to verify.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22027#issuecomment-2471054020

From darcy at openjdk.org  Tue Nov 12 17:03:28 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 17:03:28 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v13]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <UpUCOyEE5NlE9n7a8kgg-mAw5NfXoSbRkCK9dkfJsHw=.9f9b4d8f-6816-4351-a299-c1668ab96454@github.com>

> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix typos founds in code review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/8af04c4d..65722b09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=11-12

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21574/head:pull/21574

PR: https://git.openjdk.org/jdk/pull/21574

From alanb at openjdk.org  Tue Nov 12 17:03:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 17:03:38 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <OgFx3SVw01y40mczDBnKWlP_yKKr2P7jJI4v9xvYamA=.26cb0f9a-957c-4798-9167-0e7c18a798bd@github.com>

On Tue, 12 Nov 2024 15:09:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

src/java.base/share/classes/java/io/ObjectInputStream.java line 1551:

> 1549:      * is "safe", FALSE otherwise.
> 1550:      */
> 1551:     @SuppressWarnings("removal")

Can the `@SuppressWarnings` be removed?

src/java.base/share/classes/java/io/ObjectInputStream.java line 2651:

> 2649: 
> 2650:             Callback(ObjectInputValidation obj, int priority, Callback next)
> 2651:             {

I assume the "{" can move back to the previous line now.

src/java.base/share/classes/java/io/ObjectStreamClass.java line 279:

> 277:      * @return  the {@code Class} instance that this descriptor represents
> 278:      */
> 279:     @CallerSensitive

I assume this is no longer caller-sensitive.

src/java.base/share/classes/java/io/ObjectStreamClass.java line 918:

> 916:         if (cons != null) {
> 917:             try {
> 918:                 return cons.newInstance();

Do the ObjectStreamClass.newInstance still need suppress-warnings?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1838462339
PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1838463499
PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1838465737
PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1838468010

From dfuchs at openjdk.org  Tue Nov 12 17:06:47 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 12 Nov 2024 17:06:47 GMT
Subject: RFR: 8344023: Unnecessary Hashtable usage in
 LdapClient.defaultBinaryAttrs
In-Reply-To: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
References: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
Message-ID: <Y6WMbGY9kuaeQSHqel12jaq_yOIOezdHRpyyus_ckJY=.e5d00c74-9039-4460-946d-ecfe063b6580@github.com>

On Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is fully initialized in `<clinit>` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.

Thanks for running the tests @AlekseiEfimov

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21903#pullrequestreview-2430212907

From duke at openjdk.org  Tue Nov 12 17:07:46 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Tue, 12 Nov 2024 17:07:46 GMT
Subject: RFR: 8342566: Improve javadoc of java.lang.annotation.ElementType
 [v3]
In-Reply-To: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
References: <HIcr_jlJVg3pYYTkHd8OUuwRYSIyZrgyrr5vmIENe7U=.9a85b454-319a-4447-9910-4975f71e5385@github.com>
Message-ID: <V9Ne1gQvLKvc4GNWPKozpBswGGIvNODf8YqkVrbTt8E=.a3e413d4-166c-406f-9347-041bf7d60ee8@github.com>

> 8342566: Improve javadoc of java.lang.annotation.ElementType

Kevin Bourrillion has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge branch 'openjdk:master' into element-type-javadoc
 - Merge branch 'openjdk:master' into element-type-javadoc
 - Merge branch 'openjdk:master' into element-type-javadoc
 - Merge branch 'openjdk:master' into element-type-javadoc
 - handle review comments from Chen
 - maybe ready for review now
 - Merge branch 'openjdk:master' into element-type-javadoc
 - keep revising
 - massive rewrite

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21506/files
  - new: https://git.openjdk.org/jdk/pull/21506/files/3c8acc4d..8f74c311

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21506&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21506&range=01-02

  Stats: 217776 lines in 2376 files changed: 138300 ins; 54805 del; 24671 mod
  Patch: https://git.openjdk.org/jdk/pull/21506.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21506/head:pull/21506

PR: https://git.openjdk.org/jdk/pull/21506

From sviswanathan at openjdk.org  Tue Nov 12 17:11:02 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 12 Nov 2024 17:11:02 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <i8dNiKAZ4RsQAiFxtufWCv_O4vRSE1O-K3Fe14lAbvY=.88de32d8-267d-4079-b2ce-3ba801808ead@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
 <RvkEn6C7t0sGn1e939rf2SU07rxGwBEocMIoxBe_D-Q=.b3439e6e-7a70-49fb-b9c8-28eff1d7fed8@github.com>
 <i8dNiKAZ4RsQAiFxtufWCv_O4vRSE1O-K3Fe14lAbvY=.88de32d8-267d-4079-b2ce-3ba801808ead@github.com>
Message-ID: <1SFuaJR81N43qYbZw30JIV-XkAYjglS8Cecr3oUg0os=.9b39cd20-9fd1-43db-8011-3b6d90bdf371@github.com>

On Sun, 10 Nov 2024 07:36:55 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Yes, this should ensure 0xFFFFFFFF.
>
> We land here only after checking if inputs are uints, didn't want redundant match, its just a convince routine for forwarding inputs. I will create a lambda for this.

uint check only ensures value <= 0xFFFFFFFF. Here we need value to be 0xFFFFFFFF.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1838479496

From mullan at openjdk.org  Tue Nov 12 17:20:26 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 17:20:26 GMT
Subject: Integrated: 8338411: Implement JEP 486: Permanently Disable the
 Security Manager
In-Reply-To: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
References: <No3jlEWlbi30QwKwZuP0HJxjrQAlmQ_aY2tRg7O8YIc=.643931cc-b55a-41aa-a346-efb296f5f2df@github.com>
Message-ID: <Q0nD82TeeHNB3GUN883I9z2gNYRVerdm8O57BFweQMM=.43d95216-fd1d-4252-abb0-8eaec40efb61@github.com>

On Mon, 14 Oct 2024 13:52:24 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> This is the implementation of JEP 486: Permanently Disable the Security Manager. See [JEP 486](https://openjdk.org/jeps/486) for more details. The [CSR](https://bugs.openjdk.org/browse/JDK-8338412) describes in detail the main changes in the JEP and also includes an apidiff of the specification changes.
> 
> NOTE: the majority (~95%) of the changes in this PR are test updates (removal/modifications) and API specification changes, the latter mostly to remove `@throws SecurityException`. The remaining changes are primarily the removal of the `SecurityManager`, `Policy`, `AccessController` and other Security Manager API implementations. There is very little new code.
> 
> The code changes can be broken down into roughly the following categories:
> 
> 1. Degrading the behavior of Security Manager APIs to either throw Exceptions by default or provide an execution environment that disallows access to all resources by default.
> 2. Changing hundreds of methods and constructors to no longer throw a `SecurityException` if a Security Manager was enabled. They will operate as they did in JDK 23 with no Security Manager enabled.
> 3. Changing the `java` command to exit with a fatal error if a Security Manager is enabled.
> 4. Removing the hotspot native code for the privileged stack walk and the inherited access control context. The remaining hotspot code and tests related to the Security Manager will be removed immediately after integration - see [JDK-8341916](https://bugs.openjdk.org/browse/JDK-8341916).
> 5. Removing or modifying hundreds of tests. Many tests that tested Security Manager behavior are no longer relevant and thus have been removed or modified.
> 
> There are a handful of Security Manager related tests that are failing and are at the end of the `test/jdk/ProblemList.txt`, `test/langtools/ProblemList.txt` and `test/hotspot/jtreg/ProblemList.txt` files - these will be removed or separate bugs will be filed before integrating this PR. 
> 
> Inside the JDK, we have retained calls to `SecurityManager::getSecurityManager` and `AccessController::doPrivileged` for now, as these methods have been degraded to behave the same as they did in JDK 23 with no Security Manager enabled. After we integrate this JEP, those calls will be removed in each area (client-libs, core-libs, security, etc).
> 
> I don't expect each reviewer to review all the code changes in this JEP. Rather, I advise that you only focus on the changes for the area (client-libs, core-libs, net, security, etc) that you are most f...

This pull request has now been integrated.

Changeset: db850905
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db85090553ab14a84c3ed0a2604dd56c5b6e6982
Stats:     68914 lines in 1889 files changed: 2475 ins; 62597 del; 3842 mod

8338411: Implement JEP 486: Permanently Disable the Security Manager

Co-authored-by: Sean Mullan <mullan at openjdk.org>
Co-authored-by: Alan Bateman <alanb at openjdk.org>
Co-authored-by: Weijun Wang <weijun at openjdk.org>
Co-authored-by: Aleksei Efimov <aefimov at openjdk.org>
Co-authored-by: Brian Burkhalter <bpb at openjdk.org>
Co-authored-by: Daniel Fuchs <dfuchs at openjdk.org>
Co-authored-by: Harshitha Onkar <honkar at openjdk.org>
Co-authored-by: Joe Wang <joehw at openjdk.org>
Co-authored-by: Jorn Vernee <jvernee at openjdk.org>
Co-authored-by: Justin Lu <jlu at openjdk.org>
Co-authored-by: Kevin Walls <kevinw at openjdk.org>
Co-authored-by: Lance Andersen <lancea at openjdk.org>
Co-authored-by: Naoto Sato <naoto at openjdk.org>
Co-authored-by: Roger Riggs <rriggs at openjdk.org>
Co-authored-by: Brent Christian <bchristi at openjdk.org>
Co-authored-by: Stuart Marks <smarks at openjdk.org>
Co-authored-by: Ian Graves <igraves at openjdk.org>
Co-authored-by: Phil Race <prr at openjdk.org>
Co-authored-by: Erik Gahlin <egahlin at openjdk.org>
Co-authored-by: Jaikiran Pai <jpai at openjdk.org>
Reviewed-by: kevinw, aivanov, rriggs, lancea, coffeys, dfuchs, ihse, erikj, cjplummer, coleenp, naoto, mchung, prr, weijun, joehw, azvegint, psadhukhan, bchristi, sundar, attila

-------------

PR: https://git.openjdk.org/jdk/pull/21498

From alanb at openjdk.org  Tue Nov 12 17:26:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 17:26:02 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v2]
In-Reply-To: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
Message-ID: <7dSSEQvcNcWBiDF0TTSbBPHIts5ArSFkGckqU_2mg-U=.f3aebeb8-a2cf-4e17-8356-67f6a30084d2@github.com>

> Removes the SecurityManager usage from Thread + friends.
> 
> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
> 
> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 225 commits:

 - Initial commit
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - ... and 215 more: https://git.openjdk.org/jdk/compare/d0077eec...7bffe787

-------------

Changes: https://git.openjdk.org/jdk/pull/22035/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22035&range=01
  Stats: 69197 lines in 1892 files changed: 2475 ins; 62825 del; 3897 mod
  Patch: https://git.openjdk.org/jdk/pull/22035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22035/head:pull/22035

PR: https://git.openjdk.org/jdk/pull/22035

From rriggs at openjdk.org  Tue Nov 12 17:27:24 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 17:27:24 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v2]
In-Reply-To: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
Message-ID: <LY6yzppXrO2FjmcxX9nbyvdSvKkSkMTNQjwEfpslreA=.435483dd-c43a-4471-a89a-5a13fdbbde97@github.com>

> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 226 commits:

 - Simplify the generation of the exception message.
   The file path is always included in the exception, the IOException cause does not add useful information.
 - Remove security manager impl in java.lang.Process and java.lang.Runtime.exec
   Refactor to remove the dependencies on SecurityManager, doPrivileged, and AccessController.
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - ... and 216 more: https://git.openjdk.org/jdk/compare/d0077eec...319eca48

-------------

Changes: https://git.openjdk.org/jdk/pull/22024/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22024&range=01
  Stats: 69081 lines in 1893 files changed: 2475 ins; 62703 del; 3903 mod
  Patch: https://git.openjdk.org/jdk/pull/22024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22024/head:pull/22024

PR: https://git.openjdk.org/jdk/pull/22024

From rriggs at openjdk.org  Tue Nov 12 17:27:45 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 17:27:45 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v2]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <2iAxHHrezYPpHcufjUOUYNFqLWur_JmkEwYgn7LGS1g=.f661d5a1-5007-400e-9cc6-6f8c814fbb3c@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 225 commits:

 - JDK-8344034: Remove security manager dependency in Serialization
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - ... and 215 more: https://git.openjdk.org/jdk/compare/d0077eec...b45a76bf

-------------

Changes: https://git.openjdk.org/jdk/pull/22041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=01
  Stats: 69303 lines in 1891 files changed: 2482 ins; 62889 del; 3932 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From vklang at openjdk.org  Tue Nov 12 17:48:14 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Nov 2024 17:48:14 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
 <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
Message-ID: <2uQ_z7is-KTcUQDw8m5w5I_6O4Oi7lXes5LAyk67BJo=.86880842-6233-4cd6-8e4d-7e97cb7e1082@github.com>

On Tue, 12 Nov 2024 15:41:36 GMT, kabutz <duke at openjdk.org> wrote:

>>> @kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.
>> 
>> Indeed, I didn't check what happens when we create a spliterator on an empty collection.
>
>> @kabutz Let me know how you want to proceed. ?
> 
> 've made the changes and sent another PR to the branch holding the changes. Hope that's the right way of doing it...

@kabutz The update for CSLM is based on @DougLea's proposal on the JBS issue, right? (Assuming that's the case I will add him as a co-contributor)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2471189163

From liach at openjdk.org  Tue Nov 12 18:00:01 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Nov 2024 18:00:01 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v3]
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <XKYOEauGPTGzkT4z7PvZPgs8B8mIppxeEq7h-s_SXMM=.3edde68d-c7a1-4aa6-97ec-40b7341397b0@github.com>

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
 - Update docs per suggestion
 - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
 - Add a test to ensure serializable lambda creation and basic execution in hidden classes
 - Specify consequence
 - 8343064: ClassFormatError: Illegal class name from InnerClassLambdaMetafactory

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21912/files
  - new: https://git.openjdk.org/jdk/pull/21912/files/4e3790a9..c5e15955

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21912&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21912&range=01-02

  Stats: 100936 lines in 2665 files changed: 26381 ins; 67224 del; 7331 mod
  Patch: https://git.openjdk.org/jdk/pull/21912.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21912/head:pull/21912

PR: https://git.openjdk.org/jdk/pull/21912

From rriggs at openjdk.org  Tue Nov 12 18:05:46 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 18:05:46 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v3]
In-Reply-To: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
Message-ID: <_l0gpT2MUp35D4wOdhoMNFu-eO8JZKGQ-bhXp96FUa4=.19b84cdd-194d-46fe-85f7-a3add683de60@github.com>

> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits:

 - Merge branch 'master' into 8343958-process-sm-cleanup
 - correct exception message formatting
 - Simplify the generation of the exception message.
   The file path is always included in the exception, the IOException cause does not add useful information.
 - Remove security manager impl in java.lang.Process and java.lang.Runtime.exec
   Refactor to remove the dependencies on SecurityManager, doPrivileged, and AccessController.
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - ... and 218 more: https://git.openjdk.org/jdk/compare/63eb4853...4535e388

-------------

Changes: https://git.openjdk.org/jdk/pull/22024/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22024&range=02
  Stats: 166 lines in 5 files changed: 0 ins; 106 del; 60 mod
  Patch: https://git.openjdk.org/jdk/pull/22024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22024/head:pull/22024

PR: https://git.openjdk.org/jdk/pull/22024

From liach at openjdk.org  Tue Nov 12 18:02:48 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 12 Nov 2024 18:02:48 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v2]
In-Reply-To: <t_kN9keWunZ0GSPIayskKgmZXIKh5mVFX2BglAv6wkI=.ab9752b3-0c00-4ed6-b31a-e6bf430adf3b@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <t_kN9keWunZ0GSPIayskKgmZXIKh5mVFX2BglAv6wkI=.ab9752b3-0c00-4ed6-b31a-e6bf430adf3b@github.com>
Message-ID: <GefsgAPQUiVaSlQ2uBaYYGlrXd4_isudFDVBiY_CP3o=.2e575730-5315-4bec-9ae4-3757cfed2dd8@github.com>

On Tue, 5 Nov 2024 19:21:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
>> 
>> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
>> 
>> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add a test to ensure serializable lambda creation and basic execution in hidden classes

I have updated the documentation.

The API note has been simplified to a simple warning about the intended uses and the resource leak risk.

A new implementation note is added, mentioning the notorious "can't be unloaded" behavior #12493 in the reference implementation explicitly, and describe its implications.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21912#issuecomment-2471218170

From duke at openjdk.org  Tue Nov 12 18:30:46 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Tue, 12 Nov 2024 18:30:46 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v8]
In-Reply-To: <eIEgRZ2s1iXAt0zCF2uZSnIN8nUIWC1w4GmuXTn5C8s=.efdcdce8-33a3-45f9-8bff-58b512a61826@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <eIEgRZ2s1iXAt0zCF2uZSnIN8nUIWC1w4GmuXTn5C8s=.efdcdce8-33a3-45f9-8bff-58b512a61826@github.com>
Message-ID: <qJYjN6knDdG1OXt_Mcl16BS4QDag42Q56WyLMIrnsfQ=.93206a91-12e3-4956-8d65-dd8cb43429da@github.com>

On Tue, 12 Nov 2024 13:17:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - using "conciseVersionString" intead of "shortVersionString"
>   - using <jarfile>.jar <jarfile>

About the version string: I think I first proposed including it, because it seems easier and smoother and more user-friendly to just give the version, than to tell the user how they can ask for it and make them ask again. It doesn't take up much space and I just wasn't aware of any counterarguments.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2471273289

From alanb at openjdk.org  Tue Nov 12 18:34:54 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 18:34:54 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v3]
In-Reply-To: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
Message-ID: <ucT1x4EyocfEGiJmwALgc8CK48cGAhmJro47srF2cig=.03f42bcb-f9be-4de9-bba4-60d03bdee42d@github.com>

> Removes the SecurityManager usage from Thread + friends.
> 
> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
> 
> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 226 commits:

 - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
 - Initial commit
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - ... and 216 more: https://git.openjdk.org/jdk/compare/db850905...4f320f92

-------------

Changes: https://git.openjdk.org/jdk/pull/22035/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22035&range=02
  Stats: 283 lines in 11 files changed: 0 ins; 228 del; 55 mod
  Patch: https://git.openjdk.org/jdk/pull/22035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22035/head:pull/22035

PR: https://git.openjdk.org/jdk/pull/22035

From darcy at openjdk.org  Tue Nov 12 18:40:34 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 18:40:34 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v14]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <d2e7-Tss4eKtho0Ar6VSccrm7QgwDWHmJulu18NmbZs=.a4b3d82a-ee67-4d81-b0d1-c76fdf289b9f@github.com>

> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Fix bug parsing short inputs.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/65722b09..5ed21469

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=12-13

  Stats: 30 lines in 2 files changed: 28 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21574/head:pull/21574

PR: https://git.openjdk.org/jdk/pull/21574

From darcy at openjdk.org  Tue Nov 12 18:40:35 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 18:40:35 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <prIBfV-9SjZpGexOOnhVQ9FicA40RjBigJnT102gkcU=.eaf23bc3-fcef-4b6f-96b7-22840dc5f9e1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
 <os_i2UbFm71sKzSWTx0Wop4j6YxKKa5SSQonlMfUP1Q=.d56186af-9c2b-4db7-89ec-aee03158f79f@github.com>
 <FDq3PJ9Vmr03-KIVN8YlWzI4vqgKrH86luWfr-XMQUg=.f66cf820-0233-415c-967d-47395ec16818@github.com>
 <prIBfV-9SjZpGexOOnhVQ9FicA40RjBigJnT102gkcU=.eaf23bc3-fcef-4b6f-96b7-22840dc5f9e1@github.com>
Message-ID: <b2uGzUlgK4bcsP0igjvM0uoBYjATveusgi3dT6WmQBA=.04937e30-d915-4373-8def-2d4716014a96@github.com>

On Tue, 12 Nov 2024 12:49:01 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Thanks for catching that; fix and tests added in subsequent push.
>
> Single digit inputs, e.g., `Float16.valueOf"2")` throw as well.

Addressed in most recent push; thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1838590898

From alanb at openjdk.org  Tue Nov 12 18:47:46 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 18:47:46 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
Message-ID: <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>

> Removes the SecurityManager usage from Thread + friends.
> 
> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
> 
> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:

 - Merge branch 'master' into JDK-8343981
 - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
 - Initial commit
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...636ebd19

-------------

Changes: https://git.openjdk.org/jdk/pull/22035/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22035&range=03
  Stats: 282 lines in 10 files changed: 0 ins; 228 del; 54 mod
  Patch: https://git.openjdk.org/jdk/pull/22035.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22035/head:pull/22035

PR: https://git.openjdk.org/jdk/pull/22035

From dfuchs at openjdk.org  Tue Nov 12 19:09:05 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 12 Nov 2024 19:09:05 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
 <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
Message-ID: <q7TM5CcHL1xwt2zUOEIJBMnydCjEtJCZ9rpM2mo6X34=.90b0cf33-85aa-4958-a439-34e9a0a0492b@github.com>

On Tue, 12 Nov 2024 18:47:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Removes the SecurityManager usage from Thread + friends.
>> 
>> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
>> 
>> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8343981
>  - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
>  - Initial commit
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...636ebd19

The proposed changes look reasonable to me. Good simplification of the code. I had some uncertainty about the JNDI changes but I couldn't find any place in JNDI where a Subject would be extracted from the ACC associated with the created thread so I'd say that looks fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22035#issuecomment-2471344812

From schernyshev at openjdk.org  Tue Nov 12 19:13:15 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 12 Nov 2024 19:13:15 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
Message-ID: <hjzngEKOK9HJpZwhhhxtIL0al3rZMxfvQr0vJrQYqNs=.1f838f68-e296-49d6-8e16-c204bedf51b6@github.com>

On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343191
>  - patch reimplemented
>  - fix the logic that skips duplicate controller's mount points
>  - 8343191: Cgroup v1 subsystem fails to set subsystem path

> Edit: Yet, cg v2 will get into trouble since there, for example on rootless podman on cg v2 you'd end up with this instead:
> 
> ```
> [0.008s][trace][os,container] OSContainer::init: Initializing Container Support
> [0.008s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> [0.008s][debug][os,container] Detected cgroups v2 unified hierarchy
> [0.008s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/../../../../../../test
> [0.008s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../../../../../test/memory.max
> [0.008s][debug][os,container] Open of file /sys/fs/cgroup/../../../../../../test/memory.max failed, No such file or directory
> [0.008s][trace][os,container] Memory Limit failed: -2
> ...
> [0.009s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max
> [0.009s][debug][os,container] Open of file /sys/fs/cgroup/memory.max failed, No such file or directory
> [0.009s][trace][os,container] Memory Limit failed: -2
> [0.009s][trace][os,container] Memory Limit is: -2
> ```

Here, the path `/sys/fs/cgroup/memory.max` would normally point to the actual memory limit inside the container. In this particular case, the directory `/sys/fs/cgroup` is empty.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2471350885

From aturbanov at openjdk.org  Tue Nov 12 19:16:52 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Nov 2024 19:16:52 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v3]
In-Reply-To: <_l0gpT2MUp35D4wOdhoMNFu-eO8JZKGQ-bhXp96FUa4=.19b84cdd-194d-46fe-85f7-a3add683de60@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <_l0gpT2MUp35D4wOdhoMNFu-eO8JZKGQ-bhXp96FUa4=.19b84cdd-194d-46fe-85f7-a3add683de60@github.com>
Message-ID: <POKOvcIQTSHCIkkU5Ab1qmH3xzkesP5Na2-Q7ligb2Q=.7ad09464-1dbe-4806-a5d8-331e5da8e351@github.com>

On Tue, 12 Nov 2024 18:05:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits:
> 
>  - Merge branch 'master' into 8343958-process-sm-cleanup
>  - correct exception message formatting
>  - Simplify the generation of the exception message.
>    The file path is always included in the exception, the IOException cause does not add useful information.
>  - Remove security manager impl in java.lang.Process and java.lang.Runtime.exec
>    Refactor to remove the dependencies on SecurityManager, doPrivileged, and AccessController.
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - ... and 218 more: https://git.openjdk.org/jdk/compare/63eb4853...4535e388

src/java.base/windows/classes/java/lang/ProcessImpl.java line 425:

> 423:     {
> 424:         String cmdstr;
> 425:         final String value = System.getProperty("jdk.lang.Process.allowAmbiguousCommands", "true" ));

Suggestion:

        final String value = System.getProperty("jdk.lang.Process.allowAmbiguousCommands", "true"));

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838634456

From alanb at openjdk.org  Tue Nov 12 19:17:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 19:17:20 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v8]
In-Reply-To: <qJYjN6knDdG1OXt_Mcl16BS4QDag42Q56WyLMIrnsfQ=.93206a91-12e3-4956-8d65-dd8cb43429da@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <eIEgRZ2s1iXAt0zCF2uZSnIN8nUIWC1w4GmuXTn5C8s=.efdcdce8-33a3-45f9-8bff-58b512a61826@github.com>
 <qJYjN6knDdG1OXt_Mcl16BS4QDag42Q56WyLMIrnsfQ=.93206a91-12e3-4956-8d65-dd8cb43429da@github.com>
Message-ID: <wWkcI3Rb2BKJzbgGxllnwSsUzOHpGhK8eSDWxQUTEOo=.db3af62d-f23f-428e-a001-5b4ebaf586c6@github.com>

On Tue, 12 Nov 2024 18:28:33 GMT, Kevin Bourrillion <duke at openjdk.org> wrote:

> About the version string: I think I first proposed including it. If we don't, then I think that `-version` ought to be in the shortlist of options we show here (not just in full help), so it doesn't become a _three_ step goose chase for the user to find it.
> 
> To me, it feels more user-friendly to just give the version, than to tell the user how they can ask for it and make them ask again. And it seems to take about the same amount of space either way. But maybe there are counterarguments I don't know of.

I'm not opposed to it but if is printed then I think it should be the same as the first line of the java -version output. Believe it or not, the launcher has weirdness in this area where it prints slightly different version output when it's printing to stdout or stderr. The current changes in the PR use the format for stdout but it is printing to stderr. So maybe it will look better if that is fixed. To see what I mean, try `java` && `java -version` to see the difference.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2471358404

From rgiulietti at openjdk.org  Tue Nov 12 19:19:27 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 12 Nov 2024 19:19:27 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v14]
In-Reply-To: <d2e7-Tss4eKtho0Ar6VSccrm7QgwDWHmJulu18NmbZs=.a4b3d82a-ee67-4d81-b0d1-c76fdf289b9f@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <d2e7-Tss4eKtho0Ar6VSccrm7QgwDWHmJulu18NmbZs=.a4b3d82a-ee67-4d81-b0d1-c76fdf289b9f@github.com>
Message-ID: <cI01PAoVvRHCVuNQVPgI3Gb9Li2pkGqIbZVyVZL8kqo=.37580c5b-9296-4ce5-bdbe-22f2554c4f65@github.com>

On Tue, 12 Nov 2024 18:40:34 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix bug parsing short inputs.

Looks good.
Approving the current status.
Are there plans for other small additions?

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21574#pullrequestreview-2430480054

From alanb at openjdk.org  Tue Nov 12 19:21:31 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 12 Nov 2024 19:21:31 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <q7TM5CcHL1xwt2zUOEIJBMnydCjEtJCZ9rpM2mo6X34=.90b0cf33-85aa-4958-a439-34e9a0a0492b@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
 <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
 <q7TM5CcHL1xwt2zUOEIJBMnydCjEtJCZ9rpM2mo6X34=.90b0cf33-85aa-4958-a439-34e9a0a0492b@github.com>
Message-ID: <b8ZOeJkJayxSrzBldznzDiCYUwMtMaKzsHRyu2Y7UsU=.3e60e53a-3b3a-4830-b0f3-45001f15f05f@github.com>

On Tue, 12 Nov 2024 19:06:31 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> The proposed changes look reasonable to me. Good simplification of the code. I had some uncertainty about the JNDI changes but I couldn't find any place in JNDI where a Subject would be extracted from the ACC associated with the created thread so I'd say that looks fine.

ACC is dead and Subject is re-implemented on ScopedValue now so I think we are okay. There will be many other places where we will also drop the capture and use of the ACC.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22035#issuecomment-2471365088

From aturbanov at openjdk.org  Tue Nov 12 19:24:40 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Tue, 12 Nov 2024 19:24:40 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v7]
In-Reply-To: <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <J4DO9njQBXcQ1IJrWVlxclYrzMQV1Nc0SzJ2JCevT6g=.29bf09e0-b696-4aae-92c0-59fa1e4579b0@github.com>
Message-ID: <013IDnPHZGWmc4UzSBT7XqM75Z1A75thB8ddw7WyULs=.66fd0968-f736-48c3-8aaf-d50d1d115b1f@github.com>

On Tue, 12 Nov 2024 16:30:12 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix copyright

src/java.base/share/classes/java/lang/StringLatin1.java line 833:

> 831:         assert index >= 0 && index + 3 < length(val) : "Trusted caller missed bounds check";
> 832:         // Don't use the putChar method, Its instrinsic will cause C2 unable to combining values into larger stores.
> 833:         long offset  = (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index;

Suggestion:

        long offset = (long) Unsafe.ARRAY_BYTE_BASE_OFFSET + index;

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22027#discussion_r1838642848

From rriggs at openjdk.org  Tue Nov 12 19:28:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 19:28:38 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time
Message-ID: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>

After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
Some refactoring to cleanup the remaining code is expected.

-------------

Commit messages:
 - Merge branch 'master' into 8344039-sm-cleanup-java-time
 - 8344039: Remove security manager dependency in java.time
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - ... and 216 more: https://git.openjdk.org/jdk/compare/63eb4853...96a8d26c

Changes: https://git.openjdk.org/jdk/pull/22042/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22042&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344039
  Stats: 78 lines in 2 files changed: 1 ins; 31 del; 46 mod
  Patch: https://git.openjdk.org/jdk/pull/22042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22042/head:pull/22042

PR: https://git.openjdk.org/jdk/pull/22042

From duke at openjdk.org  Tue Nov 12 19:35:51 2024
From: duke at openjdk.org (kabutz)
Date: Tue, 12 Nov 2024 19:35:51 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
 <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
Message-ID: <M2JoLgysYkeL2xLVp-gybrDFJRe00XRA0VxGw9Rv8d8=.0bafa449-a556-4b01-9b5f-1a20ad5e2eb7@github.com>

On Tue, 12 Nov 2024 15:41:36 GMT, kabutz <duke at openjdk.org> wrote:

>>> @kabutz I think @DougLea identified some potential edge-cases with the proposed solution, so I added his suggested diff to the JBS Issue for reference.
>> 
>> Indeed, I didn't check what happens when we create a spliterator on an empty collection.
>
>> @kabutz Let me know how you want to proceed. ?
> 
> 've made the changes and sent another PR to the branch holding the changes. Hope that's the right way of doing it...

> @kabutz The update for CSLM is based on @DougLea's proposal on the JBS issue, right? (Assuming that's the case I will add him as a co-contributor)

Yes, correct.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2471397105

From sgehwolf at openjdk.org  Tue Nov 12 19:43:28 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 19:43:28 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <hjzngEKOK9HJpZwhhhxtIL0al3rZMxfvQr0vJrQYqNs=.1f838f68-e296-49d6-8e16-c204bedf51b6@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <hjzngEKOK9HJpZwhhhxtIL0al3rZMxfvQr0vJrQYqNs=.1f838f68-e296-49d6-8e16-c204bedf51b6@github.com>
Message-ID: <lc7ZD5A7ZHQqF_EzCtiMFQbY0suiXqoUEwESZ1gu52U=.27ea7694-46d3-4902-8250-2cb20a66551f@github.com>

On Tue, 12 Nov 2024 19:09:54 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> > Edit: Yet, cg v2 will get into trouble since there, for example on rootless podman on cg v2 you'd end up with this instead:
> > ```
> > [0.008s][trace][os,container] OSContainer::init: Initializing Container Support
> > [0.008s][debug][os,container] Detected optional pids controller entry in /proc/cgroups
> > [0.008s][debug][os,container] Detected cgroups v2 unified hierarchy
> > [0.008s][trace][os,container] Adjusting controller path for memory: /sys/fs/cgroup/../../../../../../test
> > [0.008s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/../../../../../../test/memory.max
> > [0.008s][debug][os,container] Open of file /sys/fs/cgroup/../../../../../../test/memory.max failed, No such file or directory
> > [0.008s][trace][os,container] Memory Limit failed: -2
> > ...
> > [0.009s][trace][os,container] Path to /memory.max is /sys/fs/cgroup/memory.max
> > [0.009s][debug][os,container] Open of file /sys/fs/cgroup/memory.max failed, No such file or directory
> > [0.009s][trace][os,container] Memory Limit failed: -2
> > [0.009s][trace][os,container] Memory Limit is: -2
> > ```
> 
> Here, the path `/sys/fs/cgroup/memory.max` would normally point to the actual memory limit inside the container. In this particular case, the directory `/sys/fs/cgroup` is empty.

Yes. I believe we need to issue a `warning` log message if the `cgroup_path` includes `../` mentioning that memory limits might be wrong. There is nothing more we can do here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2471414814

From duke at openjdk.org  Tue Nov 12 19:50:39 2024
From: duke at openjdk.org (Kevin Bourrillion)
Date: Tue, 12 Nov 2024 19:50:39 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v8]
In-Reply-To: <eIEgRZ2s1iXAt0zCF2uZSnIN8nUIWC1w4GmuXTn5C8s=.efdcdce8-33a3-45f9-8bff-58b512a61826@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <eIEgRZ2s1iXAt0zCF2uZSnIN8nUIWC1w4GmuXTn5C8s=.efdcdce8-33a3-45f9-8bff-58b512a61826@github.com>
Message-ID: <ikXSBffHwQuJdUsa9wo23AjxbBEC61n0ySSG9r6XDhU=.39f1876f-96e3-4b4e-b3d3-ae552afd4760@github.com>

On Tue, 12 Nov 2024 13:17:13 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk 24-internal 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reflecting review feedback:
>   - using "conciseVersionString" intead of "shortVersionString"
>   - using <jarfile>.jar <jarfile>

Ohh, I think I was answering a question that was never asked then. You were just talking about which _form_ of the version string to use.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2471427873

From sgehwolf at openjdk.org  Tue Nov 12 19:53:42 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 19:53:42 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
Message-ID: <Pj2RF7Bt8ex1GEu_Xx7puFrfqiCfa82N930D0w5cv98=.e97e9992-483c-4ff9-b0d2-580ee8b488c6@github.com>

On Thu, 7 Nov 2024 22:31:21 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

>> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
>> 
>> The relevant /proc/self/mountinfo line is
>> 
>> 
>> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
>> 
>> 
>> /proc/self/cgroup:
>> 
>> 
>> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
>> 
>> 
>> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
>> 
>> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
>> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
>> 
>> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
>> 
>> Example input
>> 
>> _root = "/a"
>> cgroup_path = "/a/b"
>> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
>> 
>> 
>> result _path
>> 
>> "/sys/fs/cgroup/cpu,cpuacct/b"
>> 
>> 
>> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
>> 
>> 
>> ...
>>        /proc/pid/cgroup (since Linux 2.6.24)
>>               This file describes control groups to which the process
>>               with the corresponding PID belongs.  The displayed
>>               information differs for cgroups version 1 and version 2
>>               hierarchies.
>>               For each cgroup hierarchy of which the process is a
>>               member, there is one entry containing three colon-
>>               separated fields:
>> 
>>                   hierarchy-ID:controller-list:cgroup-path
>> 
>>               For example:
>> 
>>                   5:cpuacct,cpu,cpuset:/daemons
>> ...
>>               [3]  This field contains the pathname of the control group
>>                    in the hierarchy to which the process belongs. This
>>                    pathname is relative to the mount point of the
>>                    hierarchy.
>> 
>> 
>> This explicitly states the "pathname is relative t...
>
> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343191
>  - patch reimplemented
>  - fix the logic that skips duplicate controller's mount points
>  - 8343191: Cgroup v1 subsystem fails to set subsystem path

We really need to consider adding container tests for this use-case. Perhaps we can require root perms for it. The tricky part would be adding appropriate synchronization for the cgroup move of the shell process and subsequent `java` runs.

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 54:

> 52:     ss.print_raw(_mount_point);
> 53:     if (strcmp(_root, "/") == 0) {
> 54:       // host processes / containers w/private cgroup namespace

Suggestion:

      // host processes and containers with cgroupns=private

src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp line 62:

> 60:       // containers only, warn if doesn't match
> 61:       log_warning(os, container)("Cgroup v1 controller (%s) mounting root [%s] doesn't match cgroup [%s]",
> 62:         _mount_point, _root, cgroup_path);

Why this warning?

It appears it would make more sense to produce this warning when `cgroup_path` contains `../` and falling back to the `mount_path` for the subsystem path which indicates we have a `cgroupns=private` deployment on CG v1, but would likely get away with it since `memory.limit_in_bytes` will be present at the mount root.

If `cgroup_path` doesn't contain `../` we should append the `cgroup_path` to the `_mount_point` similar to what we do for cg v2. In the cloudflare case we'd end up with a subsystem path of `/sys/fs/cgroup/cpu,cpuacct/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c`. Since the `cgroup_path != _root` we trigger path adjustment increasing the chance to detect any lower limit in any of the paths down to the mount point.

src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 46:

> 44:     }
> 45: 
> 46:     public void setPath(String cgroupPath) {

This should behave the same as Hotspot and also append the cgroup path to the mount point. Then let [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) kick in to reduce it down to the mount point (if necessary).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21808#pullrequestreview-2430488512
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838641975
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838656361
PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838666453

From sgehwolf at openjdk.org  Tue Nov 12 19:53:42 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 12 Nov 2024 19:53:42 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <Lr-9yFtZLqJHHcItKkdkJq-dylhZ_8KqbKXRNBbpa5g=.a16eb44b-904a-45fe-8896-87a9ce29b7b1@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <XgUP3oTSxxBjeS0CJNMhixZP45NYBdsAOepkDuQvhz8=.66911e34-2b98-4e04-a0bc-f4b9ffed6c4b@github.com>
 <f-tvktrcHPdR9Tp1zRrI7rU7VPuQoaZrYKkZKZp0FD0=.185be49b-bba4-40ea-96c3-2cdad18fc06a@github.com>
 <SEqkoSF-Pa3JKDay_7yFrwxbQ_v51Cdn964bvVrGpfY=.e76dc454-0226-4917-9e71-1b8d01b92a8a@github.com>
 <Lr-9yFtZLqJHHcItKkdkJq-dylhZ_8KqbKXRNBbpa5g=.a16eb44b-904a-45fe-8896-87a9ce29b7b1@github.com>
Message-ID: <jv07QD8MePCxTNzjbA7950qF5d4vEB41ntd6-SD4WJ0=.0ef437c7-97da-4cca-87e3-1a7c1bd51d6e@github.com>

On Tue, 12 Nov 2024 14:59:41 GMT, Sergey Chernyshev <schernyshev at openjdk.org> wrote:

> > The JBS issue doesn't mention `NullPointerException`. It would be good to list the observed NPE issue.
> 
> Example for NPE:
> 
> ```
> public class Test {
>     public static void main(String[] args) {
>         java.lang.management.ManagementFactory.getPlatformMBeanServer();
>         System.out.println("PASSED.");
>     }
> }
> ```
> 
> Script (cg v1):
> 
> ```
> sudo docker run --tty=true --rm --volume=$JAVA_HOME:/jdk --volume=./classes:/classes:ro --memory 400m ubuntu:latest \
>     sh -c "sleep 10 ; /jdk/bin/java -cp .:/classes Test" &
> sleep 10;
> HOSTPID=$(sudo ps -ef | awk '/jdk/bin/java/ && !/docker/ && !/awk/ { print $2 }')
> echo $HOSTPID | sudo tee /sys/fs/cgroup/memory/test/cgroup.procs > /dev/null
> sleep 10
> ```
> 
> Result (cg v1 before patch):
> 
> ```
> Exception in thread "main" java.lang.NullPointerException
> 	at java.base/java.util.Objects.requireNonNull(Objects.java:220)
> 	at java.base/sun.nio.fs.UnixFileSystem.getPath(UnixFileSystem.java:296)
> 	at java.base/java.nio.file.Path.of(Path.java:148)
> 	at java.base/java.nio.file.Paths.get(Paths.java:69)
> 	at java.base/jdk.internal.platform.CgroupUtil.lambda$readStringValue$0(CgroupUtil.java:67)
> 	at java.base/java.security.AccessController.doPrivileged(AccessController.java:571)
> 	at java.base/jdk.internal.platform.CgroupUtil.readStringValue(CgroupUtil.java:69)
> 	at java.base/jdk.internal.platform.CgroupSubsystemController.getStringValue(CgroupSubsystemController.java:65)
> 	at java.base/jdk.internal.platform.CgroupSubsystemController.getLongValue(CgroupSubsystemController.java:124)
> 	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getLongValue(CgroupV1Subsystem.java:190)
> 	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getHierarchical(CgroupV1Subsystem.java:160)
> 	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.initSubSystem(CgroupV1Subsystem.java:85)
> 	at java.base/jdk.internal.platform.cgroupv1.CgroupV1Subsystem.getInstance(CgroupV1Subsystem.java:61)
> 	at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:119)
> 	at java.base/jdk.internal.platform.CgroupSubsystemFactory.create(CgroupSubsystemFactory.java:89)
> 	at java.base/jdk.internal.platform.CgroupMetrics.getInstance(CgroupMetrics.java:198)
> 	at java.base/jdk.internal.platform.SystemMetrics.instance(SystemMetrics.java:29)
> 	at java.base/jdk.internal.platform.Metrics.systemMetrics(Metrics.java:58)
> 	at java.base/jdk.internal.platform.Container.metrics(Container.java:43)
> 	at jdk.management/com.sun.management.internal.OperatingSystemImpl.<init>(OperatingSystemImpl.java:175)
> 	at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl.getOperatingSystemMXBean(PlatformMBeanProviderImpl.java:316)
> 	at jdk.management/com.sun.management.internal.PlatformMBeanProviderImpl$4.nameToMBeanMap(PlatformMBeanProviderImpl.java:235)
> 	at java.management/java.lang.management.ManagementFactory.lambda$getPlatformMBeanServer$0(ManagementFactory.java:489)
> 	at java.base/java.util.stream.ReferencePipeline$7$1FlatMap.accept(ReferencePipeline.java:289)
> 	at java.base/java.util.stream.ReferencePipeline$2$1.accept(ReferencePipeline.java:197)
> 	at java.base/java.util.HashMap$ValueSpliterator.forEachRemaining(HashMap.java:1788)
> 	at java.base/java.util.stream.AbstractPipeline.copyInto(AbstractPipeline.java:570)
> 	at java.base/java.util.stream.AbstractPipeline.wrapAndCopyInto(AbstractPipeline.java:560)
> 	at java.base/java.util.stream.ForEachOps$ForEachOp.evaluateSequential(ForEachOps.java:153)
> 	at java.base/java.util.stream.ForEachOps$ForEachOp$OfRef.evaluateSequential(ForEachOps.java:176)
> 	at java.base/java.util.stream.AbstractPipeline.evaluate(AbstractPipeline.java:265)
> 	at java.base/java.util.stream.ReferencePipeline.forEach(ReferencePipeline.java:636)
> 	at java.management/java.lang.management.ManagementFactory.getPlatformMBeanServer(ManagementFactory.java:490)
> 	at Test.main(Test.java:3)
> ```

Thanks!

> After patch:
> 
> ```
> [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test]
> [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/]
> [0.001s][warning][os,container] Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/]
> Nov 12, 2024 1:14:11 PM jdk.internal.platform.cgroupv1.CgroupV1SubsystemController setPath
> WARNING: Cgroup v1 controller (/sys/fs/cgroup/memory) mounting root [/docker/e7ecd9685bcbbd3e7d3e81ad7c23cadf5d96db85c324f66d290f0d289ad867dd] doesn't match cgroup [/test].
> PASSED.
> ```
> 
> In cg v2 the NPE is not observed.
> 
> > > Only when docker fails to mount the cgroup while moving process to an outer group or a sibling group. It's probably not the case with CloudFoundry.
> > 
> > 
> > The bug suggests it's a cg v1 only problem, but I'm able to reproduce in cg v2 too. We should handle both cases more gracefully.
> 
> what gets reproduced in cg v2 is in fact a different issue, the cgroup files are not mapped inside the container. Nothing can be done in Java to overcome this. There are no files in /sys/fs/cgroup.

Yes. A warning in that case would be good.

> The only workaround is --cgroupns=host, then the correct limits are displayed.

Right. We should aim for cg v1 to behave similar to this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21808#issuecomment-2471433485

From schernyshev at openjdk.org  Tue Nov 12 19:56:25 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 12 Nov 2024 19:56:25 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v4]
In-Reply-To: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
Message-ID: <Kk-wGwjNKzecGaxZLGwfE5S9egTL1KiV1Wco7rawuMQ=.c75d0cfd-92f7-4cf6-9bc1-86fe062750ff@github.com>

> Cgroup V1 subsustem fails to initialize mounted controllers properly in certain cases, that may lead to controllers left undetected/inactive. We observed the behavior in CloudFoundry deployments, it affects also host systems.
> 
> The relevant /proc/self/mountinfo line is
> 
> 
> 2207 2196 0:43 /system.slice/garden.service/garden/good/2f57368b-0eda-4e52-64d8-af5c /sys/fs/cgroup/cpu,cpuacct ro,nosuid,nodev,noexec,relatime master:25 - cgroup cgroup rw,cpu,cpuacct
> 
> 
> /proc/self/cgroup:
> 
> 
> 11:cpu,cpuacct:/system.slice/garden.service/garden/bad/2f57368b-0eda-4e52-64d8-af5c
> 
> 
> Here, Java runs inside containerized process that is being moved cgroups due to load balancing.
> 
> Let's examine the condition at line 64 here https://github.com/openjdk/jdk/blob/55a7cf14453b6cd1de91362927b2fa63cba400a1/src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp#L59-L72
> It is always FALSE and the branch is never taken. The issue was spotted earlier by @jerboaa in [JDK-8288019](https://bugs.openjdk.org/browse/JDK-8288019). 
> 
> The original logic was intended to find the common prefix of `_root`and `cgroup_path` and concatenate the remaining suffix to the `_mount_point` (lines 67-68). That could lead to the following results: 
> 
> Example input
> 
> _root = "/a"
> cgroup_path = "/a/b"
> _mount_point = "/sys/fs/cgroup/cpu,cpuacct"
> 
> 
> result _path
> 
> "/sys/fs/cgroup/cpu,cpuacct/b"
> 
> 
> Here, cgroup_path comes from /proc/self/cgroup 3rd column. The man page (https://man7.org/linux/man-pages/man7/cgroups.7.html#NOTES) for control groups states:
> 
> 
> ...
>        /proc/pid/cgroup (since Linux 2.6.24)
>               This file describes control groups to which the process
>               with the corresponding PID belongs.  The displayed
>               information differs for cgroups version 1 and version 2
>               hierarchies.
>               For each cgroup hierarchy of which the process is a
>               member, there is one entry containing three colon-
>               separated fields:
> 
>                   hierarchy-ID:controller-list:cgroup-path
> 
>               For example:
> 
>                   5:cpuacct,cpu,cpuset:/daemons
> ...
>               [3]  This field contains the pathname of the control group
>                    in the hierarchy to which the process belongs. This
>                    pathname is relative to the mount point of the
>                    hierarchy.
> 
> 
> This explicitly states the "pathname is relative to the mount point of the hierarchy". Hence, the correct result could have been
> 
> 
> /sys/fs/cgroup/cpu,cpuacct/a/b
> 
> 
> Howe...

Sergey Chernyshev has updated the pull request incrementally with one additional commit since the last revision:

  Update src/hotspot/os/linux/cgroupV1Subsystem_linux.cpp
  
  Co-authored-by: Severin Gehwolf <jerboaa at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21808/files
  - new: https://git.openjdk.org/jdk/pull/21808/files/3bb779af..c808ad49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21808&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21808.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21808/head:pull/21808

PR: https://git.openjdk.org/jdk/pull/21808

From mullan at openjdk.org  Tue Nov 12 20:49:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 12 Nov 2024 20:49:23 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v3]
In-Reply-To: <_l0gpT2MUp35D4wOdhoMNFu-eO8JZKGQ-bhXp96FUa4=.19b84cdd-194d-46fe-85f7-a3add683de60@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <_l0gpT2MUp35D4wOdhoMNFu-eO8JZKGQ-bhXp96FUa4=.19b84cdd-194d-46fe-85f7-a3add683de60@github.com>
Message-ID: <Nme1smuq9InxDOK1B6KLwR2g84L1CryF2OLWDVNuQqw=.e77f9547-6101-4654-971b-f438a74c5498@github.com>

On Tue, 12 Nov 2024 18:05:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits:
> 
>  - Merge branch 'master' into 8343958-process-sm-cleanup
>  - correct exception message formatting
>  - Simplify the generation of the exception message.
>    The file path is always included in the exception, the IOException cause does not add useful information.
>  - Remove security manager impl in java.lang.Process and java.lang.Runtime.exec
>    Refactor to remove the dependencies on SecurityManager, doPrivileged, and AccessController.
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - ... and 218 more: https://git.openjdk.org/jdk/compare/63eb4853...4535e388

src/java.base/unix/classes/java/lang/ProcessEnvironment.java line 1:

> 1: /*

Why the copyright update? Nothing changed.

src/java.base/windows/classes/java/lang/ProcessImpl.java line 76:

> 74:     {
> 75:         if (append) {
> 76:             String path = f.getPath();

Is the SuppressWarnings annotation still needed on line 71?

src/java.base/windows/classes/java/lang/ProcessImpl.java line 422:

> 420:                         boolean forceNullOutputStream,
> 421:                         final boolean redirectErrorStream)
> 422:         throws IOException

Is the SuppressWarnings annotation still needed on line 415?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838731015
PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838734932
PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838735333

From darcy at openjdk.org  Tue Nov 12 21:04:37 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 21:04:37 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v15]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <AoKFjWjAbYy6t4zZpthp3HZdtsFXKPLgHUJtDyaXo8g=.8c49e931-21c6-4581-93f9-3f63b2cf8d5b@github.com>

> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.

Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:

  Cleanup pass on tests.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/5ed21469..d39575f0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=13-14

  Stats: 80 lines in 1 file changed: 7 ins; 20 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/21574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21574/head:pull/21574

PR: https://git.openjdk.org/jdk/pull/21574

From darcy at openjdk.org  Tue Nov 12 21:04:38 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 12 Nov 2024 21:04:38 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v14]
In-Reply-To: <cI01PAoVvRHCVuNQVPgI3Gb9Li2pkGqIbZVyVZL8kqo=.37580c5b-9296-4ce5-bdbe-22f2554c4f65@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <d2e7-Tss4eKtho0Ar6VSccrm7QgwDWHmJulu18NmbZs=.a4b3d82a-ee67-4d81-b0d1-c76fdf289b9f@github.com>
 <cI01PAoVvRHCVuNQVPgI3Gb9Li2pkGqIbZVyVZL8kqo=.37580c5b-9296-4ce5-bdbe-22f2554c4f65@github.com>
Message-ID: <u1YcJdMjsXERQmqKCBWjp1W0-q_IzfRSG4iH6nPoPAk=.579636f8-4bff-4839-810a-6bbabb024b25@github.com>

On Tue, 12 Nov 2024 19:15:45 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> Looks good. Approving the current status. Are there plans for other small additions?

Subsequent to this comment, I did a light clean-up pass over the tests. I'll do a pass over the Float16 implementation too to make sure previous comments are all addressed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2471573998

From vklang at openjdk.org  Tue Nov 12 21:13:16 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 12 Nov 2024 21:13:16 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <M2JoLgysYkeL2xLVp-gybrDFJRe00XRA0VxGw9Rv8d8=.0bafa449-a556-4b01-9b5f-1a20ad5e2eb7@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
 <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
 <M2JoLgysYkeL2xLVp-gybrDFJRe00XRA0VxGw9Rv8d8=.0bafa449-a556-4b01-9b5f-1a20ad5e2eb7@github.com>
Message-ID: <3UFiN6GbX1kVVcmoNX9xDLAL3i9lDsepFomLBCiF438=.5c695841-9366-41c4-90b5-6dadbc0ae348@github.com>

On Tue, 12 Nov 2024 19:31:21 GMT, kabutz <duke at openjdk.org> wrote:

>>> @kabutz Let me know how you want to proceed. ?
>> 
>> 've made the changes and sent another PR to the branch holding the changes. Hope that's the right way of doing it...
>
>> @kabutz The update for CSLM is based on @DougLea's proposal on the JBS issue, right? (Assuming that's the case I will add him as a co-contributor)
> 
> Yes, correct.

@kabutz The OpenJDK bot doesn't trust me :-) would you mind adding Doug as a contributor? :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2471587873

From almatvee at openjdk.org  Tue Nov 12 21:24:37 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 12 Nov 2024 21:24:37 GMT
Subject: RFR: 8342682: Errors related to unused code on Windows after
 8339120 in dt_shmem jdwp security and jpackage [v7]
In-Reply-To: <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
References: <iXLvZEu6nm6K4U2AEmPsEAUQFE0a8dLjbg3nORen0_I=.1e6dbd0d-aaa0-4d6e-894b-c1e1b749d7d5@github.com>
 <JtimSUcc6R8clIFNMPXACSRnLycNDi_WoG2zu_n_-1k=.51e77677-e676-4803-9e98-cdf29e08975a@github.com>
Message-ID: <IrROVW2SUDi-mK8lfev9uvRmIVJQQ1F14r-IOZM6yHw=.641a03d3-d44c-417b-ad01-135511b15a48@github.com>

On Mon, 11 Nov 2024 09:51:35 GMT, Julian Waters <jwaters at openjdk.org> wrote:

>> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did
>
> Julian Waters has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into unused
>  - Neater warning silencer in proc_md.h
>  - Revert _WIN32 workaround in log_messages.c
>  - Copyright in VersionInfo.cpp
>  - Remove neutralLangId in VersionInfo.cpp
>  - Remove global memHandle, would've liked to keep it as a comment :(
>  - Merge branch 'master' into unused
>  - 8342682

jpackage changes looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21616#pullrequestreview-2430719530

From dl at openjdk.org  Tue Nov 12 21:48:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 12 Nov 2024 21:48:54 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v25]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <OV20MMXk7ursVA9jhoyAUY5zjy52SGF45XCEgC3qgno=.5b0765a8-4bfc-4eaa-8868-ec097a7cf36d@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 46 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - Improve readbility; tweak runState checks
 - Address review comments
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reconcile internal docs; renamings
 - Minor improvements
 - Merge branch 'openjdk:master' into JDK-8336707
 - Add CLEANED runState
 - ... and 36 more: https://git.openjdk.org/jdk/compare/c66f1c0a...3ea2470c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/e1460f57..3ea2470c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=24
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=23-24

  Stats: 80125 lines in 2219 files changed: 10280 ins; 64527 del; 5318 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From dl at openjdk.org  Tue Nov 12 21:48:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 12 Nov 2024 21:48:54 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v24]
In-Reply-To: <NsnmmK9lrbjTuhhZ7vnZvetJZwqF0DJ8bxmfXzBsh8E=.464f9e79-652d-4e11-a33a-9b94f948a846@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <XvZ2q1QD4p4mN4DLaJZUvt_JVS3EbVSRQU90n9SmPtY=.137be678-a4c6-43d3-baa3-3e33324dd102@github.com>
 <NsnmmK9lrbjTuhhZ7vnZvetJZwqF0DJ8bxmfXzBsh8E=.464f9e79-652d-4e11-a33a-9b94f948a846@github.com>
Message-ID: <7uasZ4aAlr5dgXPr5nZM0LW1HT3RSSJuFMLLkKBmTd8=.02e6c185-dfa2-482d-a16f-27088dac98b9@github.com>

On Tue, 12 Nov 2024 14:14:18 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Address review comments
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1870:
> 
>> 1868:         else if ((phase = w.phase) != 0 && (phase & IDLE) != 0)
>> 1869:             releaseWaiters();              // ensure released
>> 1870:         if (w == null || w.source != DROPPED) {
> 
> @DougLea If this isn't intended to be an `else-if` I'd recommend adding a line of whitespace between it and the line above.

Thanks for the prod. While making the control flow here read better, I noticed that adding a leading runState check in registerWorker further reduced overhead a bit when shutdown occurs while still ramping up.

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1877:
> 
>> 1875:                                        (LMASK & c)))));
>> 1876:         }
>> 1877:         if (phase != 0 && w != null && (runState & STOP) == 0L) {
> 
> @DougLea If this isn't intended to be an else-if I'd recommend adding a line of whitespace between it and the line above.

now no more elses so less confuring

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2078:
> 
>> 2076:         w.phase = p;
>> 2077:         if (!compareAndSetCtl(pc, qc))        // try to enqueue
>> 2078:             return w.phase = phase;           // back out on possible signal
> 
> @DougLea We don't back out the stackPred change here, is that still valid? ?

yes. it's as if the deactivation didn't happen, so no need to increment version tag bits.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1838807759
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1838808625
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1838810950

From bpb at openjdk.org  Tue Nov 12 21:52:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 12 Nov 2024 21:52:10 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages from
 java.io
Message-ID: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>

Uses of `InternalLock` are removed and `sycnhronized` is reinstated.

-------------

Commit messages:
 - 8343039: Remove jdk.internal.misc.InternalLock and usages from java.io

Changes: https://git.openjdk.org/jdk/pull/22048/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343039
  Stats: 1379 lines in 11 files changed: 71 ins; 950 del; 358 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From bpb at openjdk.org  Tue Nov 12 21:52:10 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 12 Nov 2024 21:52:10 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <C_iVjDMjCamsFt54mSTItOv06JBX8Ox_poJiHxqpn2o=.178eb860-d744-4452-a56f-c12e60731133@github.com>

On Tue, 12 Nov 2024 21:45:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Uses of `InternalLock` are removed and `sycnhronized` is reinstated.

Dynamic buffer resizing in `BufferedOutputStream` and `BufferedWriter` is retained.

The `jdk.internal.access` classes `JavaIOPrintStreamAccess` and `JavaIOPrintWriterAccess` will be addressed by a subsequent request.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2471652163

From vlivanov at openjdk.org  Tue Nov 12 21:53:09 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Tue, 12 Nov 2024 21:53:09 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <IwXC8gTLD1LKFMu6DpulYxgbt5Zp1WTaL6Cc19V2dJw=.80a1e2a3-178b-4f10-9431-ea41e1c3ddd8@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
 <IwXC8gTLD1LKFMu6DpulYxgbt5Zp1WTaL6Cc19V2dJw=.80a1e2a3-178b-4f10-9431-ea41e1c3ddd8@github.com>
Message-ID: <chcOYl_NgVxCgglUI_Nt-nAw1HFLT6td8ab4K_aLfJU=.9bb5ca76-4a7c-421b-9dec-5206bb411b37@github.com>

On Sun, 10 Nov 2024 07:40:30 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I don't see a compelling reason to do so. IMO matcher functionality is more than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` + `has_int_inputs()` predicate. For `MulUIVL` you additionally do input rewiring (using `forward_masked_input`), but (1)  `AndV src (Replicate 0xFFFFFFFF))` operands can be easily detected on matcher side (with an extra AD instruction); and (2) such optimization is limited because it is valid only for `0xFFFFFFFF` case while `has_uint_inputs() == true` for `C <=  0xFFFFFFFF`.
>> 
>> So, IMO `MulIVL` and `MulUIVL` nodes just add noise in Ideal graph without improving situation during matching.
>
>> In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I don't see a compelling reason to do so. IMO matcher functionality is more than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` + `has_int_inputs()` predicate. For `MulUIVL` you additionally do input rewiring (using `forward_masked_input`), but (1) `AndV src (Replicate 0xFFFFFFFF))` operands can be easily detected on matcher side (with an extra AD instruction); and (2) such optimization is limited because it is valid only for `0xFFFFFFFF` case while `has_uint_inputs() == true` for `C <= 0xFFFFFFFF`.
>> 
>> So, IMO `MulIVL` and `MulUIVL` nodes just add noise in Ideal graph without improving situation during matching.
> 
> Hi @iwanowww ,
> Problem occurs only if AndV gets shared; in such a case, matcher will not be able to identify the constrained multiplication pattern and absorb the masking pattern. Specialized IR overrules such limitations and shields the pattern from downstream optimization passes, thereby removing any non-determinism. In addition, it facilitates forwarding inputs to the multiplier, the new IR is explicit in its semantics of considering only lower doublewords of quadword lanes for multiplication, hence we can safely save emitting redundant input masking instructions. We already have specialized IR nodes like MulAddVS2VINode and I see these new IR nodes similar to it.

@jatin-bhateja in case when `AndV` is shared, it can't be eliminated unless all users absorb it. For such cases, matcher can perform adhoc node cloning, but in this particular case it looks like an overkill either way. IMO the pattern is too niche to focus on it (either to justify input forwarding or adhoc handling on matcher side). 

It's good you mentioned `MulAddVS2VI`. On one hand, VNNI operations are more complex (similar to FMA), so such complexity *may* be justified there. On the other hand, it doesn't look like VNNI support in C2 age well. It is tied to auto-vectorizer and, by now, Vector API doesn't benefit from it. So, instead of doubling down on `MulAddVS2VI` path, I'd prefer to leave it aside and reimplement it later in a more maintainable manner.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2471654154

From rriggs at openjdk.org  Tue Nov 12 21:59:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 21:59:43 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v3]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <jyCXU7GrWAjKiTDOxdirzi_0VZDrkWQb5CzW_6sbn7s=.e8cb51cb-62f6-456c-8a3e-4d3563a2f951@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:

 - Cleanup of suppress warnings and caller sensitive from review comments.
 - Merge branch 'master' into 8344034-sm-removal-serialization
 - JDK-8344034: Remove security manager dependency in Serialization
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - Move remaining JEP 486 failing tests into correct groups.
 - Move JEP 486 failing tests into hotspot_runtime group.
 - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
 - Merge branch 'master' into jep486
 - Merge branch 'master' into jep486
 - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...3f850839

-------------

Changes: https://git.openjdk.org/jdk/pull/22041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=02
  Stats: 396 lines in 5 files changed: 7 ins; 301 del; 88 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From rriggs at openjdk.org  Tue Nov 12 22:12:30 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 12 Nov 2024 22:12:30 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
 <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
Message-ID: <XZZ3vsLFN-kpGdTi54qv5LL5Jye43MFORSC7wOL9f2I=.6730cf1e-da5d-4999-a917-9a72a8dd5784@github.com>

On Tue, 12 Nov 2024 18:47:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Removes the SecurityManager usage from Thread + friends.
>> 
>> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
>> 
>> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8343981
>  - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
>  - Initial commit
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...636ebd19

src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java line 111:

> 109: 
> 110:     Thread createThread(Runnable r) {
> 111:         return new Thread(r);

Can the refactoring go back to the callers of createThread() to just create threads themselves.
And remove this trivial method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22035#discussion_r1838835532

From asemenyuk at openjdk.org  Tue Nov 12 22:36:29 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 12 Nov 2024 22:36:29 GMT
Subject: RFR: 8343875: Minor improvements of jpackage test library
Message-ID: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>

The PR affects jpackage test library only. Changes:

- Removed dependencies on `java.io.File`. `java.io.File.pathSeparator` is still used as there is no better alternative.
- Use `TKit.concatMessages()` instead of `String.format()` in TKit.assert...() methods.
- Added unit tests for all TKit.assert...() modified methods.
- Added unit tests for `JavaAppDesc` class.
- Added `jdk.jpackage.test.TestSuite` class to automatically run all jpackage test library unit tests. This eliminates the need to add jtreg comments to every jpackage test library unit test java source.

-------------

Commit messages:
 - Bugfix
 - Extra empty lines removed
 - Blessed modifier order
 - Copyright year and trailing whitespaces fixed
 - Add unit tests for changes in TKit class.
 - Merge branch 'master' into java.io.File-cleanup
 - Bad merge fix
 - Merge branch 'master' into JDK-8343396
 - jpackag tests minor cleanup: use java.internal.util.OperatingSystem; stop using java.io.File

Changes: https://git.openjdk.org/jdk/pull/21995/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21995&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343875
  Stats: 536 lines in 11 files changed: 473 ins; 30 del; 33 mod
  Patch: https://git.openjdk.org/jdk/pull/21995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21995/head:pull/21995

PR: https://git.openjdk.org/jdk/pull/21995

From asemenyuk at openjdk.org  Tue Nov 12 22:36:29 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 12 Nov 2024 22:36:29 GMT
Subject: RFR: 8343875: Minor improvements of jpackage test library
In-Reply-To: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
References: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
Message-ID: <aLNd6OD6iA3wzR62zky-zf5tjoLK9vTPhFX60isxFTs=.a648d19d-2c01-4dde-8ce3-532de84b9880@github.com>

On Fri, 8 Nov 2024 23:57:58 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The PR affects jpackage test library only. Changes:
> 
> - Removed dependencies on `java.io.File`. `java.io.File.pathSeparator` is still used as there is no better alternative.
> - Use `TKit.concatMessages()` instead of `String.format()` in TKit.assert...() methods.
> - Added unit tests for all TKit.assert...() modified methods.
> - Added unit tests for `JavaAppDesc` class.
> - Added `jdk.jpackage.test.TestSuite` class to automatically run all jpackage test library unit tests. This eliminates the need to add jtreg comments to every jpackage test library unit test java source.

@sashamatveev ptal

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JavaAppDesc.java line 178:

> 176:         return Objects.equals(this.srcJavaPath, other.srcJavaPath);
> 177:     }
> 178: 

Netbeans generated code

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21995#issuecomment-2471725192
PR Review Comment: https://git.openjdk.org/jdk/pull/21995#discussion_r1835169118

From almatvee at openjdk.org  Tue Nov 12 23:02:34 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 12 Nov 2024 23:02:34 GMT
Subject: RFR: 8343875: Minor improvements of jpackage test library
In-Reply-To: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
References: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
Message-ID: <q80PPjbi1bPNUDcoF8RsgFiqzD_WNa4uWwJbcSfQnew=.29d20c50-b4aa-4a16-9bf4-786f3c9b9951@github.com>

On Fri, 8 Nov 2024 23:57:58 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The PR affects jpackage test library only. Changes:
> 
> - Removed dependencies on `java.io.File`. `java.io.File.pathSeparator` is still used as there is no better alternative.
> - Use `TKit.concatMessages()` instead of `String.format()` in TKit.assert...() methods.
> - Added unit tests for all TKit.assert...() modified methods.
> - Added unit tests for `JavaAppDesc` class.
> - Added `jdk.jpackage.test.TestSuite` class to automatically run all jpackage test library unit tests. This eliminates the need to add jtreg comments to every jpackage test library unit test java source.

Looks good with minor comment.

test/jdk/tools/jpackage/helpers-test/jdk/jpackage/test/TKitTest.java line 146:

> 144:                     }).toArray(String[]::new);
> 145:                 }
> 146:                 return new MethodCallConfig(method, args, expectFail,  effectiveExpectLog);

Extra space between `expectFail, effectiveExpectLog`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21995#pullrequestreview-2430900228
PR Review Comment: https://git.openjdk.org/jdk/pull/21995#discussion_r1838899686

From jvernee at openjdk.org  Tue Nov 12 23:16:15 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 12 Nov 2024 23:16:15 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v3]
In-Reply-To: <XKYOEauGPTGzkT4z7PvZPgs8B8mIppxeEq7h-s_SXMM=.3edde68d-c7a1-4aa6-97ec-40b7341397b0@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <XKYOEauGPTGzkT4z7PvZPgs8B8mIppxeEq7h-s_SXMM=.3edde68d-c7a1-4aa6-97ec-40b7341397b0@github.com>
Message-ID: <NnLYzFQUq5lD74naODisuOtPO33PwhHwrFx2zIjGQ9g=.8512c0e2-291d-455e-b178-b209cff2ef2f@github.com>

On Tue, 12 Nov 2024 18:00:01 GMT, Chen Liang <liach at openjdk.org> wrote:

>> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
>> 
>> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
>> 
>> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
>  - Update docs per suggestion
>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
>  - Add a test to ensure serializable lambda creation and basic execution in hidden classes
>  - Specify consequence
>  - 8343064: ClassFormatError: Illegal class name from InnerClassLambdaMetafactory

src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 244:

> 242:  * implementation class from unloading when the caller is a {@linkplain
> 243:  * MethodHandles.Lookup.ClassOption#STRONG hidden class} and is unloaded, or when
> 244:  * the returned call site is no longer strongly reachable.

I don't get the last part of the sentence here. When the call site is no longer reachable _that_ prevents the class from being unloaded?

I like the implNote though. Maybe: "This technique reduces heap memory use, but it prevents the implementation class from being unloaded independently of its defining class loader" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1838950278

From schernyshev at openjdk.org  Tue Nov 12 23:33:33 2024
From: schernyshev at openjdk.org (Sergey Chernyshev)
Date: Tue, 12 Nov 2024 23:33:33 GMT
Subject: RFR: 8343191: Cgroup v1 subsystem fails to set subsystem path [v3]
In-Reply-To: <Pj2RF7Bt8ex1GEu_Xx7puFrfqiCfa82N930D0w5cv98=.e97e9992-483c-4ff9-b0d2-580ee8b488c6@github.com>
References: <ewYuD7AKPZBkGxx7huXwAdeZH1Ke3BZ5wjLyqJgkRUg=.696010c5-7fd2-41d9-98f7-1de0eae6480f@github.com>
 <venNUhr0_oWPD3Jk8RurDHaG9lmnp5ozTmuMQI4lAYo=.c7eaad22-66bd-4f70-8ec6-076d812e5983@github.com>
 <Pj2RF7Bt8ex1GEu_Xx7puFrfqiCfa82N930D0w5cv98=.e97e9992-483c-4ff9-b0d2-580ee8b488c6@github.com>
Message-ID: <lYDiNahXCzv9TBqWvSQvUKemmO8F6tTcBaRz1VuSmeY=.310c5917-5f44-4142-8b16-b38ada5c3d25@github.com>

On Tue, 12 Nov 2024 19:41:50 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Sergey Chernyshev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8343191
>>  - patch reimplemented
>>  - fix the logic that skips duplicate controller's mount points
>>  - 8343191: Cgroup v1 subsystem fails to set subsystem path
>
> src/java.base/linux/classes/jdk/internal/platform/cgroupv1/CgroupV1SubsystemController.java line 46:
> 
>> 44:     }
>> 45: 
>> 46:     public void setPath(String cgroupPath) {
> 
> This should behave the same as Hotspot and also append the cgroup path to the mount point. Then let [JDK-8336881](https://bugs.openjdk.org/browse/JDK-8336881) kick in to reduce it down to the mount point (if necessary).

Correct. I double checked the behavior in cg v2:


sudo cgcreate -g memory:/test
sudo cgcreate -g memory:/test/test
sudo cgset -r memory.max=50m test
sudo cgset -r memory.swap.max=0 test
sudo cgset -r memory.max=100m test/test
sudo cgset -r memory.swap.max=0 test/test

with the above setup, allocations smaller than the outer group size will work, bigger will be oom-killed.


$ sudo cgexec -g memory:/test/test sh -c "head -c 45m /dev/zero | tail | wc -c"

47185920

$ sudo cgexec -g memory:/test/test sh -c "head -c 55m /dev/zero | tail | wc -c"

0
Killed


I'll update the PR next week.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21808#discussion_r1838979707

From swen at openjdk.org  Tue Nov 12 23:34:48 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Tue, 12 Nov 2024 23:34:48 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v8]
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  Update src/java.base/share/classes/java/lang/StringLatin1.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22027/files
  - new: https://git.openjdk.org/jdk/pull/22027/files/980cb229..e66578ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22027&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22027.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22027/head:pull/22027

PR: https://git.openjdk.org/jdk/pull/22027

From bchristi at openjdk.org  Tue Nov 12 23:36:14 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 12 Nov 2024 23:36:14 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v3]
In-Reply-To: <_l0gpT2MUp35D4wOdhoMNFu-eO8JZKGQ-bhXp96FUa4=.19b84cdd-194d-46fe-85f7-a3add683de60@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <_l0gpT2MUp35D4wOdhoMNFu-eO8JZKGQ-bhXp96FUa4=.19b84cdd-194d-46fe-85f7-a3add683de60@github.com>
Message-ID: <wwm7LOPMMJ6GHAs8mZmvku42f2k8xgrwEhUO7YmP9Uw=.ca48f82f-52ba-4224-96fa-96f946e870b3@github.com>

On Tue, 12 Nov 2024 18:05:46 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 228 commits:
> 
>  - Merge branch 'master' into 8343958-process-sm-cleanup
>  - correct exception message formatting
>  - Simplify the generation of the exception message.
>    The file path is always included in the exception, the IOException cause does not add useful information.
>  - Remove security manager impl in java.lang.Process and java.lang.Runtime.exec
>    Refactor to remove the dependencies on SecurityManager, doPrivileged, and AccessController.
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - ... and 218 more: https://git.openjdk.org/jdk/compare/63eb4853...4535e388

Changes requested by bchristi (Reviewer).

src/java.base/share/classes/java/lang/ProcessHandleImpl.java line 242:

> 240:      * @return The ProcessHandle for the pid if the process is alive;
> 241:      *         or {@code null} if the process ID does not exist in the native system.
> 242:      * @throws SecurityException if RuntimePermission("manageProcess") is not granted

I believe this @throws is no longer needed.

src/java.base/share/classes/java/lang/ProcessHandleImpl.java line 278:

> 276:      *
> 277:      * @return The ProcessHandle for the OS process.
> 278:      * @throws SecurityException if RuntimePermission("manageProcess") is not granted

Don't need this `@throws`

src/java.base/share/classes/java/lang/ProcessHandleImpl.java line 297:

> 295:      *         if the child process does not have a parent
> 296:      * @throws SecurityException           if permission is not granted by the
> 297:      *                                     security policy

Don't need the @throws

-------------

PR Review: https://git.openjdk.org/jdk/pull/22024#pullrequestreview-2430998748
PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838952133
PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838953880
PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1838954641

From davidalayachew at gmail.com  Tue Nov 12 23:37:48 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 12 Nov 2024 18:37:48 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>

Oh sure, I expect something like distinct() to pull everything. In order to
know if something is distinct, you have to do some variant of "check
against everyone else". Whether that is holding all instances in memory or
their hashes, it's clear from a glance that you will need to look at
everything, and therefore, pre-fetching makes intuitive sense to me.

I 100% did not expect terminal operations like findAny() or reduce() to
pull the whole data set. That was a complete whiplash for me. The method
findAny() advertises itself as a short-circuiting operation, so to find out
that it actually pulls the whole data set anyways was shocking.

And that was my biggest pain point -- looking at the documentation, it is
not clear to me at all that methods like findAny() would pull in all data
upon becoming parallel().

Do you think it would make sense to add documentation about this to the
javadocs for Stream/java.util.stream? Or maybe it is already there and I
misunderstood it (even after reading through it thoroughly over 5 times).


On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> >We are told how Streams can process unbounded data sets, but when it
> tries to do a findAny() with parallel(), it runs into an OOME because it
> fetched all the data ahead of time. In fact, almost of the terminal
> operations will hit an OOME in the exact same way if they are parallel and
> have a big enough data set. It's definitely not the end of the world, but
> it seems that I have to fit everything into a Collector and/or a Gatherer
> if I want to avoid pre-fetching everything.
>
> Yeah, I think it is important to distinguish "can process unbounded data
> sets" from "always able to process unbounded data sets".
>
> Some operations inherently need the end of the stream, so even something
> somple like: stream.distinct() or stream.sorted() can end up pulling in all
> data (which of course won't terminate).
>
> Fortunately, I think Gatherers can unlock much more situations where
> unbounded streams can be processed.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Tuesday, 12 November 2024 15:08
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
> as I thought of it.
>
>
> I hand-waved away the idea because I thought that the method would turn
> the stream pipeline parallel, thus, recreating the same problem I currently
> have of parallelism causing all of the elements to be fetched ahead of
> time, causing an OOME.
>
>
> It did NOT occur to me that the pipeline would stay sequential, and just
> kick these off sequentially, but have them executing in parallel. I can't
> see why I came to that incorrect conclusion. I have read the javadocs of
> this method several times. Though, to be fair, I came to the same,
> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
> until someone pointed out what the documentation was actually saying that I
> realized it's true properties.
>
> Thanks. That definitely solves at least part of my problem. Obviously, I
> would prefer to write to S3 in parallel too, but at the very least, the
> calculation part is being done in parallel. And worst case scenario, I can
> be really bad and just do the write to S3 in the mapConcurrent, and then
> just return the metadata of each write, and just bundle that up with
> collect.
>
>
> And that's ignoring the fact that I can just use the workaround too.
>
>
> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
> from a performance perspective, but is rather unintuitive to me from a
> usability perspective. We are told how Streams can process unbounded data
> sets, but when it tries to do a findAny() with parallel(), it runs into an
> OOME because it fetched all the data ahead of time. In fact, almost of the
> terminal operations will hit an OOME in the exact same way if they are
> parallel and have a big enough data set. It's definitely not the end of the
> world, but it seems that I have to fit everything into a Collector and/or a
> Gatherer if I want to avoid pre-fetching everything.
>
> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Have you considered Gatherers.mapConcurrent(?)?
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Tuesday, 12 November 2024 01:53
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> Good to know, ty vm.
>
> At the very least, I have this workaround. This will meet my needs for now.
>
> I guess my final question would be -- is this type of problem better
> suited to something besides parallel streams? Maybe an ExecutorService?
>
> Really, all I am doing is taking a jumbo file, splitting it into batches,
> and then doing some work on those batches. My IO speeds are pretty fast,
> and the compute work is non-trivial, so there is performance being left on
> the table if I give up parallelism. And I am in a position where completion
> time is very important to us.
>
> I just naturally assumed parallel streams were the right choice because
> the compute work is simple. A pure function that I can break out, and then
> call in a map. Once I do that, I just call forEach to write the batches
> back out to S3. Maybe I should look into a different part of the std lib
> instead because I am using the wrong tool for the job? My nose says
> ExecutorService, but I figure I should ask before I dive too deep in.
>
>
> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> You're most welcome!
>
> In a potential future where all intermediate operations are
> Gatherer-based, and all terminal operations are Collector-based, it would
> just work as expected. But with that said, I'm not sure it is practically
> achievable because some operations might not have the same
> performance-characteristics as before.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 18:32
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Thanks for the workaround. It's running beautifully.
>
> Is there a future where this island concept is extended to the rest of
> streams? Tbh, I don't fully understand it.
>
> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi David,
>
> This is the effect of how parallel streams are implemented, where
> different stages, which are not representible as a join-less Spliterator
> are executed as a series of "islands" where the next isn't started until
> the former has completed.
>
> If you think about it, parallelization of a Stream works best when the
> entire data set can be split amongst a set of worker threads, and that sort
> of implies that you want eager pre-fetch of data, so if your dataset does
> not fit in memory, that is likely to lead to less desirable outcomes.
>
> What I was able to do for Gatherers is to implement "gather(?) +
> collect(?)"-fusion so any number of consecutive gather(?)-operations
> immediately followed by a collect(?) is run in the same "island".
>
> So with that said, you could try something like the following:
>
> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>     *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> }
>
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .collect(forEach(eachList -> println(eachList.getFirst())));
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 14:52
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> elements
>
> And just to avoid the obvious question, I can hold about 30 batches in
> memory before the Out of Memory error occurs. So this is not an issue of my
> batch size being too high.
>
> But just to confirm, I set the batch size to 1, and it still ran into an
> out of memory error. So I feel fairly confident saying that the Gatherer is
> trying to grab all available data before sending any of it downstream.
>
> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Core Libs Dev Team,
>
> I was trying out Gatherers for a project at work, and ran into a rather
> sad scenario.
>
> I need to process a large file in batches. Each batch is small enough that
> I can hold it in memory, but I cannot hold the entire file (and thus, all
> of the batches) in memory at once.
>
> Looking at the Gatherers API, I saw windowFixed and thought that it would
> be a great match for my use case.
>
> However, when trying it out, I was disappointed to see that it ran out of
> memory very quickly. Here is my attempt at using it.
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .forEach(eachList -> println(eachList.getFirst()))
> ;
>
> As you can see, I am just splitting the file into batches, and printing
> out the first of each batch. This is purely for example's sake, of course.
> I had planned on building even more functionality on top of this, but I
> couldn't even get past this example.
>
> But anyways, not even a single one of them printed out. Which leads me to
> believe that it's pulling all of them in the Gatherer.
>
> I can get it to run successfully if I go sequentially, but not parallel.
> Parallel gives me that out of memory error.
>
> Is there any way for me to be able to have the Gatherer NOT pull in
> everything while still remaining parallel and unordered?
>
> Thank you for your time and help.
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241112/56a7a0bb/attachment-0001.htm>

From davidalayachew at gmail.com  Tue Nov 12 23:39:21 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 12 Nov 2024 18:39:21 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
Message-ID: <CAA9v-_NjqapgrR6M5Tb6P_JKnDg=MTi15K-1Du1KGoqmkVzFBQ@mail.gmail.com>

Apologies, I did not mean to add reduce(). Please ignore that part.

On Tue, Nov 12, 2024, 6:37?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Oh sure, I expect something like distinct() to pull everything. In order
> to know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
>
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
>
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
>
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
>
>
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
>> >We are told how Streams can process unbounded data sets, but when it
>> tries to do a findAny() with parallel(), it runs into an OOME because it
>> fetched all the data ahead of time. In fact, almost of the terminal
>> operations will hit an OOME in the exact same way if they are parallel and
>> have a big enough data set. It's definitely not the end of the world, but
>> it seems that I have to fit everything into a Collector and/or a Gatherer
>> if I want to avoid pre-fetching everything.
>>
>> Yeah, I think it is important to distinguish "can process unbounded data
>> sets" from "always able to process unbounded data sets".
>>
>> Some operations inherently need the end of the stream, so even something
>> somple like: stream.distinct() or stream.sorted() can end up pulling in all
>> data (which of course won't terminate).
>>
>> Fortunately, I think Gatherers can unlock much more situations where
>> unbounded streams can be processed.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Tuesday, 12 November 2024 15:08
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
>> as I thought of it.
>>
>>
>> I hand-waved away the idea because I thought that the method would turn
>> the stream pipeline parallel, thus, recreating the same problem I currently
>> have of parallelism causing all of the elements to be fetched ahead of
>> time, causing an OOME.
>>
>>
>> It did NOT occur to me that the pipeline would stay sequential, and just
>> kick these off sequentially, but have them executing in parallel. I can't
>> see why I came to that incorrect conclusion. I have read the javadocs of
>> this method several times. Though, to be fair, I came to the same,
>> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
>> until someone pointed out what the documentation was actually saying that I
>> realized it's true properties.
>>
>> Thanks. That definitely solves at least part of my problem. Obviously, I
>> would prefer to write to S3 in parallel too, but at the very least, the
>> calculation part is being done in parallel. And worst case scenario, I can
>> be really bad and just do the write to S3 in the mapConcurrent, and then
>> just return the metadata of each write, and just bundle that up with
>> collect.
>>
>>
>> And that's ignoring the fact that I can just use the workaround too.
>>
>>
>> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
>> from a performance perspective, but is rather unintuitive to me from a
>> usability perspective. We are told how Streams can process unbounded data
>> sets, but when it tries to do a findAny() with parallel(), it runs into an
>> OOME because it fetched all the data ahead of time. In fact, almost of the
>> terminal operations will hit an OOME in the exact same way if they are
>> parallel and have a big enough data set. It's definitely not the end of the
>> world, but it seems that I have to fit everything into a Collector and/or a
>> Gatherer if I want to avoid pre-fetching everything.
>>
>> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Have you considered Gatherers.mapConcurrent(?)?
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Tuesday, 12 November 2024 01:53
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> Good to know, ty vm.
>>
>> At the very least, I have this workaround. This will meet my needs for
>> now.
>>
>> I guess my final question would be -- is this type of problem better
>> suited to something besides parallel streams? Maybe an ExecutorService?
>>
>> Really, all I am doing is taking a jumbo file, splitting it into batches,
>> and then doing some work on those batches. My IO speeds are pretty fast,
>> and the compute work is non-trivial, so there is performance being left on
>> the table if I give up parallelism. And I am in a position where completion
>> time is very important to us.
>>
>> I just naturally assumed parallel streams were the right choice because
>> the compute work is simple. A pure function that I can break out, and then
>> call in a map. Once I do that, I just call forEach to write the batches
>> back out to S3. Maybe I should look into a different part of the std lib
>> instead because I am using the wrong tool for the job? My nose says
>> ExecutorService, but I figure I should ask before I dive too deep in.
>>
>>
>> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> You're most welcome!
>>
>> In a potential future where all intermediate operations are
>> Gatherer-based, and all terminal operations are Collector-based, it would
>> just work as expected. But with that said, I'm not sure it is practically
>> achievable because some operations might not have the same
>> performance-characteristics as before.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Monday, 11 November 2024 18:32
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Thanks for the workaround. It's running beautifully.
>>
>> Is there a future where this island concept is extended to the rest of
>> streams? Tbh, I don't fully understand it.
>>
>> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Hi David,
>>
>> This is the effect of how parallel streams are implemented, where
>> different stages, which are not representible as a join-less Spliterator
>> are executed as a series of "islands" where the next isn't started until
>> the former has completed.
>>
>> If you think about it, parallelization of a Stream works best when the
>> entire data set can be split amongst a set of worker threads, and that sort
>> of implies that you want eager pre-fetch of data, so if your dataset does
>> not fit in memory, that is likely to lead to less desirable outcomes.
>>
>> What I was able to do for Gatherers is to implement "gather(?) +
>> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> immediately followed by a collect(?) is run in the same "island".
>>
>> So with that said, you could try something like the following:
>>
>> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*)
>> {
>>     *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
>> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> }
>>
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .collect(forEach(eachList -> println(eachList.getFirst())));
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
>> David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Monday, 11 November 2024 14:52
>> *To:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> elements
>>
>> And just to avoid the obvious question, I can hold about 30 batches in
>> memory before the Out of Memory error occurs. So this is not an issue of my
>> batch size being too high.
>>
>> But just to confirm, I set the batch size to 1, and it still ran into an
>> out of memory error. So I feel fairly confident saying that the Gatherer is
>> trying to grab all available data before sending any of it downstream.
>>
>> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>> Hello Core Libs Dev Team,
>>
>> I was trying out Gatherers for a project at work, and ran into a rather
>> sad scenario.
>>
>> I need to process a large file in batches. Each batch is small enough
>> that I can hold it in memory, but I cannot hold the entire file (and thus,
>> all of the batches) in memory at once.
>>
>> Looking at the Gatherers API, I saw windowFixed and thought that it would
>> be a great match for my use case.
>>
>> However, when trying it out, I was disappointed to see that it ran out of
>> memory very quickly. Here is my attempt at using it.
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .forEach(eachList -> println(eachList.getFirst()))
>> ;
>>
>> As you can see, I am just splitting the file into batches, and printing
>> out the first of each batch. This is purely for example's sake, of course.
>> I had planned on building even more functionality on top of this, but I
>> couldn't even get past this example.
>>
>> But anyways, not even a single one of them printed out. Which leads me to
>> believe that it's pulling all of them in the Gatherer.
>>
>> I can get it to run successfully if I go sequentially, but not parallel.
>> Parallel gives me that out of memory error.
>>
>> Is there any way for me to be able to have the Gatherer NOT pull in
>> everything while still remaining parallel and unordered?
>>
>> Thank you for your time and help.
>> David Alayachew
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241112/7674eca1/attachment-0001.htm>

From liach at openjdk.org  Wed Nov 13 00:05:24 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 00:05:24 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v3]
In-Reply-To: <NnLYzFQUq5lD74naODisuOtPO33PwhHwrFx2zIjGQ9g=.8512c0e2-291d-455e-b178-b209cff2ef2f@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <XKYOEauGPTGzkT4z7PvZPgs8B8mIppxeEq7h-s_SXMM=.3edde68d-c7a1-4aa6-97ec-40b7341397b0@github.com>
 <NnLYzFQUq5lD74naODisuOtPO33PwhHwrFx2zIjGQ9g=.8512c0e2-291d-455e-b178-b209cff2ef2f@github.com>
Message-ID: <BIjPAsbyucO4yNCoRJzRhl2qfQf3v5H_T7wJx0_Vw0g=.7cfea631-9e08-450f-819d-b081c29420e9@github.com>

On Tue, 12 Nov 2024 23:13:16 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:
>> 
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
>>  - Update docs per suggestion
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into fix/lmf-hidden-serial-class-format
>>  - Add a test to ensure serializable lambda creation and basic execution in hidden classes
>>  - Specify consequence
>>  - 8343064: ClassFormatError: Illegal class name from InnerClassLambdaMetafactory
>
> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 244:
> 
>> 242:  * implementation class from unloading when the caller is a {@linkplain
>> 243:  * MethodHandles.Lookup.ClassOption#STRONG hidden class} and is unloaded, or when
>> 244:  * the returned call site is no longer strongly reachable.
> 
> I don't get the last part of the sentence here. When the call site is no longer reachable _that_ prevents the class from being unloaded?
> 
> I like the implNote though. Maybe: "This technique reduces heap memory use, but it prevents the implementation class from being unloaded independently of its defining class loader" ?

Re this sentence: I wish to indicate "caller is unloaded and impl class is unreachable elsewhere (besides in the ClassLoader)".  Maybe just "caller is unloaded" is fine. Thoughts on phrasing?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1839028569

From bchristi at openjdk.org  Wed Nov 13 00:32:44 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 13 Nov 2024 00:32:44 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <PLJ7i4mRNGvZilXMH4zT9nklkMrpgkQrPyZgOZIUlKg=.8f35cfa4-52ce-48d8-a86d-6894221c9e8a@github.com>

On Tue, 12 Nov 2024 16:00:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [ ] `all` tests in fastdebug

Changes requested by bchristi (Reviewer).

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 300:

> 298:                 return true;
> 299:             }
> 300:         }

It looks like the new `PhantomCleanableList.remove()` puts 100% trust in the correctness of the PhantomCleanable's `index`.

What would you think of adding some sort of check/assert that `list.get(phc.index) == phc` ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22043#pullrequestreview-2431221723
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1839073366

From naoto at openjdk.org  Wed Nov 13 01:29:30 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Nov 2024 01:29:30 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time
In-Reply-To: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
Message-ID: <H-acSZmNGKAB02bu6iv-6vsjZ0HaN5lEUzILQpdCi4M=.16ee08b6-43c4-41eb-ae2c-687d5775c0bf@github.com>

On Tue, 12 Nov 2024 15:41:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java line 147:

> 145:         // if the property java.time.zone.DefaultZoneRulesProvider is
> 146:         // set then its value is the class name of the default provider
> 147:         @SuppressWarnings("removal")

Should this SuppressWarnings be removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22042#discussion_r1839174201

From jiangli at openjdk.org  Wed Nov 13 01:44:13 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Wed, 13 Nov 2024 01:44:13 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <RMacEqw-EG630Un-DYa-lMKkRFNsItFUqzvvRf6dT64=.349aceb7-a266-4fbd-b11f-3420ba56fd81@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>
 <QEyhmjtUis_7E8umUO_S7CpGfLxFMCGcKpkYbqxyR-c=.52160107-9ba4-4884-a6d9-1bc208126e7c@github.com>
 <u2fHrEnR89C-zHBHVzzTWT9OxlkbWj-a653OQVhPTt4=.b9bf0775-d5fb-4aa5-b441-d4a8db85b15e@github.com>
 <RMacEqw-EG630Un-DYa-lMKkRFNsItFUqzvvRf6dT64=.349aceb7-a266-4fbd-b11f-3420ba56fd81@github.com>
Message-ID: <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com>

On Mon, 4 Nov 2024 21:30:10 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>>> I can confirm that with your patch, and clang, and a complete wipe + rebuild, the .java file loading works. I'm currently testing with gcc as well.
>> 
>> Good.
>>  
>> I tested using gcc.
>
> @jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much.

@magicus Just want to check if there's anything that you are waiting from me for this PR. My understanding is that you'll update the PR to fix the incremental build and debuginfo before the last review iteration. Please let me know if there are anything else. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2472135324

From asemenyuk at openjdk.org  Wed Nov 13 02:02:27 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 13 Nov 2024 02:02:27 GMT
Subject: RFR: 8343875: Minor improvements of jpackage test library [v2]
In-Reply-To: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
References: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
Message-ID: <GSeA54yjCO6KlBv6sttbCTIL08V3Wy1ft5tWX3kZOkc=.9c67b2b2-ebac-4ef8-bd8f-cef316db600f@github.com>

> The PR affects jpackage test library only. Changes:
> 
> - Removed dependencies on `java.io.File`. `java.io.File.pathSeparator` is still used as there is no better alternative.
> - Use `TKit.concatMessages()` instead of `String.format()` in TKit.assert...() methods.
> - Added unit tests for all TKit.assert...() modified methods.
> - Added unit tests for `JavaAppDesc` class.
> - Added `jdk.jpackage.test.TestSuite` class to automatically run all jpackage test library unit tests. This eliminates the need to add jtreg comments to every jpackage test library unit test java source.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant space char

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21995/files
  - new: https://git.openjdk.org/jdk/pull/21995/files/7f76e829..c669b243

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21995&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21995&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21995.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21995/head:pull/21995

PR: https://git.openjdk.org/jdk/pull/21995

From jpai at openjdk.org  Wed Nov 13 02:06:53 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Nov 2024 02:06:53 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v6]
In-Reply-To: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
Message-ID: <48fzkhp189x6wY3Px-rG6oPf_-KlxcHi4GhbghZScAU=.e26a88f4-e5d1-4fb2-9d36-3ac0dd31eecc@github.com>

> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
> 
> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
> 
> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - 8341184: Clean up the interaction between the launcher native code and the LauncherHelper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21256/files
  - new: https://git.openjdk.org/jdk/pull/21256/files/8443861f..47e3c33a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=04-05

  Stats: 86138 lines in 2304 files changed: 15059 ins; 65510 del; 5569 mod
  Patch: https://git.openjdk.org/jdk/pull/21256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256

PR: https://git.openjdk.org/jdk/pull/21256

From almatvee at openjdk.org  Wed Nov 13 02:12:33 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 13 Nov 2024 02:12:33 GMT
Subject: RFR: 8343875: Minor improvements of jpackage test library [v2]
In-Reply-To: <GSeA54yjCO6KlBv6sttbCTIL08V3Wy1ft5tWX3kZOkc=.9c67b2b2-ebac-4ef8-bd8f-cef316db600f@github.com>
References: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
 <GSeA54yjCO6KlBv6sttbCTIL08V3Wy1ft5tWX3kZOkc=.9c67b2b2-ebac-4ef8-bd8f-cef316db600f@github.com>
Message-ID: <WdPOQbLSonk9FV369RLZdsbdSmG2BmylUnUs1SCkf08=.d1b75c0f-9000-443b-8db9-b3dac430046f@github.com>

On Wed, 13 Nov 2024 02:02:27 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> The PR affects jpackage test library only. Changes:
>> 
>> - Removed dependencies on `java.io.File`. `java.io.File.pathSeparator` is still used as there is no better alternative.
>> - Use `TKit.concatMessages()` instead of `String.format()` in TKit.assert...() methods.
>> - Added unit tests for all TKit.assert...() modified methods.
>> - Added unit tests for `JavaAppDesc` class.
>> - Added `jdk.jpackage.test.TestSuite` class to automatically run all jpackage test library unit tests. This eliminates the need to add jtreg comments to every jpackage test library unit test java source.
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant space char

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21995#pullrequestreview-2431546000

From rriggs at openjdk.org  Wed Nov 13 02:17:23 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 02:17:23 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v4]
In-Reply-To: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
Message-ID: <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>

> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Revert unnecessary copyright change in ProcessEnvironment.java.
  Fix code style in ProcessImpl
  Drop unneeded suppress warnings.
  Remove obsolete @throws SecurityExceptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22024/files
  - new: https://git.openjdk.org/jdk/pull/22024/files/4535e388..accc6df3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22024&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22024&range=02-03

  Stats: 8 lines in 3 files changed: 0 ins; 6 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22024/head:pull/22024

PR: https://git.openjdk.org/jdk/pull/22024

From jbhateja at openjdk.org  Wed Nov 13 02:43:12 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Nov 2024 02:43:12 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v4]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <6fxu6YabwpKc13hCZ7Aw46C02K68kozOCBZY3Rn8R8g=.c42f98dc-c253-4972-b2a5-ea8ff5e6061b@github.com>

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains seven commits:

 - Removing target specific hooks
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
 - Review resoultions
 - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
 - Handle new I2L pattern, IR tests, Rewiring pattern inputs to MulVL further optimizes JIT code
 - Review resolutions
 - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21244/files
  - new: https://git.openjdk.org/jdk/pull/21244/files/eba586b5..43320063

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=02-03

  Stats: 70 lines in 7 files changed: 3 ins; 58 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/21244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21244/head:pull/21244

PR: https://git.openjdk.org/jdk/pull/21244

From jbhateja at openjdk.org  Wed Nov 13 02:43:12 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Nov 2024 02:43:12 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <chcOYl_NgVxCgglUI_Nt-nAw1HFLT6td8ab4K_aLfJU=.9bb5ca76-4a7c-421b-9dec-5206bb411b37@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
 <IwXC8gTLD1LKFMu6DpulYxgbt5Zp1WTaL6Cc19V2dJw=.80a1e2a3-178b-4f10-9431-ea41e1c3ddd8@github.com>
 <chcOYl_NgVxCgglUI_Nt-nAw1HFLT6td8ab4K_aLfJU=.9bb5ca76-4a7c-421b-9dec-5206bb411b37@github.com>
Message-ID: <dFqlLphBRBLoKpRZfjxiIQ1X14t6bFRBPm2d1-Vmdmk=.290f86ad-85d4-42e5-895a-102c07e598d9@github.com>

On Tue, 12 Nov 2024 21:49:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I don't see a compelling reason to do so. IMO matcher functionality is more than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` + `has_int_inputs()` predicate. For `MulUIVL` you additionally do input rewiring (using `forward_masked_input`), but (1) `AndV src (Replicate 0xFFFFFFFF))` operands can be easily detected on matcher side (with an extra AD instruction); and (2) such optimization is limited because it is valid only for `0xFFFFFFFF` case while `has_uint_inputs() == true` for `C <= 0xFFFFFFFF`.
>>> 
>>> So, IMO `MulIVL` and `MulUIVL` nodes just add noise in Ideal graph without improving situation during matching.
>> 
>> Hi @iwanowww ,
>> Problem occurs only if AndV gets shared; in such a case, matcher will not be able to identify the constrained multiplication pattern and absorb the masking pattern. Specialized IR overrules such limitations and shields the pattern from downstream optimization passes, thereby removing any non-determinism. In addition, it facilitates forwarding inputs to the multiplier, the new IR is explicit in its semantics of considering only lower doublewords of quadword lanes for multiplication, hence we can safely save emitting redundant input masking instructions. We already have specialized IR nodes like MulAddVS2VINode and I see these new IR nodes similar to it.
>
> @jatin-bhateja in case when `AndV` is shared, it can't be eliminated unless all users absorb it. For such cases, matcher can perform adhoc node cloning, but in this particular case it looks like an overkill either way. IMO the pattern is too niche to focus on it (either to justify input forwarding or adhoc handling on matcher side). 
> 
> It's good you mentioned `MulAddVS2VI`. On one hand, VNNI operations are more complex (similar to FMA), so such complexity *may* be justified there. On the other hand, it doesn't look like VNNI support in C2 age well. It is tied to auto-vectorizer and, by now, Vector API doesn't benefit from it. So, instead of doubling down on `MulAddVS2VI` path, I'd prefer to leave it aside and reimplement it later in a more maintainable manner.

Thanks @iwanowww , Patch in its current form addresses several common patterns, and focusing on optimizing one niche case looks like an overkill,  given that we are strength reducing 15 cycle multiplier with a lighter 5-cycle version is itself sufficient to offset redundant input masking instructions.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2472244154

From duke at openjdk.org  Wed Nov 13 02:47:13 2024
From: duke at openjdk.org (ExE Boss)
Date: Wed, 13 Nov 2024 02:47:13 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <HP2XEWaLo6mAVeHMebLOvCb48fvYUliap9VadXcf6kk=.a06d8f7c-8369-4942-83d2-6395c7005d62@github.com>

On Tue, 12 Nov 2024 21:45:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

src/java.base/share/classes/java/io/BufferedInputStream.java line 241:

> 239:         }
> 240:         initialSize = size;
> 241:         buf = new byte[size];

This?should probably still?retain the?lazy?buffer array?creation:
Suggestion:

size;
        if (getClass() == BufferedInputStream.class) {
            // lazily create buffer when not subclassed
            buf = EMPTY;
        } else {
            // eagerly create buffer when subclassed
            buf = new byte[size];
        }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1839298849

From liach at openjdk.org  Wed Nov 13 03:20:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 03:20:51 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <uJYNUluaPl_8vhs8y5Y0AjwmwidsiAo_UumjENbM-TY=.335f062e-ddf3-49c4-9c2c-f1acd9a21527@github.com>

On Tue, 12 Nov 2024 21:45:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

https://github.com/openjdk/jdk/tree/5212535a276a92d96ca20bdcfccfbce956febdb1 is a baseline for before virtual threads were integrated.  Note that in this period, there are other optimizations such as lazy allocation for buffer arrays or some jfr changes, so these aren't exact matches.

src/java.base/share/classes/java/io/BufferedOutputStream.java line 88:

> 86:         }
> 87: 
> 88:         this.buf = new byte[initialSize]; // resizable if initialSize < maxSize

Same remark as for BIS.

Also this initial vs max size feature was added when virtual thread was first implemented as the internal locks.  Is this implementation detail still necessary for the virtual threads?

src/java.base/share/classes/java/io/Writer.java line 279:

> 277:     public void write(String str, int off, int len) throws IOException {
> 278:         synchronized (lock) {
> 279:             char cbuf[];

As annoying as this is, but https://bugs.openjdk.org/browse/JDK-8272626 didn't fix c-style arrays in method bodies.  Sad.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22048#pullrequestreview-2431668566
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1839327857
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1839331137

From liach at openjdk.org  Wed Nov 13 03:20:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 03:20:53 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <HP2XEWaLo6mAVeHMebLOvCb48fvYUliap9VadXcf6kk=.a06d8f7c-8369-4942-83d2-6395c7005d62@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <HP2XEWaLo6mAVeHMebLOvCb48fvYUliap9VadXcf6kk=.a06d8f7c-8369-4942-83d2-6395c7005d62@github.com>
Message-ID: <2ka9z_C4pBuT1MCTSD-i-C4RXKVQgC0S-X_1bhD9jrg=.160f227e-1188-4203-a54a-d3fc254100f2@github.com>

On Wed, 13 Nov 2024 02:41:05 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> src/java.base/share/classes/java/io/BufferedInputStream.java line 241:
> 
>> 239:         }
>> 240:         initialSize = size;
>> 241:         buf = new byte[size];
> 
> This?should probably still?retain the?lazy?buffer array?creation:
> Suggestion:
> 
> size;
>         if (getClass() == BufferedInputStream.class) {
>             // lazily create buffer when not subclassed
>             buf = EMPTY;
>         } else {
>             // eagerly create buffer when subclassed
>             buf = new byte[size];
>         }

Indeed.  This and that for BufferedOutputStream are for backward compatibility with subclasses.  We cannot control when subclasses access the `buf` field after the constructor call, so laziness was impossible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1839323249

From david.holmes at oracle.com  Wed Nov 13 03:44:34 2024
From: david.holmes at oracle.com (David Holmes)
Date: Wed, 13 Nov 2024 13:44:34 +1000
Subject: RFC: Introduce JDK property jdk.patched for indicating
 --patch-module at runtime
In-Reply-To: <7c5c3044b4d69113892ac6c9970a7d8b0af11900.camel@redhat.com>
References: <7c5c3044b4d69113892ac6c9970a7d8b0af11900.camel@redhat.com>
Message-ID: <f4abceef-6154-4e75-80e2-bd15cbe05f1b@oracle.com>

Hi Severin,

On 13/11/2024 1:33 am, Severin Gehwolf wrote:
> Hi,
> 
> For JDK-8343839 it would be useful to have some form of API in order to
> be able to detect that a currently running Java process has been
> launched with '--patch-module'.
> 
> Alan Bateman suggested to expose a boolean JDK property to indicate a
> runtime that has been launched with --patch-module. In particular, the
> suggestion was to use 'jdk.patched' which would be set to true iff
> --patch-module is present when the java process launched.

The VM already sets properties like

  jdk.module.patch.N=<...>

when processing --patch-mods. Doesn't that suffice if all you need is a 
boolean flag to indicate any patching has occurred?

I would have thought you'd like to know which module has been patched, 
or to be able to ask if a given module has been patch - in which case an 
actual API method on java.lang.Module would seem reasonable. Or is this 
an area where module patching is only part of the implementation of 
Modules in the JDK, not part of the actual Java SE Module specification?

Cheers,
David
-----

> The added benefit would be to have this information available via
> serviceability tools as well. For example, -XshowSettings:properties
> would be able to show this new property.
> 
> Thoughts? Concerns?
> 
> Thanks,
> Severin
> 
> 


From darcy at openjdk.org  Wed Nov 13 05:40:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 13 Nov 2024 05:40:24 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v16]
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <lGzuOoQml6iOyw18fvZdxINUtFdXNfDaHpq-CQSAsq8=.5a0007d3-11a2-46ba-8d85-49e11b02e3f8@github.com>

> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.

Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:

 - Implement code review feedback.
 - Misc cleanups.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21574/files
  - new: https://git.openjdk.org/jdk/pull/21574/files/d39575f0..818d6ec1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21574&range=14-15

  Stats: 39 lines in 2 files changed: 17 ins; 7 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/21574.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21574/head:pull/21574

PR: https://git.openjdk.org/jdk/pull/21574

From darcy at openjdk.org  Wed Nov 13 05:40:24 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 13 Nov 2024 05:40:24 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v14]
In-Reply-To: <u1YcJdMjsXERQmqKCBWjp1W0-q_IzfRSG4iH6nPoPAk=.579636f8-4bff-4839-810a-6bbabb024b25@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <d2e7-Tss4eKtho0Ar6VSccrm7QgwDWHmJulu18NmbZs=.a4b3d82a-ee67-4d81-b0d1-c76fdf289b9f@github.com>
 <cI01PAoVvRHCVuNQVPgI3Gb9Li2pkGqIbZVyVZL8kqo=.37580c5b-9296-4ce5-bdbe-22f2554c4f65@github.com>
 <u1YcJdMjsXERQmqKCBWjp1W0-q_IzfRSG4iH6nPoPAk=.579636f8-4bff-4839-810a-6bbabb024b25@github.com>
Message-ID: <2i3Tu7cJb4R3YOPxf_XvOhby4gPUQKl1n4s6UtzMEQ8=.4c75e0e5-e2c2-4ec2-85d7-dfa33b19110a@github.com>

On Tue, 12 Nov 2024 21:01:36 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> > Looks good. Approving the current status. Are there plans for other small additions?
> 
> Subsequent to this comment, I did a light clean-up pass over the tests. I'll do a pass over the Float16 implementation too to make sure previous comments are all addressed.

PS Pushed another clean-up pass over the implementation and tests.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21574#issuecomment-2472437931

From jbhateja at openjdk.org  Wed Nov 13 05:50:49 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Nov 2024 05:50:49 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
Message-ID: <vZV35ckouuZV-_7dcqf1beBbusFld507_VqkVG0Pymw=.f89d1268-1f65-44fe-af45-94543299be31@github.com>

On Wed, 30 Oct 2024 05:25:47 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Respond to review feedback.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 91:

> 89: // JEP-401 (https://openjdk.org/jeps/401).
> 90: // @jdk.internal.MigratedValueClass
> 91: // @jdk.internal.ValueBased

Please uncomment value-based class annotation.
Float16 does comply with the semantics of value-based classes.
https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/doc-files/ValueBased.html

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1835875585

From aturbanov at openjdk.org  Wed Nov 13 06:40:21 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Nov 2024 06:40:21 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v3]
In-Reply-To: <jyCXU7GrWAjKiTDOxdirzi_0VZDrkWQb5CzW_6sbn7s=.e8cb51cb-62f6-456c-8a3e-4d3563a2f951@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <jyCXU7GrWAjKiTDOxdirzi_0VZDrkWQb5CzW_6sbn7s=.e8cb51cb-62f6-456c-8a3e-4d3563a2f951@github.com>
Message-ID: <wCCl_6AeNU_718c29fEanRHlG6yUQEfB8xnVzwoNkJs=.2b5bbe73-f604-410b-a077-adae08706822@github.com>

On Tue, 12 Nov 2024 21:59:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Cleanup of suppress warnings and caller sensitive from review comments.
>  - Merge branch 'master' into 8344034-sm-removal-serialization
>  - JDK-8344034: Remove security manager dependency in Serialization
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...3f850839

src/java.base/share/classes/java/io/ObjectInputFilter.java line 1:

> 1: /*

Should all usages of `SecurityManager` be removed from this class?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1839558496

From darcy at openjdk.org  Wed Nov 13 06:43:21 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 13 Nov 2024 06:43:21 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <vZV35ckouuZV-_7dcqf1beBbusFld507_VqkVG0Pymw=.f89d1268-1f65-44fe-af45-94543299be31@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
 <vZV35ckouuZV-_7dcqf1beBbusFld507_VqkVG0Pymw=.f89d1268-1f65-44fe-af45-94543299be31@github.com>
Message-ID: <_J30xBDEFG5HFDhbnG9YaJH4kjns68-Tf-xpdRl7atU=.37ae41db-5962-4ad1-815a-d226cd9fe77d@github.com>

On Mon, 11 Nov 2024 02:09:41 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Respond to review feedback.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 91:
> 
>> 89: // JEP-401 (https://openjdk.org/jeps/401).
>> 90: // @jdk.internal.MigratedValueClass
>> 91: // @jdk.internal.ValueBased
> 
> Please uncomment value-based class annotation.
> Float16 does comply with the semantics of value-based classes.
> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/doc-files/ValueBased.html

The jdk.internal.ValueBased annotation is not exported for use outside of the java.base module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1839565417

From alanb at openjdk.org  Wed Nov 13 07:11:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 07:11:16 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <XZZ3vsLFN-kpGdTi54qv5LL5Jye43MFORSC7wOL9f2I=.6730cf1e-da5d-4999-a917-9a72a8dd5784@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
 <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
 <XZZ3vsLFN-kpGdTi54qv5LL5Jye43MFORSC7wOL9f2I=.6730cf1e-da5d-4999-a917-9a72a8dd5784@github.com>
Message-ID: <FSwsnmYRZgcTcVaaF8IT-5gcu9_Dp2JLB62QwvRFBLs=.1682ba3b-02b3-4f23-9724-b62ea10d8714@github.com>

On Tue, 12 Nov 2024 22:08:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
>> 
>>  - Merge branch 'master' into JDK-8343981
>>  - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
>>  - Initial commit
>>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>>  - Merge branch 'master' into jep486
>>  - Move remaining JEP 486 failing tests into correct groups.
>>  - Move JEP 486 failing tests into hotspot_runtime group.
>>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>>  - Merge branch 'master' into jep486
>>  - Merge branch 'master' into jep486
>>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...636ebd19
>
> src/java.naming/share/classes/com/sun/jndi/ldap/VersionHelper.java line 111:
> 
>> 109: 
>> 110:     Thread createThread(Runnable r) {
>> 111:         return new Thread(r);
> 
> Can the refactoring go back to the callers of createThread() to just create threads themselves.
> And remove this trivial method.

Yes, but in the PR that does the cleanup of java.naming module.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22035#discussion_r1839618104

From alanb at openjdk.org  Wed Nov 13 07:18:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 07:18:15 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <ZgQCMQLZl6SCMccn9hN-t2BmywYF7_4j7X0UAlOEMnU=.5a7dc892-66e1-4d5c-b191-f37e506b9266@github.com>

On Tue, 12 Nov 2024 21:45:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

I think we should remove jdk.internal.misc.InternalLock and the usages in Throwable as part of this change. I don't mind if JavaIOPrintStreamAccess is removed now or in a later PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2472658184

From alanb at openjdk.org  Wed Nov 13 07:18:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 07:18:15 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <uJYNUluaPl_8vhs8y5Y0AjwmwidsiAo_UumjENbM-TY=.335f062e-ddf3-49c4-9c2c-f1acd9a21527@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <uJYNUluaPl_8vhs8y5Y0AjwmwidsiAo_UumjENbM-TY=.335f062e-ddf3-49c4-9c2c-f1acd9a21527@github.com>
Message-ID: <en5P1DrQjJUcCjPQCEY0Sqj1taXR-YmAIijXwUCYGmQ=.c4ede912-957b-4a02-bb4f-bb31c12134e0@github.com>

On Wed, 13 Nov 2024 03:11:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> src/java.base/share/classes/java/io/BufferedOutputStream.java line 88:
> 
>> 86:         }
>> 87: 
>> 88:         this.buf = new byte[initialSize]; // resizable if initialSize < maxSize
> 
> Same remark as for BIS.
> 
> Also this initial vs max size feature was added when virtual thread was first implemented as the internal locks.  Is this implementation detail still necessary for the virtual threads?

Think about 100_000 virtual threads, all blocked on sockets with input/output streams that have wrapped with buffered streams, as in BIS and BOS. This is the motivation for using a reduced initial size.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1839629562

From alan.bateman at oracle.com  Wed Nov 13 07:35:48 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Wed, 13 Nov 2024 07:35:48 +0000
Subject: RFC: Introduce JDK property jdk.patched for indicating
 --patch-module at runtime
In-Reply-To: <f4abceef-6154-4e75-80e2-bd15cbe05f1b@oracle.com>
References: <7c5c3044b4d69113892ac6c9970a7d8b0af11900.camel@redhat.com>
 <f4abceef-6154-4e75-80e2-bd15cbe05f1b@oracle.com>
Message-ID: <a68f71ad-5f08-4e5a-8006-39562f6af94e@oracle.com>

On 13/11/2024 03:44, David Holmes wrote:
>
> The VM already sets properties like
>
> ?jdk.module.patch.N=<...>
>
> when processing --patch-mods. Doesn't that suffice if all you need is 
> a boolean flag to indicate any patching has occurred?
>
> I would have thought you'd like to know which module has been patched, 
> or to be able to ask if a given module has been patch - in which case 
> an actual API method on java.lang.Module would seem reasonable. Or is 
> this an area where module patching is only part of the implementation 
> of Modules in the JDK, not part of the actual Java SE Module 
> specification?

It's very JDK specific and --patch-module is complex due to being a 
repeated option. The jdk.module.patch.<N> properties are the internal 
way to communicate the values provide to --patch-module during startup. 
The properties are removed to avoid wider parts of the system having a 
dependency on its private protocol.

-Alan

From alanb at openjdk.org  Wed Nov 13 07:40:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 07:40:55 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v8]
In-Reply-To: <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
Message-ID: <6bApISnYnGNmKlxN1xUIGgD6t1Ncf1EtAUvD8lYteE4=.39eb53a0-9643-4dcb-a133-bd80297389fd@github.com>

On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringLatin1.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2432158366

From pminborg at openjdk.org  Wed Nov 13 07:48:32 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 07:48:32 GMT
Subject: RFR: 8343984: Fix Unsafe address overflow [v8]
In-Reply-To: <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
 <wdBn226vhZE2L7THAYLBHSThb-e1V58Xbi-k7juzY-g=.abee3c4a-1b3a-466a-8606-3f77a3733746@github.com>
Message-ID: <J336kGkSSw9twyKsuZ6mOIIpSEHehKAxpxyAk_18-8M=.4e67a2cf-cee7-4555-af3c-f034a329508d@github.com>

On Tue, 12 Nov 2024 23:34:48 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update src/java.base/share/classes/java/lang/StringLatin1.java
>   
>   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

Great with the additional fixes.

-------------

Marked as reviewed by pminborg (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22027#pullrequestreview-2432171697

From shade at openjdk.org  Wed Nov 13 08:19:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 08:19:53 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v2]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <ji4F75HWgJbt4B5a2JpE64KmfCSd7wC-V3jkZr0BW3Q=.29509229-eb66-4639-a5a9-49a4ac3718c1@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [ ] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Touchups: assert index, polish commits

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/69d2d189..f791d3ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=00-01

  Stats: 13 lines in 2 files changed: 6 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Wed Nov 13 08:19:53 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 08:19:53 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v2]
In-Reply-To: <PLJ7i4mRNGvZilXMH4zT9nklkMrpgkQrPyZgOZIUlKg=.8f35cfa4-52ce-48d8-a86d-6894221c9e8a@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <PLJ7i4mRNGvZilXMH4zT9nklkMrpgkQrPyZgOZIUlKg=.8f35cfa4-52ce-48d8-a86d-6894221c9e8a@github.com>
Message-ID: <_uqJXPm0kvj5HGR6t5Y6InoNXsqV8ZGYwTCM491k55s=.debdcf8a-d55f-4850-9a5b-c5df4922faec@github.com>

On Wed, 13 Nov 2024 00:30:37 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Touchups: assert index, polish commits
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 300:
> 
>> 298:                 return true;
>> 299:             }
>> 300:         }
> 
> It looks like the new `PhantomCleanableList.remove()` puts 100% trust in the correctness of the PhantomCleanable's `index`.
> 
> What would you think of adding some sort of check/assert that `list.get(phc.index) == phc` ?

Right, tracking indexes is the part of the algo. I added asserts in most important sites, `java/lang` still passes with `-esa`. Please take a look again.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1839714073

From vklang at openjdk.org  Wed Nov 13 08:58:38 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Nov 2024 08:58:38 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v25]
In-Reply-To: <OV20MMXk7ursVA9jhoyAUY5zjy52SGF45XCEgC3qgno=.5b0765a8-4bfc-4eaa-8868-ec097a7cf36d@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <OV20MMXk7ursVA9jhoyAUY5zjy52SGF45XCEgC3qgno=.5b0765a8-4bfc-4eaa-8868-ec097a7cf36d@github.com>
Message-ID: <8GMHQcemGFpM3_YrkOgVr1l4fdMvMB_ybKNe5_lZP-Y=.28eafa87-82b1-4b94-b717-17179750980a@github.com>

On Tue, 12 Nov 2024 21:48:54 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 46 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Improve readbility; tweak runState checks
>  - Address review comments
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Reconcile internal docs; renamings
>  - Minor improvements
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Add CLEANED runState
>  - ... and 36 more: https://git.openjdk.org/jdk/compare/20705130...3ea2470c

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2617:

> 2615:                 if (q != null)
> 2616:                     return q;
> 2617:                 if (shutdown != 0L)

@DougLea Any benefit of doing this vs `boolean shutdown = (lockRunState() & SHUTDOWN) != 0L` and check `!shutdown` and `shutdown`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1839773621

From jvernee at openjdk.org  Wed Nov 13 09:21:36 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Nov 2024 09:21:36 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v3]
In-Reply-To: <BIjPAsbyucO4yNCoRJzRhl2qfQf3v5H_T7wJx0_Vw0g=.7cfea631-9e08-450f-819d-b081c29420e9@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <XKYOEauGPTGzkT4z7PvZPgs8B8mIppxeEq7h-s_SXMM=.3edde68d-c7a1-4aa6-97ec-40b7341397b0@github.com>
 <NnLYzFQUq5lD74naODisuOtPO33PwhHwrFx2zIjGQ9g=.8512c0e2-291d-455e-b178-b209cff2ef2f@github.com>
 <BIjPAsbyucO4yNCoRJzRhl2qfQf3v5H_T7wJx0_Vw0g=.7cfea631-9e08-450f-819d-b081c29420e9@github.com>
Message-ID: <o5HiIN5U5d0ixXd5lZHPf37eRt-NmZSPjyXtwXnSaLI=.eac889b7-9f02-4a18-b8c8-6df178650c9b@github.com>

On Wed, 13 Nov 2024 00:01:40 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 244:
>> 
>>> 242:  * implementation class from unloading when the caller is a {@linkplain
>>> 243:  * MethodHandles.Lookup.ClassOption#STRONG hidden class} and is unloaded, or when
>>> 244:  * the returned call site is no longer strongly reachable.
>> 
>> I don't get the last part of the sentence here. When the call site is no longer reachable _that_ prevents the class from being unloaded?
>> 
>> I like the implNote though. Maybe: "This technique reduces heap memory use, but it prevents the implementation class from being unloaded independently of its defining class loader" ?
>
> Re this sentence: I wish to indicate "caller is unloaded and impl class is unreachable elsewhere (besides in the ClassLoader)".  Maybe just "caller is unloaded" is fine. Thoughts on phrasing?

Maybe 'caller's class is unloaded'.

Also, is the link correct? It links to the STRONG option, but the link text is 'hidden class'.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1839798268

From ihse at openjdk.org  Wed Nov 13 09:47:13 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Nov 2024 09:47:13 GMT
Subject: Integrated: 8339783: Implement JEP 479: Remove the Windows 32-bit x86
 Port
In-Reply-To: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
References: <4cHZyhXPaDSdVif1FC4QKRVLtEecEt3szQaNCDlaJec=.a88d4532-bd5e-49eb-96aa-8c893f581b12@github.com>
Message-ID: <DWWt17muH2zF1oJ5TI8hhjiujsGX7u33TGO446kd5_Y=.d51e25e6-2321-40e2-9ea1-c73108af6998@github.com>

On Mon, 28 Oct 2024 18:09:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This is the implementation of [JEP 479: _Remove the Windows 32-bit x86 Port_](https://openjdk.org/jeps/479).
> 
> This is the summary of JEP 479:
>> Remove the source code and build support for the Windows 32-bit x86 port. This port was [deprecated for removal in JDK 21](https://openjdk.org/jeps/449) with the express intent to remove it in a future release.

This pull request has now been integrated.

Changeset: 79345bbb
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/79345bbbae2564f9f523859d1227a1784293b20f
Stats:     1922 lines in 85 files changed: 82 ins; 1573 del; 267 mod

8339783: Implement JEP 479: Remove the Windows 32-bit x86 Port

Reviewed-by: kbarrett, kvn, stuefe, shade, erikj

-------------

PR: https://git.openjdk.org/jdk/pull/21744

From viktor.klang at oracle.com  Wed Nov 13 10:00:07 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Wed, 13 Nov 2024 10:00:07 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
Message-ID: <MW4PR10MB5774FF395A0DC8AAC4333716FF5A2@MW4PR10MB5774.namprd10.prod.outlook.com>

I think the problem is that it depends on the order, and combination, of operations to know what executes in the same "island".

My personal preference would try to end up in a place where an entire pipeline is executed as a single island, which would mean that short-circuit signals would always propagate right back to the source.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Wednesday, 13 November 2024 00:37
To: Viktor Klang <viktor.klang at oracle.com>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Oh sure, I expect something like distinct() to pull everything. In order to know if something is distinct, you have to do some variant of "check against everyone else". Whether that is holding all instances in memory or their hashes, it's clear from a glance that you will need to look at everything, and therefore, pre-fetching makes intuitive sense to me.

I 100% did not expect terminal operations like findAny() or reduce() to pull the whole data set. That was a complete whiplash for me. The method findAny() advertises itself as a short-circuiting operation, so to find out that it actually pulls the whole data set anyways was shocking.

And that was my biggest pain point -- looking at the documentation, it is not clear to me at all that methods like findAny() would pull in all data upon becoming parallel().

Do you think it would make sense to add documentation about this to the javadocs for Stream/java.util.stream? Or maybe it is already there and I misunderstood it (even after reading through it thoroughly over 5 times).


On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>We are told how Streams can process unbounded data sets, but when it tries to do a findAny() with parallel(), it runs into an OOME because it fetched all the data ahead of time. In fact, almost of the terminal operations will hit an OOME in the exact same way if they are parallel and have a big enough data set. It's definitely not the end of the world, but it seems that I have to fit everything into a Collector and/or a Gatherer if I want to avoid pre-fetching everything.

Yeah, I think it is important to distinguish "can process unbounded data sets" from "always able to process unbounded data sets".

Some operations inherently need the end of the stream, so even something somple like: stream.distinct() or stream.sorted() can end up pulling in all data (which of course won't terminate).

Fortunately, I think Gatherers can unlock much more situations where unbounded streams can be processed.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Tuesday, 12 November 2024 15:08
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon as I thought of it.


I hand-waved away the idea because I thought that the method would turn the stream pipeline parallel, thus, recreating the same problem I currently have of parallelism causing all of the elements to be fetched ahead of time, causing an OOME.


It did NOT occur to me that the pipeline would stay sequential, and just kick these off sequentially, but have them executing in parallel. I can't see why I came to that incorrect conclusion. I have read the javadocs of this method several times. Though, to be fair, I came to the same, incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't until someone pointed out what the documentation was actually saying that I realized it's true properties.

Thanks. That definitely solves at least part of my problem. Obviously, I would prefer to write to S3 in parallel too, but at the very least, the calculation part is being done in parallel. And worst case scenario, I can be really bad and just do the write to S3 in the mapConcurrent, and then just return the metadata of each write, and just bundle that up with collect.


And that's ignoring the fact that I can just use the workaround too.


Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me from a performance perspective, but is rather unintuitive to me from a usability perspective. We are told how Streams can process unbounded data sets, but when it tries to do a findAny() with parallel(), it runs into an OOME because it fetched all the data ahead of time. In fact, almost of the terminal operations will hit an OOME in the exact same way if they are parallel and have a big enough data set. It's definitely not the end of the world, but it seems that I have to fit everything into a Collector and/or a Gatherer if I want to avoid pre-fetching everything.

On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Have you considered Gatherers.mapConcurrent(?)?


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Tuesday, 12 November 2024 01:53
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Good to know, ty vm.

At the very least, I have this workaround. This will meet my needs for now.

I guess my final question would be -- is this type of problem better suited to something besides parallel streams? Maybe an ExecutorService?

Really, all I am doing is taking a jumbo file, splitting it into batches, and then doing some work on those batches. My IO speeds are pretty fast, and the compute work is non-trivial, so there is performance being left on the table if I give up parallelism. And I am in a position where completion time is very important to us.

I just naturally assumed parallel streams were the right choice because the compute work is simple. A pure function that I can break out, and then call in a map. Once I do that, I just call forEach to write the batches back out to S3. Maybe I should look into a different part of the std lib instead because I am using the wrong tool for the job? My nose says ExecutorService, but I figure I should ask before I dive too deep in.


On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
You're most welcome!

In a potential future where all intermediate operations are Gatherer-based, and all terminal operations are Collector-based, it would just work as expected. But with that said, I'm not sure it is practically achievable because some operations might not have the same performance-characteristics as before.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Monday, 11 November 2024 18:32
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Thanks for the workaround. It's running beautifully.

Is there a future where this island concept is extended to the rest of streams? Tbh, I don't fully understand it.

On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Hi David,

This is the effect of how parallel streams are implemented, where different stages, which are not representible as a join-less Spliterator are executed as a series of "islands" where the next isn't started until the former has completed.

If you think about it, parallelization of a Stream works best when the entire data set can be split amongst a set of worker threads, and that sort of implies that you want eager pre-fetch of data, so if your dataset does not fit in memory, that is likely to lead to less desirable outcomes.

What I was able to do for Gatherers is to implement "gather(?) + collect(?)"-fusion so any number of consecutive gather(?)-operations immediately followed by a collect(?) is run in the same "island".

So with that said, you could try something like the following:

static <T> Collector<T, ?, Void> forEach(Consumer<? super T> each) {
    return Collector.of(() -> null, (v, e) -> each.accept(e), (l, r) -> l, (v) -> null, Collector.Characteristics.IDENTITY_FINISH);
}


stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.collect(forEach(eachList -> println(eachList.getFirst())));


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Monday, 11 November 2024 14:52
To: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: Question about Streams, Gatherers, and fetching too many elements

And just to avoid the obvious question, I can hold about 30 batches in memory before the Out of Memory error occurs. So this is not an issue of my batch size being too high.

But just to confirm, I set the batch size to 1, and it still ran into an out of memory error. So I feel fairly confident saying that the Gatherer is trying to grab all available data before sending any of it downstream.

On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>> wrote:
Hello Core Libs Dev Team,

I was trying out Gatherers for a project at work, and ran into a rather sad scenario.

I need to process a large file in batches. Each batch is small enough that I can hold it in memory, but I cannot hold the entire file (and thus, all of the batches) in memory at once.

Looking at the Gatherers API, I saw windowFixed and thought that it would be a great match for my use case.

However, when trying it out, I was disappointed to see that it ran out of memory very quickly. Here is my attempt at using it.

stream
.parallel()
.unordered()
.gather(Gatherers.windowFixed(BATCH_SIZE))
.forEach(eachList -> println(eachList.getFirst()))
;

As you can see, I am just splitting the file into batches, and printing out the first of each batch. This is purely for example's sake, of course. I had planned on building even more functionality on top of this, but I couldn't even get past this example.

But anyways, not even a single one of them printed out. Which leads me to believe that it's pulling all of them in the Gatherer.

I can get it to run successfully if I go sequentially, but not parallel. Parallel gives me that out of memory error.

Is there any way for me to be able to have the Gatherer NOT pull in everything while still remaining parallel and unordered?

Thank you for your time and help.
David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241113/a329e892/attachment-0001.htm>

From rgiulietti at openjdk.org  Wed Nov 13 10:23:44 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Nov 2024 10:23:44 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v16]
In-Reply-To: <lGzuOoQml6iOyw18fvZdxINUtFdXNfDaHpq-CQSAsq8=.5a0007d3-11a2-46ba-8d85-49e11b02e3f8@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <lGzuOoQml6iOyw18fvZdxINUtFdXNfDaHpq-CQSAsq8=.5a0007d3-11a2-46ba-8d85-49e11b02e3f8@github.com>
Message-ID: <gmwyRTMXmiQyCONi-nZwF_xrPGB58No3NJaJV2_zzGw=.f4f52d43-abd5-4852-9012-0f773296e474@github.com>

On Wed, 13 Nov 2024 05:40:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Implement code review feedback.
>  - Misc cleanups.

LGTM

-------------

Marked as reviewed by rgiulietti (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21574#pullrequestreview-2432540929

From pminborg at openjdk.org  Wed Nov 13 10:24:14 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 10:24:14 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v14]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <cxSiGV-TWjxSKHsHX3dxCqMk0cXtIE9DfXCipDjFCtU=.3424bd59-fbce-4bfd-898e-43d99d5dcf2c@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:

 - Update after comments
 - Merge branch 'master' into linker-padding-layout-only
 - Simplify exception testing
 - Merge branch 'master' into linker-padding-layout-only
 - Remove redundant check
 - Rephrase doc
 - Improve language
 - Add checks of exception messages
 - Update test/jdk/java/foreign/TestLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - ... and 22 more: https://git.openjdk.org/jdk/compare/712b259a...786b1737

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/6a97fe5d..786b1737

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=12-13

  Stats: 17927 lines in 551 files changed: 13128 ins; 2558 del; 2241 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From shade at openjdk.org  Wed Nov 13 10:23:57 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 10:23:57 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v3]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <lNtj3cMQob9fLBWWxLxS4ZSh9oQR2aqHvewcMdSntZ8=.b6e50c2e-bf0e-4750-a628-88912d440019@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [ ] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Merge branch 'master' into JDK-8343704-cleaner-gc
 - Touchups: assert index, polish commits
 - Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/f791d3ce..885edc1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=01-02

  Stats: 81613 lines in 2233 files changed: 9865 ins; 66346 del; 5402 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From alanb at openjdk.org  Wed Nov 13 10:24:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 10:24:55 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v4]
In-Reply-To: <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
Message-ID: <wOEGel1frS6ukHU_WT-eCc2jXef3iewQK37XmoWmeBk=.6436b506-e643-4fe1-ad89-e42efa2da791@github.com>

On Wed, 13 Nov 2024 02:17:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unnecessary copyright change in ProcessEnvironment.java.
>   Fix code style in ProcessImpl
>   Drop unneeded suppress warnings.
>   Remove obsolete @throws SecurityExceptions

I did another pass on this, looks good.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22024#pullrequestreview-2432569542

From eirbjo at openjdk.org  Wed Nov 13 10:44:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 13 Nov 2024 10:44:19 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v16]
In-Reply-To: <lGzuOoQml6iOyw18fvZdxINUtFdXNfDaHpq-CQSAsq8=.5a0007d3-11a2-46ba-8d85-49e11b02e3f8@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <lGzuOoQml6iOyw18fvZdxINUtFdXNfDaHpq-CQSAsq8=.5a0007d3-11a2-46ba-8d85-49e11b02e3f8@github.com>
Message-ID: <IUtwBMxhLcRaPgJFfGdWwRsbbsJnfs1S8OG1c4zVolY=.21933fe0-3bea-4a5b-ae43-946be4ba19b7@github.com>

On Wed, 13 Nov 2024 05:40:24 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.
>
> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Implement code review feedback.
>  - Misc cleanups.

src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 150:

> 148:      * A constant holding the largest positive finite value of type
> 149:      * {@code Float16},
> 150:      * (2-2<sup>-10</sup>)&middot;2<sup>15</sup>, numerically equal to 65504.0.

I'm curious why `MAX_VALUE` includes the "numerically equal to", while `MIN_NORMAL` and `MIN_VALUE` do not?

I see java.lang.Float does not use "numerically equal" in the corresponding constants.  Float instead says "It is equal to the hexadecimal floating-point literal.."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1839952935

From alanb at openjdk.org  Wed Nov 13 10:56:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 10:56:47 GMT
Subject: RFR: 8310996: Add JFR event for connect operations [v4]
In-Reply-To: <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
References: <9WgigdK6VDa5UjTuNSUw1A_cn0PUzhZxdl3REdSzZz4=.c3307452-0fd0-4392-89d3-6c050c587f3d@github.com>
 <JlZAxnvrWEjfN8cOtsjOUEkSdKr-9_2MffsL8v9C7vI=.0841f2f4-a51c-4b2e-9551-0290b1759817@github.com>
Message-ID: <ZUtXH5LRVvMxJxmVtIwGr1uGYVtRicgUKPdtlD7I1ts=.96d095d5-21f5-42f3-965e-5bcb7573bba9@github.com>

On Wed, 6 Nov 2024 00:15:44 GMT, Tim Prinzing <tprinzing at openjdk.org> wrote:

>> Adds a JFR event for socket connect operations.
>> 
>> Existing tests TestSocketEvents and TestSocketChannelEvents modified to also check for connect events.
>
> Tim Prinzing has updated the pull request incrementally with one additional commit since the last revision:
> 
>   suggested changes

@tprinzing Are you planning on all the tests?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21528#issuecomment-2473184324

From jpai at openjdk.org  Wed Nov 13 11:02:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Nov 2024 11:02:48 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v4]
In-Reply-To: <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
Message-ID: <WodpAoIcb2kM-jAV18jyCP7BTtFLqKR_azUpO7cQ6Hc=.510fc507-25b0-411d-86ee-0bd2afd52eab@github.com>

On Wed, 13 Nov 2024 02:17:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert unnecessary copyright change in ProcessEnvironment.java.
>   Fix code style in ProcessImpl
>   Drop unneeded suppress warnings.
>   Remove obsolete @throws SecurityExceptions

src/java.base/windows/classes/java/lang/ProcessImpl.java line 516:

> 514:         }
> 515: 
> 516:         return null;

I think this is an oversight - returning `null` from the constructor would be an compile error.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1839985669

From jpai at openjdk.org  Wed Nov 13 11:02:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Nov 2024 11:02:49 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v4]
In-Reply-To: <WodpAoIcb2kM-jAV18jyCP7BTtFLqKR_azUpO7cQ6Hc=.510fc507-25b0-411d-86ee-0bd2afd52eab@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
 <WodpAoIcb2kM-jAV18jyCP7BTtFLqKR_azUpO7cQ6Hc=.510fc507-25b0-411d-86ee-0bd2afd52eab@github.com>
Message-ID: <IoMhcCkViKjAp009qT1ZGyq4FI-Ch_mJKz9ZwPz5yRE=.1cc9a0a8-d4cf-40e5-ad1d-7588200c4916@github.com>

On Wed, 13 Nov 2024 10:57:10 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Revert unnecessary copyright change in ProcessEnvironment.java.
>>   Fix code style in ProcessImpl
>>   Drop unneeded suppress warnings.
>>   Remove obsolete @throws SecurityExceptions
>
> src/java.base/windows/classes/java/lang/ProcessImpl.java line 516:
> 
>> 514:         }
>> 515: 
>> 516:         return null;
> 
> I think this is an oversight - returning `null` from the constructor would be an compile error.

Actually, looking at the GitHub actions job, it appears to have caught one other compilation error in this file:


jdk\jdk\src\java.base\windows\classes\java\lang\ProcessImpl.java:423: error: ';' expected
        final String value = System.getProperty("jdk.lang.Process.allowAmbiguousCommands", "true"));
                                                                                                  ^
1 error

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1839992366

From rgiulietti at openjdk.org  Wed Nov 13 11:18:31 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Nov 2024 11:18:31 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v16]
In-Reply-To: <IUtwBMxhLcRaPgJFfGdWwRsbbsJnfs1S8OG1c4zVolY=.21933fe0-3bea-4a5b-ae43-946be4ba19b7@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <lGzuOoQml6iOyw18fvZdxINUtFdXNfDaHpq-CQSAsq8=.5a0007d3-11a2-46ba-8d85-49e11b02e3f8@github.com>
 <IUtwBMxhLcRaPgJFfGdWwRsbbsJnfs1S8OG1c4zVolY=.21933fe0-3bea-4a5b-ae43-946be4ba19b7@github.com>
Message-ID: <eaMPSs8wcByzWRB5SpkJfTwC-LVDDxpM3nOfjxa-790=.ec358b67-0363-4f86-af06-1e95e70954a3@github.com>

On Wed, 13 Nov 2024 10:41:34 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Joe Darcy has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Implement code review feedback.
>>  - Misc cleanups.
>
> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 150:
> 
>> 148:      * A constant holding the largest positive finite value of type
>> 149:      * {@code Float16},
>> 150:      * (2-2<sup>-10</sup>)&middot;2<sup>15</sup>, numerically equal to 65504.0.
> 
> I'm curious why `MAX_VALUE` includes the "numerically equal to", while `MIN_NORMAL` and `MIN_VALUE` do not?
> 
> I see java.lang.Float does not use "numerically equal" in the corresponding constants.  Float instead says "It is equal to the hexadecimal floating-point literal.."

Not sure if this is the reason, but in decimal notation `MIN_NORMAL` and `MIN_VALUE` are relatively unreadable: `0.00006103515625` and `5.9604644775390625E-8`, resp.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1840063297

From sgehwolf at redhat.com  Wed Nov 13 11:19:45 2024
From: sgehwolf at redhat.com (Severin Gehwolf)
Date: Wed, 13 Nov 2024 12:19:45 +0100
Subject: RFC: Introduce JDK property jdk.patched for indicating
 --patch-module at runtime
In-Reply-To: <a68f71ad-5f08-4e5a-8006-39562f6af94e@oracle.com>
References: <7c5c3044b4d69113892ac6c9970a7d8b0af11900.camel@redhat.com>
 <f4abceef-6154-4e75-80e2-bd15cbe05f1b@oracle.com>
 <a68f71ad-5f08-4e5a-8006-39562f6af94e@oracle.com>
Message-ID: <4f7cf6d420a379975f70cbf662e269578e5959df.camel@redhat.com>

On Wed, 2024-11-13 at 07:35 +0000, Alan Bateman wrote:
> On 13/11/2024 03:44, David Holmes wrote:
> > 
> > The VM already sets properties like
> > 
> > ?jdk.module.patch.N=<...>
> > 
> > when processing --patch-mods. Doesn't that suffice if all you need is 
> > a boolean flag to indicate any patching has occurred?
> > 
> > I would have thought you'd like to know which module has been patched, 
> > or to be able to ask if a given module has been patch - in which case 
> > an actual API method on java.lang.Module would seem reasonable. Or is 
> > this an area where module patching is only part of the implementation 
> > of Modules in the JDK, not part of the actual Java SE Module 
> > specification?
> 
> It's very JDK specific and --patch-module is complex due to being a 
> repeated option. The jdk.module.patch.<N> properties are the internal
> way to communicate the values provide to --patch-module during startup. 
> The properties are removed to avoid wider parts of the system having a 
> dependency on its private protocol.

Yes. Also a `jdk.patched` boolean property would be more generic and
wouldn't leak any details. A use-case of such a property can be seen
in:

https://github.com/openjdk/jdk/pull/22037

It currently needs to jump through hoops (using VM.getSavedProperties),
which is internal API. A more generic property would satisfy this use-
case without needing to expose jdk.internal.misc to jdk.jlink from
java.base. I.e. if at least one internal jdk.module.patch.<N> is
present, the public property would be true.

Thanks,
Severin


From alanb at openjdk.org  Wed Nov 13 11:31:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 11:31:16 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v3]
In-Reply-To: <jyCXU7GrWAjKiTDOxdirzi_0VZDrkWQb5CzW_6sbn7s=.e8cb51cb-62f6-456c-8a3e-4d3563a2f951@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <jyCXU7GrWAjKiTDOxdirzi_0VZDrkWQb5CzW_6sbn7s=.e8cb51cb-62f6-456c-8a3e-4d3563a2f951@github.com>
Message-ID: <NpW7TUFHBSiINS8URnfENDiEaid1G1buHzXVvH4i6MM=.99ac8a1a-472d-4b3e-8063-ef0b1fb19b29@github.com>

On Tue, 12 Nov 2024 21:59:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Cleanup of suppress warnings and caller sensitive from review comments.
>  - Merge branch 'master' into 8344034-sm-removal-serialization
>  - JDK-8344034: Remove security manager dependency in Serialization
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...3f850839

ObjectInputFilter.setSerialFilter and setSerialFilterFactory, have they been missed?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22041#issuecomment-2473301863

From alanb at openjdk.org  Wed Nov 13 11:42:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 11:42:17 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v4]
In-Reply-To: <IoMhcCkViKjAp009qT1ZGyq4FI-Ch_mJKz9ZwPz5yRE=.1cc9a0a8-d4cf-40e5-ad1d-7588200c4916@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
 <WodpAoIcb2kM-jAV18jyCP7BTtFLqKR_azUpO7cQ6Hc=.510fc507-25b0-411d-86ee-0bd2afd52eab@github.com>
 <IoMhcCkViKjAp009qT1ZGyq4FI-Ch_mJKz9ZwPz5yRE=.1cc9a0a8-d4cf-40e5-ad1d-7588200c4916@github.com>
Message-ID: <LG-GAZoaZECXPthNc-oQmraMbo_KHTupSyaGlewOi1Y=.9feeca4a-e6cc-4cc7-942a-088ab2224823@github.com>

On Wed, 13 Nov 2024 10:58:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/windows/classes/java/lang/ProcessImpl.java line 516:
>> 
>>> 514:         }
>>> 515: 
>>> 516:         return null;
>> 
>> I think this is an oversight - returning `null` from the constructor would be an compile error.
>
> Actually, looking at the GitHub actions job, it appears to have caught one other compilation error in this file:
> 
> 
> jdk\jdk\src\java.base\windows\classes\java\lang\ProcessImpl.java:423: error: ';' expected
>         final String value = System.getProperty("jdk.lang.Process.allowAmbiguousCommands", "true"));
>                                                                                                   ^
> 1 error

I assume Roger will run at least tier1 on all platforms before integrating.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1840100951

From davidalayachew at gmail.com  Wed Nov 13 11:49:27 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 13 Nov 2024 06:49:27 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB5774FF395A0DC8AAC4333716FF5A2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <MW4PR10MB5774FF395A0DC8AAC4333716FF5A2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_M=ny1uQarYHFc4G1JSqX9m0_fed7Ago37LF6rouPZ+nA@mail.gmail.com>

Makes a lot of sense. And I agree -- hopefully we do end up in a place
where all the methods on Stream do execute on the same island.

Until then, I will make do with keeping as much functionality as possible
on the Gatherers and Collectors, so that I can eliminate island hopping
entirely. At the very least, I will avoid using the non-Collector terminal
operations, as it appears that, using a Collector keeps everything on the
same island for the duration of the stream.


On Wed, Nov 13, 2024, 5:00?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> I think the problem is that it depends on the order, and combination, of
> operations to know what executes in the same "island".
>
> My personal preference would try to end up in a place where an entire
> pipeline is executed as a single island, which would mean that
> short-circuit signals would always propagate right back to the source.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Wednesday, 13 November 2024 00:37
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> Oh sure, I expect something like distinct() to pull everything. In order
> to know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
>
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
>
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
>
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
>
>
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> >We are told how Streams can process unbounded data sets, but when it
> tries to do a findAny() with parallel(), it runs into an OOME because it
> fetched all the data ahead of time. In fact, almost of the terminal
> operations will hit an OOME in the exact same way if they are parallel and
> have a big enough data set. It's definitely not the end of the world, but
> it seems that I have to fit everything into a Collector and/or a Gatherer
> if I want to avoid pre-fetching everything.
>
> Yeah, I think it is important to distinguish "can process unbounded data
> sets" from "always able to process unbounded data sets".
>
> Some operations inherently need the end of the stream, so even something
> somple like: stream.distinct() or stream.sorted() can end up pulling in all
> data (which of course won't terminate).
>
> Fortunately, I think Gatherers can unlock much more situations where
> unbounded streams can be processed.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Tuesday, 12 November 2024 15:08
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
> as I thought of it.
>
>
> I hand-waved away the idea because I thought that the method would turn
> the stream pipeline parallel, thus, recreating the same problem I currently
> have of parallelism causing all of the elements to be fetched ahead of
> time, causing an OOME.
>
>
> It did NOT occur to me that the pipeline would stay sequential, and just
> kick these off sequentially, but have them executing in parallel. I can't
> see why I came to that incorrect conclusion. I have read the javadocs of
> this method several times. Though, to be fair, I came to the same,
> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
> until someone pointed out what the documentation was actually saying that I
> realized it's true properties.
>
> Thanks. That definitely solves at least part of my problem. Obviously, I
> would prefer to write to S3 in parallel too, but at the very least, the
> calculation part is being done in parallel. And worst case scenario, I can
> be really bad and just do the write to S3 in the mapConcurrent, and then
> just return the metadata of each write, and just bundle that up with
> collect.
>
>
> And that's ignoring the fact that I can just use the workaround too.
>
>
> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
> from a performance perspective, but is rather unintuitive to me from a
> usability perspective. We are told how Streams can process unbounded data
> sets, but when it tries to do a findAny() with parallel(), it runs into an
> OOME because it fetched all the data ahead of time. In fact, almost of the
> terminal operations will hit an OOME in the exact same way if they are
> parallel and have a big enough data set. It's definitely not the end of the
> world, but it seems that I have to fit everything into a Collector and/or a
> Gatherer if I want to avoid pre-fetching everything.
>
> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Have you considered Gatherers.mapConcurrent(?)?
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Tuesday, 12 November 2024 01:53
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> Good to know, ty vm.
>
> At the very least, I have this workaround. This will meet my needs for now.
>
> I guess my final question would be -- is this type of problem better
> suited to something besides parallel streams? Maybe an ExecutorService?
>
> Really, all I am doing is taking a jumbo file, splitting it into batches,
> and then doing some work on those batches. My IO speeds are pretty fast,
> and the compute work is non-trivial, so there is performance being left on
> the table if I give up parallelism. And I am in a position where completion
> time is very important to us.
>
> I just naturally assumed parallel streams were the right choice because
> the compute work is simple. A pure function that I can break out, and then
> call in a map. Once I do that, I just call forEach to write the batches
> back out to S3. Maybe I should look into a different part of the std lib
> instead because I am using the wrong tool for the job? My nose says
> ExecutorService, but I figure I should ask before I dive too deep in.
>
>
> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> You're most welcome!
>
> In a potential future where all intermediate operations are
> Gatherer-based, and all terminal operations are Collector-based, it would
> just work as expected. But with that said, I'm not sure it is practically
> achievable because some operations might not have the same
> performance-characteristics as before.
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 18:32
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Thanks for the workaround. It's running beautifully.
>
> Is there a future where this island concept is extended to the rest of
> streams? Tbh, I don't fully understand it.
>
> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> Hi David,
>
> This is the effect of how parallel streams are implemented, where
> different stages, which are not representible as a join-less Spliterator
> are executed as a series of "islands" where the next isn't started until
> the former has completed.
>
> If you think about it, parallelization of a Stream works best when the
> entire data set can be split amongst a set of worker threads, and that sort
> of implies that you want eager pre-fetch of data, so if your dataset does
> not fit in memory, that is likely to lead to less desirable outcomes.
>
> What I was able to do for Gatherers is to implement "gather(?) +
> collect(?)"-fusion so any number of consecutive gather(?)-operations
> immediately followed by a collect(?) is run in the same "island".
>
> So with that said, you could try something like the following:
>
> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>     *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> }
>
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .collect(forEach(eachList -> println(eachList.getFirst())));
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Monday, 11 November 2024 14:52
> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> elements
>
> And just to avoid the obvious question, I can hold about 30 batches in
> memory before the Out of Memory error occurs. So this is not an issue of my
> batch size being too high.
>
> But just to confirm, I set the batch size to 1, and it still ran into an
> out of memory error. So I feel fairly confident saying that the Gatherer is
> trying to grab all available data before sending any of it downstream.
>
> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
> wrote:
>
> Hello Core Libs Dev Team,
>
> I was trying out Gatherers for a project at work, and ran into a rather
> sad scenario.
>
> I need to process a large file in batches. Each batch is small enough that
> I can hold it in memory, but I cannot hold the entire file (and thus, all
> of the batches) in memory at once.
>
> Looking at the Gatherers API, I saw windowFixed and thought that it would
> be a great match for my use case.
>
> However, when trying it out, I was disappointed to see that it ran out of
> memory very quickly. Here is my attempt at using it.
>
> stream
> .parallel()
> .unordered()
> .gather(Gatherers.windowFixed(BATCH_SIZE))
> .forEach(eachList -> println(eachList.getFirst()))
> ;
>
> As you can see, I am just splitting the file into batches, and printing
> out the first of each batch. This is purely for example's sake, of course.
> I had planned on building even more functionality on top of this, but I
> couldn't even get past this example.
>
> But anyways, not even a single one of them printed out. Which leads me to
> believe that it's pulling all of them in the Gatherer.
>
> I can get it to run successfully if I go sequentially, but not parallel.
> Parallel gives me that out of memory error.
>
> Is there any way for me to be able to have the Gatherer NOT pull in
> everything while still remaining parallel and unordered?
>
> Thank you for your time and help.
> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241113/750b392c/attachment-0001.htm>

From openjdk at icemanx.nl  Wed Nov 13 12:06:02 2024
From: openjdk at icemanx.nl (Rob Spoor)
Date: Wed, 13 Nov 2024 13:06:02 +0100
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
Message-ID: <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>

distinct() doesn't require everything to be pulled. It can push elements 
to the downstream as they come along for the first time. When 
downstream.push returns false the gatherer is done.

As part of some experimentation I've implemented all intermediary 
operations using gatherers. Most of them are pretty straightforward and 
will stop integrating once the downstream starts rejecting elements 
(although some use Gatherer.ofSequential to keep it easy). I only found 
two exceptions that don't return the result of downstream.push:

* mapMulti. The downstream.push is passed as the mapper which is a 
Consumer - the return value is ignored. With some more effort it's 
probably possible to capture any false return value and return that from 
the integrator, but I haven't tried that yet.

* sorted. Obviously every element needs to be inspected.


On 13/11/2024 00:37, David Alayachew wrote:
> Oh sure, I expect something like distinct() to pull everything. In order to
> know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
> 
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
> 
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
> 
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
> 
> 
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com> wrote:
> 
>>> We are told how Streams can process unbounded data sets, but when it
>> tries to do a findAny() with parallel(), it runs into an OOME because it
>> fetched all the data ahead of time. In fact, almost of the terminal
>> operations will hit an OOME in the exact same way if they are parallel and
>> have a big enough data set. It's definitely not the end of the world, but
>> it seems that I have to fit everything into a Collector and/or a Gatherer
>> if I want to avoid pre-fetching everything.
>>
>> Yeah, I think it is important to distinguish "can process unbounded data
>> sets" from "always able to process unbounded data sets".
>>
>> Some operations inherently need the end of the stream, so even something
>> somple like: stream.distinct() or stream.sorted() can end up pulling in all
>> data (which of course won't terminate).
>>
>> Fortunately, I think Gatherers can unlock much more situations where
>> unbounded streams can be processed.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Tuesday, 12 November 2024 15:08
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
>> as I thought of it.
>>
>>
>> I hand-waved away the idea because I thought that the method would turn
>> the stream pipeline parallel, thus, recreating the same problem I currently
>> have of parallelism causing all of the elements to be fetched ahead of
>> time, causing an OOME.
>>
>>
>> It did NOT occur to me that the pipeline would stay sequential, and just
>> kick these off sequentially, but have them executing in parallel. I can't
>> see why I came to that incorrect conclusion. I have read the javadocs of
>> this method several times. Though, to be fair, I came to the same,
>> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
>> until someone pointed out what the documentation was actually saying that I
>> realized it's true properties.
>>
>> Thanks. That definitely solves at least part of my problem. Obviously, I
>> would prefer to write to S3 in parallel too, but at the very least, the
>> calculation part is being done in parallel. And worst case scenario, I can
>> be really bad and just do the write to S3 in the mapConcurrent, and then
>> just return the metadata of each write, and just bundle that up with
>> collect.
>>
>>
>> And that's ignoring the fact that I can just use the workaround too.
>>
>>
>> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
>> from a performance perspective, but is rather unintuitive to me from a
>> usability perspective. We are told how Streams can process unbounded data
>> sets, but when it tries to do a findAny() with parallel(), it runs into an
>> OOME because it fetched all the data ahead of time. In fact, almost of the
>> terminal operations will hit an OOME in the exact same way if they are
>> parallel and have a big enough data set. It's definitely not the end of the
>> world, but it seems that I have to fit everything into a Collector and/or a
>> Gatherer if I want to avoid pre-fetching everything.
>>
>> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Have you considered Gatherers.mapConcurrent(?)?
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Tuesday, 12 November 2024 01:53
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> Good to know, ty vm.
>>
>> At the very least, I have this workaround. This will meet my needs for now.
>>
>> I guess my final question would be -- is this type of problem better
>> suited to something besides parallel streams? Maybe an ExecutorService?
>>
>> Really, all I am doing is taking a jumbo file, splitting it into batches,
>> and then doing some work on those batches. My IO speeds are pretty fast,
>> and the compute work is non-trivial, so there is performance being left on
>> the table if I give up parallelism. And I am in a position where completion
>> time is very important to us.
>>
>> I just naturally assumed parallel streams were the right choice because
>> the compute work is simple. A pure function that I can break out, and then
>> call in a map. Once I do that, I just call forEach to write the batches
>> back out to S3. Maybe I should look into a different part of the std lib
>> instead because I am using the wrong tool for the job? My nose says
>> ExecutorService, but I figure I should ask before I dive too deep in.
>>
>>
>> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> You're most welcome!
>>
>> In a potential future where all intermediate operations are
>> Gatherer-based, and all terminal operations are Collector-based, it would
>> just work as expected. But with that said, I'm not sure it is practically
>> achievable because some operations might not have the same
>> performance-characteristics as before.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Monday, 11 November 2024 18:32
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Thanks for the workaround. It's running beautifully.
>>
>> Is there a future where this island concept is extended to the rest of
>> streams? Tbh, I don't fully understand it.
>>
>> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> Hi David,
>>
>> This is the effect of how parallel streams are implemented, where
>> different stages, which are not representible as a join-less Spliterator
>> are executed as a series of "islands" where the next isn't started until
>> the former has completed.
>>
>> If you think about it, parallelization of a Stream works best when the
>> entire data set can be split amongst a set of worker threads, and that sort
>> of implies that you want eager pre-fetch of data, so if your dataset does
>> not fit in memory, that is likely to lead to less desirable outcomes.
>>
>> What I was able to do for Gatherers is to implement "gather(?) +
>> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> immediately followed by a collect(?) is run in the same "island".
>>
>> So with that said, you could try something like the following:
>>
>> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
>> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> }
>>
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .collect(forEach(eachList -> println(eachList.getFirst())));
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
>> Alayachew <davidalayachew at gmail.com>
>> *Sent:* Monday, 11 November 2024 14:52
>> *To:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> elements
>>
>> And just to avoid the obvious question, I can hold about 30 batches in
>> memory before the Out of Memory error occurs. So this is not an issue of my
>> batch size being too high.
>>
>> But just to confirm, I set the batch size to 1, and it still ran into an
>> out of memory error. So I feel fairly confident saying that the Gatherer is
>> trying to grab all available data before sending any of it downstream.
>>
>> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com>
>> wrote:
>>
>> Hello Core Libs Dev Team,
>>
>> I was trying out Gatherers for a project at work, and ran into a rather
>> sad scenario.
>>
>> I need to process a large file in batches. Each batch is small enough that
>> I can hold it in memory, but I cannot hold the entire file (and thus, all
>> of the batches) in memory at once.
>>
>> Looking at the Gatherers API, I saw windowFixed and thought that it would
>> be a great match for my use case.
>>
>> However, when trying it out, I was disappointed to see that it ran out of
>> memory very quickly. Here is my attempt at using it.
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .forEach(eachList -> println(eachList.getFirst()))
>> ;
>>
>> As you can see, I am just splitting the file into batches, and printing
>> out the first of each batch. This is purely for example's sake, of course.
>> I had planned on building even more functionality on top of this, but I
>> couldn't even get past this example.
>>
>> But anyways, not even a single one of them printed out. Which leads me to
>> believe that it's pulling all of them in the Gatherer.
>>
>> I can get it to run successfully if I go sequentially, but not parallel.
>> Parallel gives me that out of memory error.
>>
>> Is there any way for me to be able to have the Gatherer NOT pull in
>> everything while still remaining parallel and unordered?
>>
>> Thank you for your time and help.
>> David Alayachew

From alanb at openjdk.org  Wed Nov 13 12:05:38 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 12:05:38 GMT
Subject: RFR: 8342380: Implement JEP draft: Warn about use of Memory-Access
 Methods in `sun.misc.Unsafe` [v2]
In-Reply-To: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
Message-ID: <8jaBPHqLI5QJ826RlbsnXPImPUSXmUx7ORfRaLa5J1s=.2e14927e-8de1-421b-a258-cb1201a85913@github.com>

> Change default value of the command line option --sun-misc-unsafe-memory-access from "allow" to "warn".

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into JDK-8342380
 - Update test
 - Merge branch 'master' into JDK-8342380
 - Update usage/man page
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21762/files
  - new: https://git.openjdk.org/jdk/pull/21762/files/85264b80..a9f99896

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21762&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21762&range=00-01

  Stats: 225679 lines in 3239 files changed: 123548 ins; 77490 del; 24641 mod
  Patch: https://git.openjdk.org/jdk/pull/21762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21762/head:pull/21762

PR: https://git.openjdk.org/jdk/pull/21762

From alanb at openjdk.org  Wed Nov 13 12:06:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 12:06:58 GMT
Subject: RFR: 8342486: Implement JEP draft: Structured Concurrency (Fifth
 Preview) [v2]
In-Reply-To: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
References: <GzKHag0v2go9g81fQHSdpSafHj56aSVxOp2vHOtD458=.f1d206b3-ef53-4926-bfca-d4066561dcc6@github.com>
Message-ID: <Dz2LRL9-pTqol3MP3foxc7hr81jO1uYLUrbEX3tFGA4=.da58d231-1110-404f-83ef-1788dec9d567@github.com>

> Changes for [JEP draft: Structured Concurrency (Fifth Preview)](https://openjdk.org/jeps/8340343). The JEP isn't on the technical roadmap yet. The proposal is to re-preview the API with some changes, specifically:
> 
> - A [StructuredTaskScope](https://download.java.net/java/early_access/loom/docs/api/java.base/java/util/concurrent/StructuredTaskScope.html) is now opened with a static factory method instead of a constructor.  Once opened, the API usage is unchanged: fork subtasks individually, join them as a unit, process outcome, and close.
> - In conjunction with moving to using a static open method, policy and desired outcome is now selected by specifying a Joiner to the open method rather than extending STS. A Joiner handles subtask completion and produces the result for join to return. Joiner.onComplete is the equivalent of overriding handleComplete previously. This change means that the subclasses ShutdownOnFailure and ShutdownOnSuccess are removed, replaced by factory methods on Joiner to get an equivalent Joiner.
> - The join method is changed to return the result or throw STS.FailedException, replacing the need for an API in subclasses to obtain the outcome. This removes the hazard that was forgetting to call throwIfFailed to propagate exceptions.
> - Configuration that was provided with parameters for the constructor is changed so that can be provided by a configuration function.
> - joinUntil is replaced by allowing a timeout be configured by the configuration function. This allows the timeout to apply the scope rather than the join method.
>  
> The underlying implementation is unchanged except that ThreadFlock.shutdown and wakeup methods are no longer confined. The STS API implementation moves to non-public StructuedTaskScopeImpl because STS is now an interface. A non-public Joiners class is added with the built-in Joiner implementations.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Pull latest API docs + impl from loom repo
 - Merge branch 'master' into JDK-8342486
 - Sync up from loom repo
 - Initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/21934/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21934&range=01
  Stats: 4079 lines in 15 files changed: 1852 ins; 1498 del; 729 mod
  Patch: https://git.openjdk.org/jdk/pull/21934.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21934/head:pull/21934

PR: https://git.openjdk.org/jdk/pull/21934

From turbanoff at gmail.com  Wed Nov 13 12:08:04 2024
From: turbanoff at gmail.com (Andrey Turbanov)
Date: Wed, 13 Nov 2024 15:08:04 +0300
Subject: Math.toIntExact why only long?
Message-ID: <CAF+DQ5fpFeVd=vkSGSaA5biBmsB=4PB4P-YszC=D=TGU8hhvKw@mail.gmail.com>

I wounder, why java.lang.Math.toIntExact accepts only long parameter?
I think it will quite useful to have it with float/double parameters too.

Andrey Turbanov

From alanb at openjdk.org  Wed Nov 13 12:19:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 12:19:58 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs
Message-ID: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>

Remove code required needed for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.

sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will be removed to remove empty methods and qualified exports once the changes in "far away" code and modules is done.

runtime/cds/appcds/StaticArchiveWithLambda.java is temporarily excluded as the loading of a dynamically generated class at archive time. I'm checking with Calvin and Ioi on whether this test should be updated or replaced.

Testing: tier1-5

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22063/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22063&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344011
  Stats: 1254 lines in 26 files changed: 8 ins; 1094 del; 152 mod
  Patch: https://git.openjdk.org/jdk/pull/22063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22063/head:pull/22063

PR: https://git.openjdk.org/jdk/pull/22063

From jlahoda at openjdk.org  Wed Nov 13 12:33:16 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Wed, 13 Nov 2024 12:33:16 GMT
Subject: RFR: 8335989: JEP 494: Implement Module Import Declarations
 (Second Preview) [v7]
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <4ybB5B_AJXd-L8tGumK4LJz4oil4sLOO9xXtpO3eMK8=.3c6fe57d-1f1b-45d0-aae7-fd1ccb5773d1@github.com>

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:

 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Moving operators to the beginning of line, as suggested.
 - Updating PreviewFeature metadata
 - Cleanup.
 - Merge branch 'master' into JDK-8335989
 - Merge branch 'master' into JDK-8335989
 - Reflecting review feedback.
 - Cleanup.
 - Cleanup.
 - ... and 11 more: https://git.openjdk.org/jdk/compare/79345bbb...babcfccf

-------------

Changes: https://git.openjdk.org/jdk/pull/21431/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21431&range=06
  Stats: 762 lines in 28 files changed: 580 ins; 46 del; 136 mod
  Patch: https://git.openjdk.org/jdk/pull/21431.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21431/head:pull/21431

PR: https://git.openjdk.org/jdk/pull/21431

From davidalayachew at gmail.com  Wed Nov 13 13:07:02 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Wed, 13 Nov 2024 08:07:02 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
Message-ID: <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>

That is a good point Rob.

Then let me correct myself -- I think the terminal operations don't do a
great job of advertising whether or not they pre-fetch everything when
parallelism is activated. Collector fetches as needed. FindAny pre-fetches
everything. I understand that later releases might change their behaviour,
but I still want to document the current behaviour in the official javadocs
so that we can limit undocumented tripping hazards.


On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl> wrote:

> distinct() doesn't require everything to be pulled. It can push elements
> to the downstream as they come along for the first time. When
> downstream.push returns false the gatherer is done.
>
> As part of some experimentation I've implemented all intermediary
> operations using gatherers. Most of them are pretty straightforward and
> will stop integrating once the downstream starts rejecting elements
> (although some use Gatherer.ofSequential to keep it easy). I only found
> two exceptions that don't return the result of downstream.push:
>
> * mapMulti. The downstream.push is passed as the mapper which is a
> Consumer - the return value is ignored. With some more effort it's
> probably possible to capture any false return value and return that from
> the integrator, but I haven't tried that yet.
>
> * sorted. Obviously every element needs to be inspected.
>
>
> On 13/11/2024 00:37, David Alayachew wrote:
> > Oh sure, I expect something like distinct() to pull everything. In order
> to
> > know if something is distinct, you have to do some variant of "check
> > against everyone else". Whether that is holding all instances in memory
> or
> > their hashes, it's clear from a glance that you will need to look at
> > everything, and therefore, pre-fetching makes intuitive sense to me.
> >
> > I 100% did not expect terminal operations like findAny() or reduce() to
> > pull the whole data set. That was a complete whiplash for me. The method
> > findAny() advertises itself as a short-circuiting operation, so to find
> out
> > that it actually pulls the whole data set anyways was shocking.
> >
> > And that was my biggest pain point -- looking at the documentation, it is
> > not clear to me at all that methods like findAny() would pull in all data
> > upon becoming parallel().
> >
> > Do you think it would make sense to add documentation about this to the
> > javadocs for Stream/java.util.stream? Or maybe it is already there and I
> > misunderstood it (even after reading through it thoroughly over 5 times).
> >
> >
> > On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
> >
> >>> We are told how Streams can process unbounded data sets, but when it
> >> tries to do a findAny() with parallel(), it runs into an OOME because it
> >> fetched all the data ahead of time. In fact, almost of the terminal
> >> operations will hit an OOME in the exact same way if they are parallel
> and
> >> have a big enough data set. It's definitely not the end of the world,
> but
> >> it seems that I have to fit everything into a Collector and/or a
> Gatherer
> >> if I want to avoid pre-fetching everything.
> >>
> >> Yeah, I think it is important to distinguish "can process unbounded data
> >> sets" from "always able to process unbounded data sets".
> >>
> >> Some operations inherently need the end of the stream, so even something
> >> somple like: stream.distinct() or stream.sorted() can end up pulling in
> all
> >> data (which of course won't terminate).
> >>
> >> Fortunately, I think Gatherers can unlock much more situations where
> >> unbounded streams can be processed.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 15:08
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Oh woah. I certainly did not. Or rather, I had dismissed the idea as
> soon
> >> as I thought of it.
> >>
> >>
> >> I hand-waved away the idea because I thought that the method would turn
> >> the stream pipeline parallel, thus, recreating the same problem I
> currently
> >> have of parallelism causing all of the elements to be fetched ahead of
> >> time, causing an OOME.
> >>
> >>
> >> It did NOT occur to me that the pipeline would stay sequential, and just
> >> kick these off sequentially, but have them executing in parallel. I
> can't
> >> see why I came to that incorrect conclusion. I have read the javadocs of
> >> this method several times. Though, to be fair, I came to the same,
> >> incorrect conclusion about Collectors.groupingByConcurrent(), and it
> wasn't
> >> until someone pointed out what the documentation was actually saying
> that I
> >> realized it's true properties.
> >>
> >> Thanks. That definitely solves at least part of my problem. Obviously, I
> >> would prefer to write to S3 in parallel too, but at the very least, the
> >> calculation part is being done in parallel. And worst case scenario, I
> can
> >> be really bad and just do the write to S3 in the mapConcurrent, and then
> >> just return the metadata of each write, and just bundle that up with
> >> collect.
> >>
> >>
> >> And that's ignoring the fact that I can just use the workaround too.
> >>
> >>
> >> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
> >> from a performance perspective, but is rather unintuitive to me from a
> >> usability perspective. We are told how Streams can process unbounded
> data
> >> sets, but when it tries to do a findAny() with parallel(), it runs into
> an
> >> OOME because it fetched all the data ahead of time. In fact, almost of
> the
> >> terminal operations will hit an OOME in the exact same way if they are
> >> parallel and have a big enough data set. It's definitely not the end of
> the
> >> world, but it seems that I have to fit everything into a Collector
> and/or a
> >> Gatherer if I want to avoid pre-fetching everything.
> >>
> >> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Have you considered Gatherers.mapConcurrent(?)?
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 01:53
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >> Good to know, ty vm.
> >>
> >> At the very least, I have this workaround. This will meet my needs for
> now.
> >>
> >> I guess my final question would be -- is this type of problem better
> >> suited to something besides parallel streams? Maybe an ExecutorService?
> >>
> >> Really, all I am doing is taking a jumbo file, splitting it into
> batches,
> >> and then doing some work on those batches. My IO speeds are pretty fast,
> >> and the compute work is non-trivial, so there is performance being left
> on
> >> the table if I give up parallelism. And I am in a position where
> completion
> >> time is very important to us.
> >>
> >> I just naturally assumed parallel streams were the right choice because
> >> the compute work is simple. A pure function that I can break out, and
> then
> >> call in a map. Once I do that, I just call forEach to write the batches
> >> back out to S3. Maybe I should look into a different part of the std lib
> >> instead because I am using the wrong tool for the job? My nose says
> >> ExecutorService, but I figure I should ask before I dive too deep in.
> >>
> >>
> >> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> You're most welcome!
> >>
> >> In a potential future where all intermediate operations are
> >> Gatherer-based, and all terminal operations are Collector-based, it
> would
> >> just work as expected. But with that said, I'm not sure it is
> practically
> >> achievable because some operations might not have the same
> >> performance-characteristics as before.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 18:32
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Thanks for the workaround. It's running beautifully.
> >>
> >> Is there a future where this island concept is extended to the rest of
> >> streams? Tbh, I don't fully understand it.
> >>
> >> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Hi David,
> >>
> >> This is the effect of how parallel streams are implemented, where
> >> different stages, which are not representible as a join-less Spliterator
> >> are executed as a series of "islands" where the next isn't started until
> >> the former has completed.
> >>
> >> If you think about it, parallelization of a Stream works best when the
> >> entire data set can be split amongst a set of worker threads, and that
> sort
> >> of implies that you want eager pre-fetch of data, so if your dataset
> does
> >> not fit in memory, that is likely to lead to less desirable outcomes.
> >>
> >> What I was able to do for Gatherers is to implement "gather(?) +
> >> collect(?)"-fusion so any number of consecutive gather(?)-operations
> >> immediately followed by a collect(?) is run in the same "island".
> >>
> >> So with that said, you could try something like the following:
> >>
> >> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T>
> *each*) {
> >>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e),
> (*l*,
> >> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> >> }
> >>
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .collect(forEach(eachList -> println(eachList.getFirst())));
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> David
> >> Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 14:52
> >> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> >> elements
> >>
> >> And just to avoid the obvious question, I can hold about 30 batches in
> >> memory before the Out of Memory error occurs. So this is not an issue
> of my
> >> batch size being too high.
> >>
> >> But just to confirm, I set the batch size to 1, and it still ran into an
> >> out of memory error. So I feel fairly confident saying that the
> Gatherer is
> >> trying to grab all available data before sending any of it downstream.
> >>
> >> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com
> >
> >> wrote:
> >>
> >> Hello Core Libs Dev Team,
> >>
> >> I was trying out Gatherers for a project at work, and ran into a rather
> >> sad scenario.
> >>
> >> I need to process a large file in batches. Each batch is small enough
> that
> >> I can hold it in memory, but I cannot hold the entire file (and thus,
> all
> >> of the batches) in memory at once.
> >>
> >> Looking at the Gatherers API, I saw windowFixed and thought that it
> would
> >> be a great match for my use case.
> >>
> >> However, when trying it out, I was disappointed to see that it ran out
> of
> >> memory very quickly. Here is my attempt at using it.
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .forEach(eachList -> println(eachList.getFirst()))
> >> ;
> >>
> >> As you can see, I am just splitting the file into batches, and printing
> >> out the first of each batch. This is purely for example's sake, of
> course.
> >> I had planned on building even more functionality on top of this, but I
> >> couldn't even get past this example.
> >>
> >> But anyways, not even a single one of them printed out. Which leads me
> to
> >> believe that it's pulling all of them in the Gatherer.
> >>
> >> I can get it to run successfully if I go sequentially, but not parallel.
> >> Parallel gives me that out of memory error.
> >>
> >> Is there any way for me to be able to have the Gatherer NOT pull in
> >> everything while still remaining parallel and unordered?
> >>
> >> Thank you for your time and help.
> >> David Alayachew
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241113/ff0d2cb7/attachment-0001.htm>

From dl at openjdk.org  Wed Nov 13 13:17:18 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 13 Nov 2024 13:17:18 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v26]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <NEhdAmXbti0eqPLjPGboF5NgewhKwsDXDWzQQdHbMS8=.8c01d69c-2ef4-4c43-9440-b996c9e8a3a7@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Rename variable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/3ea2470c..a5f038f9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=25
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=24-25

  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From dl at openjdk.org  Wed Nov 13 13:17:19 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 13 Nov 2024 13:17:19 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v26]
In-Reply-To: <8GMHQcemGFpM3_YrkOgVr1l4fdMvMB_ybKNe5_lZP-Y=.28eafa87-82b1-4b94-b717-17179750980a@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <OV20MMXk7ursVA9jhoyAUY5zjy52SGF45XCEgC3qgno=.5b0765a8-4bfc-4eaa-8868-ec097a7cf36d@github.com>
 <8GMHQcemGFpM3_YrkOgVr1l4fdMvMB_ybKNe5_lZP-Y=.28eafa87-82b1-4b94-b717-17179750980a@github.com>
Message-ID: <QB-x4C7Ry7_Lbd6Gz62JaSjkr3pVYkhDrJh4W0MB50I=.ff421006-f393-4acf-9201-af8850d56a85@github.com>

On Wed, 13 Nov 2024 08:55:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Rename variable
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2617:
> 
>> 2615:                 if (q != null)
>> 2616:                     return q;
>> 2617:                 if (shutdown != 0L)
> 
> @DougLea Any benefit of doing this vs `boolean shutdown = (lockRunState() & SHUTDOWN) != 0L` and check `!shutdown` and `shutdown`

It doesn't seem to matter with respect to generated code. I did it this way for symmetry to other similar usages (including tryTerminate) but for more symmetry should have named it isShutdown, so just changed it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1840246733

From duke at openjdk.org  Wed Nov 13 13:17:31 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 13 Nov 2024 13:17:31 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:

 - Merge remote-tracking branch 'upstream-jdk/master' into serialization
 - Round out the documentation of the new methods to explain the supported and unsupported cases
 - Move `serialPersistentFields` for a degree of method order consistency
 - Address review feedback
 - Test fixes and finish renaming
 - Address review feedback
 - Address review comment
 - Eliminate cache
 - Rework using facilities found in ObjectStreamClass
   
   This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
 - More tests
 - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346

-------------

Changes: https://git.openjdk.org/jdk/pull/19702/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=08
  Stats: 916 lines in 6 files changed: 913 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From rriggs at openjdk.org  Wed Nov 13 14:12:34 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 14:12:34 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v2]
In-Reply-To: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
Message-ID: <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary suppress warnings removal
  ServiceLoader configuration exceptions (in a static initialization) are rethrown as Error.
  Remove dependency on SecurityException thrown by ServiceLoader (as obsolete)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22042/files
  - new: https://git.openjdk.org/jdk/pull/22042/files/96a8d26c..0f2e92f5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22042&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22042&range=00-01

  Stats: 5 lines in 1 file changed: 0 ins; 4 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22042/head:pull/22042

PR: https://git.openjdk.org/jdk/pull/22042

From mullan at openjdk.org  Wed Nov 13 14:31:41 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Nov 2024 14:31:41 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v2]
In-Reply-To: <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
 <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
Message-ID: <jby7R0SL7l_5JCJZ_4xLbQf2SXPM0NPoAOlTEiEDivs=.72a44c85-1d40-4b60-bbc7-f4b1c82cafe8@github.com>

On Wed, 13 Nov 2024 14:12:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary suppress warnings removal
>   ServiceLoader configuration exceptions (in a static initialization) are rethrown as Error.
>   Remove dependency on SecurityException thrown by ServiceLoader (as obsolete)

src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java line 1:

> 1: /*

Lines 171-172:

                if (ex.getCause() instanceof SecurityException) {
                    continue;  // ignore the security exception, try the next provider
                }

You may be able to remove this code, but may be better to leave it as-is for now until the SL code has been checked for cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22042#discussion_r1840369340

From duke at openjdk.org  Wed Nov 13 14:35:35 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 13 Nov 2024 14:35:35 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
Message-ID: <rFazSuui4kPRPxh0r6CE1XuXKNsMytZZcOZEKkzeO6s=.632872a6-34b1-44ae-941b-330edf59aacf@github.com>

On Wed, 13 Nov 2024 13:17:31 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - Eliminate cache
>  - Rework using facilities found in ObjectStreamClass
>    
>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>  - More tests
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346

The failure on Mac is some kind of tooling setup error:


xcode-select: error: invalid developer directory '/Applications/Xcode_14.3.1.app/Contents/Developer'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2473790153

From mullan at openjdk.org  Wed Nov 13 14:36:35 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Nov 2024 14:36:35 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v2]
In-Reply-To: <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
 <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
Message-ID: <9Y6lZCntKbFfd7vt_4S1uA_DMgoKM_r0ur9py-KJgik=.4ced80c3-ef7b-4e48-a369-4e486de19203@github.com>

On Wed, 13 Nov 2024 14:12:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary suppress warnings removal
>   ServiceLoader configuration exceptions (in a static initialization) are rethrown as Error.
>   Remove dependency on SecurityException thrown by ServiceLoader (as obsolete)

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22042#pullrequestreview-2433433270

From pminborg at openjdk.org  Wed Nov 13 14:37:11 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 14:37:11 GMT
Subject: RFR: 8344086: Remove security manager dependency in FFM
Message-ID: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>

This PR proposes to remove the security manager dependencies in the FFM implementing classes.

-------------

Commit messages:
 - Remove security manager related code

Changes: https://git.openjdk.org/jdk/pull/22071/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22071&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344086
  Stats: 72 lines in 11 files changed: 5 ins; 33 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/22071.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22071/head:pull/22071

PR: https://git.openjdk.org/jdk/pull/22071

From alanb at openjdk.org  Wed Nov 13 14:41:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 14:41:57 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v2]
In-Reply-To: <jby7R0SL7l_5JCJZ_4xLbQf2SXPM0NPoAOlTEiEDivs=.72a44c85-1d40-4b60-bbc7-f4b1c82cafe8@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
 <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
 <jby7R0SL7l_5JCJZ_4xLbQf2SXPM0NPoAOlTEiEDivs=.72a44c85-1d40-4b60-bbc7-f4b1c82cafe8@github.com>
Message-ID: <UHnOrnTsL2N0Z0H0SYMUgW8ny82x1PrvKK-QpMjsGwE=.3e5aa5e7-fd78-4d96-864a-495d195fc8d9@github.com>

On Wed, 13 Nov 2024 14:13:59 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove unnecessary suppress warnings removal
>>   ServiceLoader configuration exceptions (in a static initialization) are rethrown as Error.
>>   Remove dependency on SecurityException thrown by ServiceLoader (as obsolete)
>
> src/java.base/share/classes/java/time/zone/ZoneRulesProvider.java line 1:
> 
>> 1: /*
> 
> Lines 171-172:
> 
>                 if (ex.getCause() instanceof SecurityException) {
>                     continue;  // ignore the security exception, try the next provider
>                 }
> 
> You may be able to remove this code, but may be better to leave it as-is for now until the SL code has been checked for cleanup.

The SL changes are in JDK-8344011.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22042#discussion_r1840444817

From rriggs at openjdk.org  Wed Nov 13 14:44:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 14:44:56 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v4]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <B-N0ZIRnkx7pXEZdW83kfPBhTHDMCHZlQv8j1_oyO4s=.689fc890-03b4-45fe-adf4-b6c17d3864e0@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove overlooked SecurityManager use in ObjectInputFilter and ObjectStreamClass

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22041/files
  - new: https://git.openjdk.org/jdk/pull/22041/files/3f850839..3e56ef09

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=02-03

  Stats: 16 lines in 2 files changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From mullan at openjdk.org  Wed Nov 13 14:46:44 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Nov 2024 14:46:44 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v2]
In-Reply-To: <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
 <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
Message-ID: <WWzsZy-Qk5Iak-MBGe4ZOClBqNgkYVXAaqQee6jKtuE=.90e51c28-c6b8-4130-8d2d-8695c37ddfa6@github.com>

On Wed, 13 Nov 2024 14:12:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary suppress warnings removal
>   ServiceLoader configuration exceptions (in a static initialization) are rethrown as Error.
>   Remove dependency on SecurityException thrown by ServiceLoader (as obsolete)

The PR description above seems to be copied from the serialization PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22042#issuecomment-2473818246

From pminborg at openjdk.org  Wed Nov 13 14:48:37 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 14:48:37 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v15]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <EVYwENtX2A4zrpbGK2BWxXT4IM2fW9OoCaYa9VFVxio=.5dad5a00-3fb5-4a27-860c-ec331294203b@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 33 additional commits since the last revision:

 - Merge branch 'master' into linker-padding-layout-only
 - Update after comments
 - Merge branch 'master' into linker-padding-layout-only
 - Simplify exception testing
 - Merge branch 'master' into linker-padding-layout-only
 - Remove redundant check
 - Rephrase doc
 - Improve language
 - Add checks of exception messages
 - Update test/jdk/java/foreign/TestLinker.java
   
   Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
 - ... and 23 more: https://git.openjdk.org/jdk/compare/75a052c9...97f8da66

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/786b1737..97f8da66

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=13-14

  Stats: 81811 lines in 2251 files changed: 9940 ins; 66399 del; 5472 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From lancea at openjdk.org  Wed Nov 13 14:46:44 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 13 Nov 2024 14:46:44 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v2]
In-Reply-To: <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
 <rxv94CJtaTg97A6girvDp3iEjOfciBpiZWfLdvYjPas=.422b522b-21b9-4d45-9905-54c09a37ec93@github.com>
Message-ID: <kZ1reR6ZrflbqcQu0Vs3um0gILGSn7EcMYLmd2JZWLI=.30e900fe-b707-4df2-a6a6-380cbe1b85f1@github.com>

On Wed, 13 Nov 2024 14:12:34 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unnecessary suppress warnings removal
>   ServiceLoader configuration exceptions (in a static initialization) are rethrown as Error.
>   Remove dependency on SecurityException thrown by ServiceLoader (as obsolete)

Looks good to me Roger

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22042#pullrequestreview-2433460607

From rriggs at openjdk.org  Wed Nov 13 14:51:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 14:51:07 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v3]
In-Reply-To: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
Message-ID: <hp7BJFRImE16eDqCGvuvhS9_A6i_V4tbh8gs97uo1aA=.2018e299-f914-43b4-b8c6-481e90f76e38@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on doPriviledged and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Retain check for SecurityException until ServiceLoader cleanup is complete.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22042/files
  - new: https://git.openjdk.org/jdk/pull/22042/files/0f2e92f5..23f149e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22042&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22042&range=01-02

  Stats: 4 lines in 1 file changed: 3 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22042.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22042/head:pull/22042

PR: https://git.openjdk.org/jdk/pull/22042

From alanb at openjdk.org  Wed Nov 13 14:54:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 14:54:53 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v4]
In-Reply-To: <B-N0ZIRnkx7pXEZdW83kfPBhTHDMCHZlQv8j1_oyO4s=.689fc890-03b4-45fe-adf4-b6c17d3864e0@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <B-N0ZIRnkx7pXEZdW83kfPBhTHDMCHZlQv8j1_oyO4s=.689fc890-03b4-45fe-adf4-b6c17d3864e0@github.com>
Message-ID: <BAH97c0PGd8cKTL4RpYYMhKz4-rrlsBz4eqFH5nylTg=.00a2067d-1cc1-4fba-ad2d-79df50f3a6d8@github.com>

On Wed, 13 Nov 2024 14:44:56 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove overlooked SecurityManager use in ObjectInputFilter and ObjectStreamClass

src/java.base/share/classes/java/io/ObjectStreamField.java line 166:

> 164:     @SuppressWarnings("removal")
> 165:     @CallerSensitive
> 166:     public Class<?> getType() {

This method is no longer caller sensitive, also no need to import ReflectUtil now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1840484140

From rriggs at openjdk.org  Wed Nov 13 14:54:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 14:54:54 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
 <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
Message-ID: <vG63zk_8PN2kCk3hG1ODRJ5j1UwgookNYY1Vn2uPGUM=.4934f263-e5c9-43ad-9c39-3b64ef259b55@github.com>

On Tue, 12 Nov 2024 18:47:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Removes the SecurityManager usage from Thread + friends.
>> 
>> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
>> 
>> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8343981
>  - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
>  - Initial commit
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...636ebd19

LGTM

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22035#pullrequestreview-2433491246

From mcimadamore at openjdk.org  Wed Nov 13 15:16:35 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 15:16:35 GMT
Subject: RFR: 8344086: Remove security manager dependency in FFM
In-Reply-To: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
References: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
Message-ID: <MLhXQks2Oq3IIHLQxhpoHNKBNoG7h48vUbB1mSIZUfI=.e86f3628-e129-477d-9895-d2ac9cb4413b@github.com>

On Wed, 13 Nov 2024 13:48:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the security manager dependencies in the FFM implementing classes.

Nice cleanup!

-------------

Marked as reviewed by mcimadamore (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22071#pullrequestreview-2433556003

From pminborg at openjdk.org  Wed Nov 13 15:21:24 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 15:21:24 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v16]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <GSUee2bqFC9HCLW4SMRt3tFkoPnjrLK0eV4xlQ-V6lI=.89739729-ef55-4f09-a46b-abf7432c2d2c@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix failing test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/97f8da66..69e6593d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=14-15

  Stats: 6 lines in 2 files changed: 2 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From mcimadamore at openjdk.org  Wed Nov 13 15:22:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 15:22:20 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v6]
In-Reply-To: <wGw56NfcZDgy2xiyV-UDq8B6SuyT3SbsHB93ebjida0=.1a2e9fca-62a2-4aa1-b32f-12507364e562@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <wGw56NfcZDgy2xiyV-UDq8B6SuyT3SbsHB93ebjida0=.1a2e9fca-62a2-4aa1-b32f-12507364e562@github.com>
Message-ID: <ax1mtXG6Sv3MIF7RwJY-Zpj4aWOUHIQAErNVCI2yEOI=.5ccb0364-d6fd-4683-b7f9-292e418d7139@github.com>

On Tue, 12 Nov 2024 16:15:31 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is not issuing a mandated unchecked cast warning for code like:
>> 
>> 
>> import java.lang.invoke.VarHandle;
>> 
>> class VarHandleCast<V> {
>>      VarHandle vh;
>>      V method(Object obj) {
>>          return (V)vh.getAndSet(this, obj);
>>      }
>> }
>> 
>> 
>> according to the spec the return type inferred for this method polymorphic method should be Object see:
>> 
>> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
>> ...
>>     ? The compile-time result is determined as follows:
>>         Otherwise, if the method invocation expression is the operand of a cast
>>     expression (?15.16), the compile-time result is the erasure of the type of the
>>     cast expression (?4.6).
>> 
>> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
>> 
>> TIA
>> 
>> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   adding regression test

src/jdk.compiler/share/classes/com/sun/tools/javac/code/Source.java line 266:

> 264:         MODULE_IMPORTS(JDK23, Fragments.FeatureModuleImports, DiagKind.PLURAL),
> 265:         PRIVATE_MEMBERS_IN_PERMITS_CLAUSE(JDK19),
> 266:         COMPILE_TIME_TYPE_SIG_POLYMORPHIC_MTH(JDK24),

Nit: I'd pick a name that is more representative of what the behavior is. E.g. `erase_poly_sig_return_type`. Same for the field in `Infer` storing the boolean flag.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21914#discussion_r1840566249

From rriggs at openjdk.org  Wed Nov 13 15:28:14 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 15:28:14 GMT
Subject: RFR: 8344086: Remove security manager dependency in FFM
In-Reply-To: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
References: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
Message-ID: <Kvm1dsaB6dwEf2IZYSlBPy_NdNEIeYFLFDaGrbYP4aQ=.7191802a-c79d-408f-a032-1efdcb8a672c@github.com>

On Wed, 13 Nov 2024 13:48:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the security manager dependencies in the FFM implementing classes.

lgtm

src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 128:

> 126:      */
> 127:     private static Path jdkLibraryPath(String name) {
> 128:         Path javahome = Path.of(System.getProperty("java.home"));

If not out of scope for this PR:
System property java.home is available in a static; will need an `import jdk.internal.util.StaticProperty`
Suggestion:

        Path javahome = StaticProperty.javaHome();

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22071#pullrequestreview-2433591071
PR Review Comment: https://git.openjdk.org/jdk/pull/22071#discussion_r1840583128

From cstein at openjdk.org  Wed Nov 13 15:31:00 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 13 Nov 2024 15:31:00 GMT
Subject: RFR: 8316804: Gracefully handle the case where --release is not
 specified last
Message-ID: <P_31GGK7WG72JM2gXTV9BBgCcX5x-I8N0LH9vhdytGQ=.a40d1769-f299-4b58-9bee-5ad6008dadd4@github.com>

Please review this change for the `jar` tool to gracefully handle the case where `--release` is not specified as the last arguments.

Prior to this commit, operation modes `-d --describe-module` and `--validate` expected to read the optional `--release` option as a file argument: `jar -d -f a.jar --release 9`
By adding a hidden GNU-style `--release` option, processing the optional arguments before in those two operation modes, the position is now no longer required to trail behind the `-f --file` option: `jar -d --release 9 -f a.jar`

-------------

Commit messages:
 - 8316804: Gracefully handle the case where --release is not specified last

Changes: https://git.openjdk.org/jdk/pull/22079/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22079&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8316804
  Stats: 45 lines in 2 files changed: 35 ins; 3 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22079/head:pull/22079

PR: https://git.openjdk.org/jdk/pull/22079

From rriggs at openjdk.org  Wed Nov 13 15:31:11 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 15:31:11 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v5]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <w-Lf-X2Eoh8KikxMZKMjo2hTum0SChWqDW3imMpygLw=.48b2a052-af5e-4422-9096-17f75424fddd@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove CallerSensitive and suppress warnings

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22041/files
  - new: https://git.openjdk.org/jdk/pull/22041/files/3e56ef09..8c1fc41d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From vromero at openjdk.org  Wed Nov 13 15:35:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Nov 2024 15:35:30 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v7]
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <A3CuI2UqyYDYGe2J55I9vIm5SGoTyaTEWVykqK6bv2E=.708273e9-96db-40be-94ad-6c5a696f2e69@github.com>

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:

  address review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21914/files
  - new: https://git.openjdk.org/jdk/pull/21914/files/a99c4547..36011fa7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21914&range=05-06

  Stats: 4 lines in 2 files changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21914.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21914/head:pull/21914

PR: https://git.openjdk.org/jdk/pull/21914

From mcimadamore at openjdk.org  Wed Nov 13 15:35:30 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Wed, 13 Nov 2024 15:35:30 GMT
Subject: RFR: 8343286: Missing unchecked cast warning in polymorphic method
 call [v7]
In-Reply-To: <A3CuI2UqyYDYGe2J55I9vIm5SGoTyaTEWVykqK6bv2E=.708273e9-96db-40be-94ad-6c5a696f2e69@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
 <A3CuI2UqyYDYGe2J55I9vIm5SGoTyaTEWVykqK6bv2E=.708273e9-96db-40be-94ad-6c5a696f2e69@github.com>
Message-ID: <8EUvDlccN0eNRa4qj-i32rQRnDraTCOR2_fLkQUBLFc=.67d3ff9f-b7dc-4c9d-83b8-6ced8c707e2a@github.com>

On Wed, 13 Nov 2024 15:31:59 GMT, Vicente Romero <vromero at openjdk.org> wrote:

>> Javac is not issuing a mandated unchecked cast warning for code like:
>> 
>> 
>> import java.lang.invoke.VarHandle;
>> 
>> class VarHandleCast<V> {
>>      VarHandle vh;
>>      V method(Object obj) {
>>          return (V)vh.getAndSet(this, obj);
>>      }
>> }
>> 
>> 
>> according to the spec the return type inferred for this method polymorphic method should be Object see:
>> 
>> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
>> ...
>>     ? The compile-time result is determined as follows:
>>         Otherwise, if the method invocation expression is the operand of a cast
>>     expression (?15.16), the compile-time result is the erasure of the type of the
>>     cast expression (?4.6).
>> 
>> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
>> 
>> TIA
>> 
>> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug
>
> Vicente Romero has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address review comments

Marked as reviewed by mcimadamore (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21914#pullrequestreview-2433605574

From vromero at openjdk.org  Wed Nov 13 15:35:30 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Nov 2024 15:35:30 GMT
Subject: Integrated: 8343286: Missing unchecked cast warning in polymorphic
 method call
In-Reply-To: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
References: <ygYmwOIWZjf1ogu_DHrqd4d65hGRamD6VHRPynV_vJI=.65b2019f-6c39-45bc-884f-4732f4c8ae06@github.com>
Message-ID: <Fqx0NIJJkeQHLnYesAgdBrxmS8W4C8Tgt-Dk2KbwytU=.36fcc7c3-123f-4754-9675-360a31e5c029@github.com>

On Tue, 5 Nov 2024 19:51:04 GMT, Vicente Romero <vromero at openjdk.org> wrote:

> Javac is not issuing a mandated unchecked cast warning for code like:
> 
> 
> import java.lang.invoke.VarHandle;
> 
> class VarHandleCast<V> {
>      VarHandle vh;
>      V method(Object obj) {
>          return (V)vh.getAndSet(this, obj);
>      }
> }
> 
> 
> according to the spec the return type inferred for this method polymorphic method should be Object see:
> 
> -  If the compile-time declaration for the method invocation is a signature polymorphic method, then:
> ...
>     ? The compile-time result is determined as follows:
>         Otherwise, if the method invocation expression is the operand of a cast
>     expression (?15.16), the compile-time result is the erasure of the type of the
>     cast expression (?4.6).
> 
> javac is not doing the type erasure mandated by the spec which is what this PR is fixing
> 
> TIA
> 
> Note: I had to add some annotations to suppress warnings in java.base that were not being issued before due to the javac bug

This pull request has now been integrated.

Changeset: cc2acd14
Author:    Vicente Romero <vromero at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc2acd14b13ada243fc13dc4d9007c4e2df56148
Stats:     40 lines in 10 files changed: 38 ins; 0 del; 2 mod

8343286: Missing unchecked cast warning in polymorphic method call

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/21914

From rriggs at openjdk.org  Wed Nov 13 15:35:42 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 15:35:42 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v6]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <iC-cWokw4nc5UHR3tB7SbIrqheofd8wFW8Vbl2l13zY=.77db0c69-28a1-49cb-a4b7-831e119f136f@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove unused imports

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22041/files
  - new: https://git.openjdk.org/jdk/pull/22041/files/8c1fc41d..054b410f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=04-05

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From shade at openjdk.org  Wed Nov 13 15:38:35 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 15:38:35 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [ ] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Merge branch 'master' into JDK-8343704-cleaner-gc
 - Merge branch 'master' into JDK-8343704-cleaner-gc
 - Touchups: assert index, polish commits
 - Fix

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/885edc1b..0194c9bc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=02-03

  Stats: 374 lines in 43 files changed: 159 ins; 98 del; 117 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From liach at openjdk.org  Wed Nov 13 15:39:51 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 15:39:51 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v3]
In-Reply-To: <o5HiIN5U5d0ixXd5lZHPf37eRt-NmZSPjyXtwXnSaLI=.eac889b7-9f02-4a18-b8c8-6df178650c9b@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <XKYOEauGPTGzkT4z7PvZPgs8B8mIppxeEq7h-s_SXMM=.3edde68d-c7a1-4aa6-97ec-40b7341397b0@github.com>
 <NnLYzFQUq5lD74naODisuOtPO33PwhHwrFx2zIjGQ9g=.8512c0e2-291d-455e-b178-b209cff2ef2f@github.com>
 <BIjPAsbyucO4yNCoRJzRhl2qfQf3v5H_T7wJx0_Vw0g=.7cfea631-9e08-450f-819d-b081c29420e9@github.com>
 <o5HiIN5U5d0ixXd5lZHPf37eRt-NmZSPjyXtwXnSaLI=.eac889b7-9f02-4a18-b8c8-6df178650c9b@github.com>
Message-ID: <uebxNmJSB7bLPaUXepnOBj7YoDYsl8BRZEnJjSKRoV0=.e9283874-00df-4323-9c75-3588e006746d@github.com>

On Wed, 13 Nov 2024 09:10:57 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

>> Re this sentence: I wish to indicate "caller is unloaded and impl class is unreachable elsewhere (besides in the ClassLoader)".  Maybe just "caller is unloaded" is fine. Thoughts on phrasing?
>
> Maybe 'caller's class is unloaded'.
> 
> Also, is the link correct? It links to the STRONG option, but the link text is 'hidden class'.

The link is intended: I wish the link to describe the unloadable scenario for hidden classes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1840617057

From rriggs at openjdk.org  Wed Nov 13 15:40:38 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 15:40:38 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
Message-ID: <HAE0WD_xO0at-YRQHw-xi2OekDa8XvQifoRYAini3nE=.f7c8cb89-b3ad-4621-9447-84981aeffff5@github.com>

On Wed, 13 Nov 2024 13:17:31 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - Eliminate cache
>  - Rework using facilities found in ObjectStreamClass
>    
>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>  - More tests
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346

With the SecurityManager (jep 486) integrated, cleanup of referernces to SecurityManager etc will need to be cleanedup.
It can be done as a separate PR or included in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2473974361

From jvernee at openjdk.org  Wed Nov 13 15:46:25 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Nov 2024 15:46:25 GMT
Subject: RFR: 8344086: Remove security manager dependency in FFM
In-Reply-To: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
References: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
Message-ID: <PZsFb-99KOxxVsgBV383d697M1xutHlbJCoO97qE61g=.bf68bbec-e8a0-4497-a935-93f5b49a1006@github.com>

On Wed, 13 Nov 2024 13:48:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the security manager dependencies in the FFM implementing classes.

Marked as reviewed by jvernee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22071#pullrequestreview-2433649735

From duke at openjdk.org  Wed Nov 13 15:49:47 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 13 Nov 2024 15:49:47 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <HAE0WD_xO0at-YRQHw-xi2OekDa8XvQifoRYAini3nE=.f7c8cb89-b3ad-4621-9447-84981aeffff5@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
 <HAE0WD_xO0at-YRQHw-xi2OekDa8XvQifoRYAini3nE=.f7c8cb89-b3ad-4621-9447-84981aeffff5@github.com>
Message-ID: <Z5yH2yOXOL2b_quVOwJ3nF1U2fI7r4ah-nw9ZNw7ghE=.df0c7d88-27ba-4cd3-a7a0-71ee725b7f2a@github.com>

On Wed, 13 Nov 2024 15:37:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With the SecurityManager (jep 486) integrated, cleanup of referernces to SecurityManager etc will need to be cleanedup. It can be done as a separate PR or included in this PR.

I already did this as part of the upstream merge (there was a conflict with the security policy so I also removed the `doPrivileged` from the tests at the same time that I resolved the conflict).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2474001531

From rriggs at openjdk.org  Wed Nov 13 15:51:44 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 15:51:44 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v5]
In-Reply-To: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
Message-ID: <1oJga566b3c4g8iZnqUVjeR4vCjFuLzhlo92debLSEc=.f18f48bf-5111-42bb-9b70-d0449d194f53@github.com>

> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.

Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:

 - Merge branch '8343958-process-sm-cleanup' of https://github.com/RogerRiggs/jdk into 8343958-process-sm-cleanup
 - Revert unnecessary copyright change in ProcessEnvironment.java.
   Fix code style in ProcessImpl
   Drop unneeded suppress warnings.
   Remove obsolete @throws SecurityExceptions
   Correct compilation errors in Windows ProcessImpl

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22024/files
  - new: https://git.openjdk.org/jdk/pull/22024/files/accc6df3..16d11e1c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22024&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22024&range=03-04

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22024.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22024/head:pull/22024

PR: https://git.openjdk.org/jdk/pull/22024

From rriggs at openjdk.org  Wed Nov 13 15:51:45 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 15:51:45 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v4]
In-Reply-To: <LG-GAZoaZECXPthNc-oQmraMbo_KHTupSyaGlewOi1Y=.9feeca4a-e6cc-4cc7-942a-088ab2224823@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
 <WodpAoIcb2kM-jAV18jyCP7BTtFLqKR_azUpO7cQ6Hc=.510fc507-25b0-411d-86ee-0bd2afd52eab@github.com>
 <IoMhcCkViKjAp009qT1ZGyq4FI-Ch_mJKz9ZwPz5yRE=.1cc9a0a8-d4cf-40e5-ad1d-7588200c4916@github.com>
 <LG-GAZoaZECXPthNc-oQmraMbo_KHTupSyaGlewOi1Y=.9feeca4a-e6cc-4cc7-942a-088ab2224823@github.com>
Message-ID: <7UIOJe6XcLVOkG3ZYySjhPKDsfLuXBItVesGMxYNwsY=.afe28b9d-d2e7-4956-b7c0-263186ba77c7@github.com>

On Wed, 13 Nov 2024 11:39:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Actually, looking at the GitHub actions job, it appears to have caught one other compilation error in this file:
>> 
>> 
>> jdk\jdk\src\java.base\windows\classes\java\lang\ProcessImpl.java:423: error: ';' expected
>>         final String value = System.getProperty("jdk.lang.Process.allowAmbiguousCommands", "true"));
>>                                                                                                   ^
>> 1 error
>
> I assume Roger will run at least tier1 on all platforms before integrating.

Inadvertent lapse.
Retested in the CI on all platforms

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1840655371

From rriggs at openjdk.org  Wed Nov 13 15:53:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 15:53:41 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
Message-ID: <emFPpFaANkv9aaGmICcMXQh4Z9apLU0u1QFe7OAQbKA=.a9333a02-1aff-46db-b1cc-6d266b841956@github.com>

On Wed, 13 Nov 2024 13:17:31 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - Eliminate cache
>  - Rework using facilities found in ObjectStreamClass
>    
>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>  - More tests
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 44:

> 42: import java.lang.reflect.Modifier;
> 43: import java.lang.reflect.Proxy;
> 44: import java.security.PrivilegedAction;

Unneeded import.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1840659630

From jpai at openjdk.org  Wed Nov 13 15:58:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Nov 2024 15:58:23 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v5]
In-Reply-To: <1oJga566b3c4g8iZnqUVjeR4vCjFuLzhlo92debLSEc=.f18f48bf-5111-42bb-9b70-d0449d194f53@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <1oJga566b3c4g8iZnqUVjeR4vCjFuLzhlo92debLSEc=.f18f48bf-5111-42bb-9b70-d0449d194f53@github.com>
Message-ID: <raJgBbydER-1G-Aj1jSAKHGvRZeuwA5qAy_dq5Qnc1w=.f91e361e-3c72-4a34-8d0f-0b3645eabc10@github.com>

On Wed, 13 Nov 2024 15:51:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8343958-process-sm-cleanup' of https://github.com/RogerRiggs/jdk into 8343958-process-sm-cleanup
>  - Revert unnecessary copyright change in ProcessEnvironment.java.
>    Fix code style in ProcessImpl
>    Drop unneeded suppress warnings.
>    Remove obsolete @throws SecurityExceptions
>    Correct compilation errors in Windows ProcessImpl

Marked as reviewed by jpai (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22024#pullrequestreview-2433677467

From jpai at openjdk.org  Wed Nov 13 15:58:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 13 Nov 2024 15:58:24 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v4]
In-Reply-To: <7UIOJe6XcLVOkG3ZYySjhPKDsfLuXBItVesGMxYNwsY=.afe28b9d-d2e7-4956-b7c0-263186ba77c7@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <V3pgE8WoUPQKYv8hRwDM2-ef5euekBsY2yQR6YExy5Y=.6dce51ca-67f1-4ccc-9e99-91c96ed80cfe@github.com>
 <WodpAoIcb2kM-jAV18jyCP7BTtFLqKR_azUpO7cQ6Hc=.510fc507-25b0-411d-86ee-0bd2afd52eab@github.com>
 <IoMhcCkViKjAp009qT1ZGyq4FI-Ch_mJKz9ZwPz5yRE=.1cc9a0a8-d4cf-40e5-ad1d-7588200c4916@github.com>
 <LG-GAZoaZECXPthNc-oQmraMbo_KHTupSyaGlewOi1Y=.9feeca4a-e6cc-4cc7-942a-088ab2224823@github.com>
 <7UIOJe6XcLVOkG3ZYySjhPKDsfLuXBItVesGMxYNwsY=.afe28b9d-d2e7-4956-b7c0-263186ba77c7@github.com>
Message-ID: <t7xZznqBYG6INaA567jXImILf0CmkCRg23deQpV0vXo=.35a3766c-b952-4476-a78a-2a5fd8fb2b43@github.com>

On Wed, 13 Nov 2024 15:48:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I assume Roger will run at least tier1 on all platforms before integrating.
>
> Inadvertent lapse.
> Retested in the CI on all platforms

Thank you Roger, the updated changes look good to me.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22024#discussion_r1840671802

From duke at openjdk.org  Wed Nov 13 16:00:34 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 13 Nov 2024 16:00:34 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <emFPpFaANkv9aaGmICcMXQh4Z9apLU0u1QFe7OAQbKA=.a9333a02-1aff-46db-b1cc-6d266b841956@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
 <emFPpFaANkv9aaGmICcMXQh4Z9apLU0u1QFe7OAQbKA=.a9333a02-1aff-46db-b1cc-6d266b841956@github.com>
Message-ID: <bM-C65a11slu025oKKMADTVbIrAfgkniMSF9NdD8XHQ=.0b8f83f8-d098-4b23-8450-6a0e00e6cc67@github.com>

On Wed, 13 Nov 2024 15:49:55 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>>  - Move `serialPersistentFields` for a degree of method order consistency
>>  - Address review feedback
>>  - Test fixes and finish renaming
>>  - Address review feedback
>>  - Address review comment
>>  - Eliminate cache
>>  - Rework using facilities found in ObjectStreamClass
>>    
>>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>>  - More tests
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 44:
> 
>> 42: import java.lang.reflect.Modifier;
>> 43: import java.lang.reflect.Proxy;
>> 44: import java.security.PrivilegedAction;
> 
> Unneeded import.

This is used down below on line 423:


    private static boolean hasDefaultOrNoSerialization(Class<?> cl) {
        return ! Serializable.class.isAssignableFrom(cl)
            || cl.isInterface()
            || cl.isArray()
            || Proxy.isProxyClass(cl) // <=== right here
            || Externalizable.class.isAssignableFrom(cl)
            || cl.isEnum()
            || cl.isRecord()
            || cl.isHidden()
            || nonSerializableLeafClasses.contains(cl);
    }

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1840681881

From rriggs at openjdk.org  Wed Nov 13 16:05:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 16:05:51 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <bM-C65a11slu025oKKMADTVbIrAfgkniMSF9NdD8XHQ=.0b8f83f8-d098-4b23-8450-6a0e00e6cc67@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
 <emFPpFaANkv9aaGmICcMXQh4Z9apLU0u1QFe7OAQbKA=.a9333a02-1aff-46db-b1cc-6d266b841956@github.com>
 <bM-C65a11slu025oKKMADTVbIrAfgkniMSF9NdD8XHQ=.0b8f83f8-d098-4b23-8450-6a0e00e6cc67@github.com>
Message-ID: <FLDMx7-HqvN3CgpryN4PMFJRPeyQOl_zU2V4h9udDgM=.db70a4af-e09f-4631-8aa2-86bdc22c1a82@github.com>

On Wed, 13 Nov 2024 15:57:28 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 44:
>> 
>>> 42: import java.lang.reflect.Modifier;
>>> 43: import java.lang.reflect.Proxy;
>>> 44: import java.security.PrivilegedAction;
>> 
>> Unneeded import.
>
> This is used down below on line 423:
> 
> 
>     private static boolean hasDefaultOrNoSerialization(Class<?> cl) {
>         return ! Serializable.class.isAssignableFrom(cl)
>             || cl.isInterface()
>             || cl.isArray()
>             || Proxy.isProxyClass(cl) // <=== right here
>             || Externalizable.class.isAssignableFrom(cl)
>             || cl.isEnum()
>             || cl.isRecord()
>             || cl.isHidden()
>             || nonSerializableLeafClasses.contains(cl);
>     }

Sorry, I meant to flag PrivilegedAction.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1840694107

From cstein at openjdk.org  Wed Nov 13 16:08:44 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 13 Nov 2024 16:08:44 GMT
Subject: RFR: 8316804: Gracefully handle the case where --release is not
 specified last [v2]
In-Reply-To: <P_31GGK7WG72JM2gXTV9BBgCcX5x-I8N0LH9vhdytGQ=.a40d1769-f299-4b58-9bee-5ad6008dadd4@github.com>
References: <P_31GGK7WG72JM2gXTV9BBgCcX5x-I8N0LH9vhdytGQ=.a40d1769-f299-4b58-9bee-5ad6008dadd4@github.com>
Message-ID: <0PNXrpbXsBRSHAM_ZR-FDk1gXllcMDIDBVZCw4jH2cM=.9a0e02e3-5e10-4914-a84e-4d4d2509eb27@github.com>

> Please review this change for the `jar` tool to gracefully handle the case where `--release` is not specified as the last arguments.
> 
> Prior to this commit, operation modes `-d --describe-module` and `--validate` expected to read the optional `--release` option as a file argument: `jar -d -f a.jar --release 9`
> By adding a hidden GNU-style `--release` option, processing the optional arguments before in those two operation modes, the position is now no longer required to trail behind the `-f --file` option: `jar -d --release 9 -f a.jar`
> 
> 
> ==============================
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jdk/tools/jar                             26    26     0     0
> ==============================
> TEST SUCCESS

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Stream argument processing and fix typo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22079/files
  - new: https://git.openjdk.org/jdk/pull/22079/files/311c725e..4f56a934

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22079&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22079&range=00-01

  Stats: 11 lines in 2 files changed: 4 ins; 5 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22079.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22079/head:pull/22079

PR: https://git.openjdk.org/jdk/pull/22079

From bpb at openjdk.org  Wed Nov 13 16:12:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 16:12:56 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <ZgQCMQLZl6SCMccn9hN-t2BmywYF7_4j7X0UAlOEMnU=.5a7dc892-66e1-4d5c-b191-f37e506b9266@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <ZgQCMQLZl6SCMccn9hN-t2BmywYF7_4j7X0UAlOEMnU=.5a7dc892-66e1-4d5c-b191-f37e506b9266@github.com>
Message-ID: <vuKrVZ3dJ3bxxrN5BpVCvKMg2f5r_KBmVYbbyP6HQkU=.6452b55d-c283-4561-ac16-a87b1cea6d7a@github.com>

On Wed, 13 Nov 2024 07:13:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think we should remove jdk.internal.misc.InternalLock and the usages in Throwable as part of this change. I don't mind if JavaIOPrintStreamAccess is removed now or in a later PR.

I will address these items first and then the other comments, but will probably refrain from much in the way of simple cleanups, at least before the final iteration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474056635

From rgiulietti at openjdk.org  Wed Nov 13 16:13:29 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 13 Nov 2024 16:13:29 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <ZoVL2aI3sRfDdt1uE0Gd8-GwGmXik6IiapS7Pl-f6Wg=.f3ff26b2-84e0-45ae-bf83-df5a6a910051@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <IS8RKT9AcGJuhjLtW9XSOjBjXZYH8RKc14k8RbjILH8=.44639722-5970-428a-bc37-114f66d2887d@github.com>
 <4-8HmTeqt_jAN7gxmZQ02rCDnpaFY3mkbLq0ZXE_HQA=.57062632-7331-417a-8870-435f648170f7@github.com>
 <5QiIddOeRC1c6Uu6k29kncwwYaHPihYNzbR8o5YUaQU=.0211e950-0a0c-4f36-944b-39afbe03aebd@github.com>
 <ZoVL2aI3sRfDdt1uE0Gd8-GwGmXik6IiapS7Pl-f6Wg=.f3ff26b2-84e0-45ae-bf83-df5a6a910051@github.com>
Message-ID: <1EfcODsNDn1-TLzJco21IKPpOdYLONl00v_T-PHXgvs=.c3696277-0f95-4eb2-9949-b83708ccdf82@github.com>

On Mon, 21 Oct 2024 17:01:43 GMT, fabioromano1 <duke at openjdk.org> wrote:

>>> > Curiously, this one runs in a fraction of a second on the current implementation, but not on the proposed one: `BigDecimal.valueOf(100).sqrt(new MathContext(1_000_000, RoundingMode.HALF_EVEN)).shortValue()`
>>> 
>>> @rgiulietti This is because, in the current implementation, the check for even powers of 10 is always done, while in mine is done only if exact result is required.
>> 
>> Since there's an invocation of `stripTrailingZeros()` anyway, what's the reason to _not_ "optimize" for other round modes as well, like in the current implementation?
>
>> Since there's an invocation of `stripTrailingZeros()` anyway, what's the reason to _not_ "optimize" for other round modes as well, like in the current implementation?
> 
> Because it is not necessary to strip zeros when an exact result is not requested, so while the call to `stripTrailingZeros()` speeds up only for the unlikely case that the input is an even power of 10, it slows down for all other cases...

@fabioromano1 I took a look at the code, and at first sight it looks good.
However, before approving, I'll have a deeper look in the next couple of days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2474053522

From duke at openjdk.org  Wed Nov 13 16:13:29 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 13 Nov 2024 16:13:29 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization
In-Reply-To: <1EfcODsNDn1-TLzJco21IKPpOdYLONl00v_T-PHXgvs=.c3696277-0f95-4eb2-9949-b83708ccdf82@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <IS8RKT9AcGJuhjLtW9XSOjBjXZYH8RKc14k8RbjILH8=.44639722-5970-428a-bc37-114f66d2887d@github.com>
 <4-8HmTeqt_jAN7gxmZQ02rCDnpaFY3mkbLq0ZXE_HQA=.57062632-7331-417a-8870-435f648170f7@github.com>
 <5QiIddOeRC1c6Uu6k29kncwwYaHPihYNzbR8o5YUaQU=.0211e950-0a0c-4f36-944b-39afbe03aebd@github.com>
 <ZoVL2aI3sRfDdt1uE0Gd8-GwGmXik6IiapS7Pl-f6Wg=.f3ff26b2-84e0-45ae-bf83-df5a6a910051@github.com>
 <1EfcODsNDn1-TLzJco21IKPpOdYLONl00v_T-PHXgvs=.c3696277-0f95-4eb2-9949-b83708ccdf82@github.com>
Message-ID: <4whMqYFRLmNKqWpX1LqRSx9awEIuUjIUqTSZuR-Fz0w=.5eb9a46c-8989-43a1-ad1c-894e0011f7fa@github.com>

On Wed, 13 Nov 2024 16:07:42 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>>> Since there's an invocation of `stripTrailingZeros()` anyway, what's the reason to _not_ "optimize" for other round modes as well, like in the current implementation?
>> 
>> Because it is not necessary to strip zeros when an exact result is not requested, so while the call to `stripTrailingZeros()` speeds up only for the unlikely case that the input is an even power of 10, it slows down for all other cases...
>
> @fabioromano1 I took a look at the code, and at first sight it looks good.
> However, before approving, I'll have a deeper look in the next couple of days.

@rgiulietti Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21301#issuecomment-2474064838

From bpb at openjdk.org  Wed Nov 13 16:18:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 16:18:44 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <vuKrVZ3dJ3bxxrN5BpVCvKMg2f5r_KBmVYbbyP6HQkU=.6452b55d-c283-4561-ac16-a87b1cea6d7a@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <ZgQCMQLZl6SCMccn9hN-t2BmywYF7_4j7X0UAlOEMnU=.5a7dc892-66e1-4d5c-b191-f37e506b9266@github.com>
 <vuKrVZ3dJ3bxxrN5BpVCvKMg2f5r_KBmVYbbyP6HQkU=.6452b55d-c283-4561-ac16-a87b1cea6d7a@github.com>
Message-ID: <FO2diqXvcTj_B-BUN931N5XeIU-8-Y22qCXFe9YWjIY=.86274289-149d-48e6-bee8-fb60a7f67c9a@github.com>

On Wed, 13 Nov 2024 16:08:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I think we should remove jdk.internal.misc.InternalLock

`InternalLock` is also in `sun.nio.cs.Stream{De,En}coder`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474077686

From duke at openjdk.org  Wed Nov 13 16:18:47 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 13 Nov 2024 16:18:47 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <FLDMx7-HqvN3CgpryN4PMFJRPeyQOl_zU2V4h9udDgM=.db70a4af-e09f-4631-8aa2-86bdc22c1a82@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
 <emFPpFaANkv9aaGmICcMXQh4Z9apLU0u1QFe7OAQbKA=.a9333a02-1aff-46db-b1cc-6d266b841956@github.com>
 <bM-C65a11slu025oKKMADTVbIrAfgkniMSF9NdD8XHQ=.0b8f83f8-d098-4b23-8450-6a0e00e6cc67@github.com>
 <FLDMx7-HqvN3CgpryN4PMFJRPeyQOl_zU2V4h9udDgM=.db70a4af-e09f-4631-8aa2-86bdc22c1a82@github.com>
Message-ID: <EFyXQNFNP2pbBHRYFOsfOgkChIEpAQ7VXimlD-jYclo=.2b1a83d1-6011-4df5-9e88-03f681dbc69a@github.com>

On Wed, 13 Nov 2024 16:01:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This is used down below on line 423:
>> 
>> 
>>     private static boolean hasDefaultOrNoSerialization(Class<?> cl) {
>>         return ! Serializable.class.isAssignableFrom(cl)
>>             || cl.isInterface()
>>             || cl.isArray()
>>             || Proxy.isProxyClass(cl) // <=== right here
>>             || Externalizable.class.isAssignableFrom(cl)
>>             || cl.isEnum()
>>             || cl.isRecord()
>>             || cl.isHidden()
>>             || nonSerializableLeafClasses.contains(cl);
>>     }
>
> Sorry, I meant to flag PrivilegedAction.

Ah, I see. It looks like it's still used though, in `GetReflectionFactoryAction` which hasn't been removed yet. I guess it'll be removed in one of the sub-tasks of [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411)? It wasn't added in this PR in any event.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1840724748

From yzheng at openjdk.org  Wed Nov 13 16:28:36 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 13 Nov 2024 16:28:36 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
 <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
Message-ID: <bWryJ5zC3Uw2IyOEYs5RiVQkr3_D_LkSUjwJK-ce6qQ=.adf08930-ed39-4ccd-83d3-fe3bc5206324@github.com>

On Tue, 12 Nov 2024 18:47:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Removes the SecurityManager usage from Thread + friends.
>> 
>> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
>> 
>> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8343981
>  - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
>  - Initial commit
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...636ebd19

Please hold until I have the Graal changes ready

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22035#issuecomment-2474106454

From acobbs at openjdk.org  Wed Nov 13 16:32:26 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Nov 2024 16:32:26 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v5]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <iqCXfJ4MwX4AbwXNhpEN6_aMMcaSdeEDB4Ag3xR8LNY=.1343bace-e197-4625-a5c5-bb5e2c7f1ce4@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 10 commits:

 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update copyright years.
 - Remove a few more @SuppressWarnings annotations.
 - Remove a few more @SuppressWarnings annotations.
 - Update copyright years.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove unnecessary @SuppressWarnings annotations.

-------------

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=04
  Stats: 187 lines in 94 files changed: 0 ins; 95 del; 92 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

PR: https://git.openjdk.org/jdk/pull/21852

From pminborg at openjdk.org  Wed Nov 13 16:40:14 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 16:40:14 GMT
Subject: RFR: 8344086: Remove security manager dependency in FFM
In-Reply-To: <Kvm1dsaB6dwEf2IZYSlBPy_NdNEIeYFLFDaGrbYP4aQ=.7191802a-c79d-408f-a032-1efdcb8a672c@github.com>
References: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
 <Kvm1dsaB6dwEf2IZYSlBPy_NdNEIeYFLFDaGrbYP4aQ=.7191802a-c79d-408f-a032-1efdcb8a672c@github.com>
Message-ID: <eZL2VHp2FsuPqK07JxkPllb_aK4XUf5LI3wMHQy_vP0=.98d6950a-84ee-42ad-8fe6-6fd2cca4c210@github.com>

On Wed, 13 Nov 2024 15:24:26 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> This PR proposes to remove the security manager dependencies in the FFM implementing classes.
>
> src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 128:
> 
>> 126:      */
>> 127:     private static Path jdkLibraryPath(String name) {
>> 128:         Path javahome = Path.of(System.getProperty("java.home"));
> 
> If not out of scope for this PR:
> System property java.home is available in a static; will need an `import jdk.internal.util.StaticProperty`
> Suggestion:
> 
>         Path javahome = StaticProperty.javaHome();

Let's do that change under a separate PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22071#discussion_r1840778192

From yzheng at openjdk.org  Wed Nov 13 16:42:54 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 13 Nov 2024 16:42:54 GMT
Subject: RFR: 8343981: Remove usage of security manager from Thread and
 related classes [v4]
In-Reply-To: <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
 <8-WGEK-jn2edcngzAuAyNJaePjOxwNJFkSGELd9bJSc=.21c86aca-d077-4d07-be47-25d74128208b@github.com>
Message-ID: <VAtXMlVDC7v_hRv0SEhH4xsGjvN5CeZwaaxXwumzT5E=.afa6e631-17aa-4fb9-9f8b-4618e7943387@github.com>

On Tue, 12 Nov 2024 18:47:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Removes the SecurityManager usage from Thread + friends.
>> 
>> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
>> 
>> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 227 commits:
> 
>  - Merge branch 'master' into JDK-8343981
>  - Merge commit 'db85090553ab14a84c3ed0a2604dd56c5b6e6982' into JDK-8343981
>  - Initial commit
>  - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
>  - Merge branch 'master' into jep486
>  - Move remaining JEP 486 failing tests into correct groups.
>  - Move JEP 486 failing tests into hotspot_runtime group.
>  - test/jdk/java/rmi/server/RMIClassLoader/spi/DefaultProperty.java failing
>  - Merge branch 'master' into jep486
>  - Merge branch 'master' into jep486
>  - ... and 217 more: https://git.openjdk.org/jdk/compare/63eb4853...636ebd19

Marked as reviewed by yzheng (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22035#pullrequestreview-2433814049

From pminborg at openjdk.org  Wed Nov 13 16:44:17 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 16:44:17 GMT
Subject: RFR: 8344086: Remove security manager dependency in FFM
In-Reply-To: <eZL2VHp2FsuPqK07JxkPllb_aK4XUf5LI3wMHQy_vP0=.98d6950a-84ee-42ad-8fe6-6fd2cca4c210@github.com>
References: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
 <Kvm1dsaB6dwEf2IZYSlBPy_NdNEIeYFLFDaGrbYP4aQ=.7191802a-c79d-408f-a032-1efdcb8a672c@github.com>
 <eZL2VHp2FsuPqK07JxkPllb_aK4XUf5LI3wMHQy_vP0=.98d6950a-84ee-42ad-8fe6-6fd2cca4c210@github.com>
Message-ID: <6OTPZSmXzUt8TFy6QTbfQ2Fkw8B2ZObgqc2uLsS2DVA=.c7291fba-b067-46a2-b147-219c8e979e83@github.com>

On Wed, 13 Nov 2024 16:37:19 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/foreign/SystemLookup.java line 128:
>> 
>>> 126:      */
>>> 127:     private static Path jdkLibraryPath(String name) {
>>> 128:         Path javahome = Path.of(System.getProperty("java.home"));
>> 
>> If not out of scope for this PR:
>> System property java.home is available in a static; will need an `import jdk.internal.util.StaticProperty`
>> Suggestion:
>> 
>>         Path javahome = StaticProperty.javaHome();
>
> Let's do that change under a separate PR.

https://bugs.openjdk.org/browse/JDK-8344134

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22071#discussion_r1840786281

From pminborg at openjdk.org  Wed Nov 13 16:45:59 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 13 Nov 2024 16:45:59 GMT
Subject: Integrated: 8344086: Remove security manager dependency in FFM
In-Reply-To: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
References: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
Message-ID: <2Ij5oJn2mmrKmaO740emY0YDd-POW0cAJf-min0RQeM=.99cdc500-0a92-4440-9ec8-3b3bb98e44d3@github.com>

On Wed, 13 Nov 2024 13:48:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the security manager dependencies in the FFM implementing classes.

This pull request has now been integrated.

Changeset: bd3fec30
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bd3fec3075829efc0afe7a99d7a684cf81cc5bbb
Stats:     72 lines in 11 files changed: 5 ins; 33 del; 34 mod

8344086: Remove security manager dependency in FFM

Reviewed-by: mcimadamore, rriggs, jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/22071

From vklang at openjdk.org  Wed Nov 13 16:46:28 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 13 Nov 2024 16:46:28 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream [v3]
In-Reply-To: <nbHSVJw56lW8cmWDlxms_zs1f8YRGU3XICBXBSY55js=.42c0cce9-f5c6-4e95-a107-82209c4dc6ce@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <nbHSVJw56lW8cmWDlxms_zs1f8YRGU3XICBXBSY55js=.42c0cce9-f5c6-4e95-a107-82209c4dc6ce@github.com>
Message-ID: <ELJm9gJb_lEEJNKi3m3wCjcOXX-qtsdBu66Otvw_Y9g=.4542bef7-525f-498b-9574-ee89314238f6@github.com>

On Tue, 12 Nov 2024 16:12:36 GMT, kabutz <duke at openjdk.org> wrote:

>> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
>> 
>> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.
>
> kabutz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed NPE when set is empty and added TCK test

Nice catch, @kabutz !

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21820#pullrequestreview-2433824217

From alanb at openjdk.org  Wed Nov 13 16:58:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 16:58:21 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <FO2diqXvcTj_B-BUN931N5XeIU-8-Y22qCXFe9YWjIY=.86274289-149d-48e6-bee8-fb60a7f67c9a@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <ZgQCMQLZl6SCMccn9hN-t2BmywYF7_4j7X0UAlOEMnU=.5a7dc892-66e1-4d5c-b191-f37e506b9266@github.com>
 <vuKrVZ3dJ3bxxrN5BpVCvKMg2f5r_KBmVYbbyP6HQkU=.6452b55d-c283-4561-ac16-a87b1cea6d7a@github.com>
 <FO2diqXvcTj_B-BUN931N5XeIU-8-Y22qCXFe9YWjIY=.86274289-149d-48e6-bee8-fb60a7f67c9a@github.com>
Message-ID: <4iZzCSE49Aw6EAZTMxaK10gSI27dEqPBZw7dgv6xC00=.8a2a24db-9454-49ea-8d07-b01b97ace229@github.com>

On Wed, 13 Nov 2024 16:14:11 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> `InternalLock` is also in `sun.nio.cs.Stream{De,En}coder`.

Yes, these two will need to be updated. I don't mind if this is split up into several PRs but if InternalLock isn't removed by the current PR then you'll need to change its title :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474195205

From duke at openjdk.org  Wed Nov 13 17:00:30 2024
From: duke at openjdk.org (duke)
Date: Wed, 13 Nov 2024 17:00:30 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream [v3]
In-Reply-To: <nbHSVJw56lW8cmWDlxms_zs1f8YRGU3XICBXBSY55js=.42c0cce9-f5c6-4e95-a107-82209c4dc6ce@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <nbHSVJw56lW8cmWDlxms_zs1f8YRGU3XICBXBSY55js=.42c0cce9-f5c6-4e95-a107-82209c4dc6ce@github.com>
Message-ID: <MiWcC9i70G98c-JV0h_uHz2NJmeglBw4DeUlN5Dty5E=.c105de7c-595f-4770-b99e-2de6e07c2248@github.com>

On Tue, 12 Nov 2024 16:12:36 GMT, kabutz <duke at openjdk.org> wrote:

>> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
>> 
>> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.
>
> kabutz has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Removed NPE when set is empty and added TCK test

@kabutz 
Your change (at version d167b88fcc213b02080d25d9cf4761d41f4bfc1b) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2474200282

From duke at openjdk.org  Wed Nov 13 17:00:58 2024
From: duke at openjdk.org (Naman Nigam)
Date: Wed, 13 Nov 2024 17:00:58 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's getFloorEntry
 and getCeilingEntry
Message-ID: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>

As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:

if no such entry exists, returns the entry for the least key greater than the specified key;
if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.

-------------

Commit messages:
 - JDK-8343125 : Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry
 - Correction: Documentation update for ceil and floor

Changes: https://git.openjdk.org/jdk/pull/21729/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21729&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343125
  Stats: 10 lines in 1 file changed: 2 ins; 2 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21729/head:pull/21729

PR: https://git.openjdk.org/jdk/pull/21729

From liach at openjdk.org  Wed Nov 13 17:00:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 17:00:58 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry
In-Reply-To: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
Message-ID: <dolTFlm-5GyQV66gwSjwxJX4_J_O6ofMliOwHX6LimA=.67ea06df-8eee-4478-b5e3-1b4a476e734c@github.com>

On Sat, 26 Oct 2024 14:06:37 GMT, Naman Nigam <duke at openjdk.org> wrote:

> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
> 
> if no such entry exists, returns the entry for the least key greater than the specified key;
> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.

To get a JBS issue, please open a bug report about this typo in https://bugs.java.com/bugdatabase/. Also follow https://openjdk.org/guide for the rest of the steps for contributions.

src/java.base/share/classes/java/util/TreeMap.java line 424:

> 422:     /**
> 423:      * Gets the entry corresponding to the specified key; returns the entry for
> 424:      * the least key greater than the specified key; if no such entry exists

What about: (same for the floor one)

Returns the entry for the least key greater than or equal to the specified key;
if no such entry exists (i.e. the specified key is greater than any key in the tree),
returns {@code null}.

What do you think of my version?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2439810022
PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1819302174

From liach at openjdk.org  Wed Nov 13 17:01:14 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 17:01:14 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v4]
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <uwJW7YAr6iId-G8bHfFzFunDHG72PYawAvY4NiDkpNE=.a1968afe-f881-48e0-b2ce-6cedaa8f30bf@github.com>

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Wording as discussed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21912/files
  - new: https://git.openjdk.org/jdk/pull/21912/files/c5e15955..2306ceba

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21912&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21912&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21912.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21912/head:pull/21912

PR: https://git.openjdk.org/jdk/pull/21912

From duke at openjdk.org  Wed Nov 13 17:00:59 2024
From: duke at openjdk.org (Naman Nigam)
Date: Wed, 13 Nov 2024 17:00:59 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry
In-Reply-To: <dolTFlm-5GyQV66gwSjwxJX4_J_O6ofMliOwHX6LimA=.67ea06df-8eee-4478-b5e3-1b4a476e734c@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <dolTFlm-5GyQV66gwSjwxJX4_J_O6ofMliOwHX6LimA=.67ea06df-8eee-4478-b5e3-1b4a476e734c@github.com>
Message-ID: <UsWuxzhC_BjzIcX5ooaEN1SOfg9RjWgc_VwTFsSMbtA=.45d9e5a3-d1ea-483e-8d95-89e778755fef@github.com>

On Sun, 27 Oct 2024 02:30:33 GMT, Chen Liang <liach at openjdk.org> wrote:

> To get a JBS issue, please open a bug report about this typo in https://bugs.java.com/bugdatabase/. Also follow https://openjdk.org/guide for the rest of the steps for contributions.

Thank you for your response @liach, I have
- [x] filed the bug and referenced its ID
- [x] signed the [OCA](https://oca.opensource.oracle.com/) and waiting for its approval

Please help me understand whom to add as a reviewer (and how) for such changes.

> src/java.base/share/classes/java/util/TreeMap.java line 424:
> 
>> 422:     /**
>> 423:      * Gets the entry corresponding to the specified key; returns the entry for
>> 424:      * the least key greater than the specified key; if no such entry exists
> 
> What about: (same for the floor one)
> 
> Returns the entry for the least key greater than or equal to the specified key;
> if no such entry exists (i.e. the specified key is greater than any key in the tree),
> returns {@code null}.
> 
> What do you think of my version?

Looks good to me and is similar to other methods of the form `get*` such as `getHigherEntry`. I could make that change and ensure documentation is similar for methods.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2440628625
PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1821302920

From liach at openjdk.org  Wed Nov 13 17:00:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 17:00:59 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry
In-Reply-To: <UsWuxzhC_BjzIcX5ooaEN1SOfg9RjWgc_VwTFsSMbtA=.45d9e5a3-d1ea-483e-8d95-89e778755fef@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <dolTFlm-5GyQV66gwSjwxJX4_J_O6ofMliOwHX6LimA=.67ea06df-8eee-4478-b5e3-1b4a476e734c@github.com>
 <UsWuxzhC_BjzIcX5ooaEN1SOfg9RjWgc_VwTFsSMbtA=.45d9e5a3-d1ea-483e-8d95-89e778755fef@github.com>
Message-ID: <Ughwrgl1mCQCrCDGe0FwrY0C0xCEua9fxZEimoFpid0=.62fb6023-c026-4e6e-8234-4b3ae926e28b@github.com>

On Mon, 28 Oct 2024 06:05:50 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> To get a JBS issue, please open a bug report about this typo in https://bugs.java.com/bugdatabase/. Also follow https://openjdk.org/guide for the rest of the steps for contributions.
>
>> To get a JBS issue, please open a bug report about this typo in https://bugs.java.com/bugdatabase/. Also follow https://openjdk.org/guide for the rest of the steps for contributions.
> 
> Thank you for your response @liach, I have
> - [x] filed the bug and referenced its ID
> - [x] signed the [OCA](https://oca.opensource.oracle.com/) and waiting for its approval
> 
> Please help me understand whom to add as a reviewer (and how) for such changes.

@namannigam Please take note of https://github.com/openjdk/jdk/pull/21729#issuecomment-2439595154

> Once you have signed the OCA, please let us know by writing `/signed` in a comment in this pull request.

You have filled in the issue ID correctly; but you need to make sure the PR title has the same text as the issue title. So the correct PR title will be

8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry


For reviewers, this is the "JDK" project in the OpenJDK census: https://openjdk.org/census#jdk

People don't usually review until a patch (PR) is "rfr" (ready for review), which means that the oca has to be cleared first.

>> src/java.base/share/classes/java/util/TreeMap.java line 424:
>> 
>>> 422:     /**
>>> 423:      * Gets the entry corresponding to the specified key; returns the entry for
>>> 424:      * the least key greater than the specified key; if no such entry exists
>> 
>> What about: (same for the floor one)
>> 
>> Returns the entry for the least key greater than or equal to the specified key;
>> if no such entry exists (i.e. the specified key is greater than any key in the tree),
>> returns {@code null}.
>> 
>> What do you think of my version?
>
> Looks good to me and is similar to other methods of the form `get*` such as `getHigherEntry`. I could make that change and ensure documentation is similar for methods.

Indeed, ceil works like higher; given a key `k`, ceil allows exact `k` while higher does not, and they are otherwise the same. Same for floor/lower.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2441925256
PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1821347656

From rriggs at openjdk.org  Wed Nov 13 17:02:58 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 17:02:58 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
Message-ID: <pJ6vlElpa1_sGeL_hTuKIUhPUAqHDdUwlUq88snZah8=.42054e7f-fc8e-4d3f-bfaf-c44ab9422ee3@github.com>

On Wed, 13 Nov 2024 13:17:31 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - Eliminate cache
>  - Rework using facilities found in ObjectStreamClass
>    
>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>  - More tests
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19702#pullrequestreview-2433878329

From rriggs at openjdk.org  Wed Nov 13 17:03:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 17:03:00 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <EFyXQNFNP2pbBHRYFOsfOgkChIEpAQ7VXimlD-jYclo=.2b1a83d1-6011-4df5-9e88-03f681dbc69a@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
 <emFPpFaANkv9aaGmICcMXQh4Z9apLU0u1QFe7OAQbKA=.a9333a02-1aff-46db-b1cc-6d266b841956@github.com>
 <bM-C65a11slu025oKKMADTVbIrAfgkniMSF9NdD8XHQ=.0b8f83f8-d098-4b23-8450-6a0e00e6cc67@github.com>
 <FLDMx7-HqvN3CgpryN4PMFJRPeyQOl_zU2V4h9udDgM=.db70a4af-e09f-4631-8aa2-86bdc22c1a82@github.com>
 <EFyXQNFNP2pbBHRYFOsfOgkChIEpAQ7VXimlD-jYclo=.2b1a83d1-6011-4df5-9e88-03f681dbc69a@github.com>
Message-ID: <jSaVGxnk10LAxjIdDlWM54R7su3VyJuQ8u9h0D9z26c=.6ce4629c-2645-4c36-8dae-afdd993c7d7c@github.com>

On Wed, 13 Nov 2024 16:13:58 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Sorry, I meant to flag PrivilegedAction.
>
> Ah, I see. It looks like it's still used though, in `GetReflectionFactoryAction` which hasn't been removed yet. I guess it'll be removed in one of the sub-tasks of [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411)? It wasn't added in this PR in any event.

ok, as is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1840829847

From bpb at openjdk.org  Wed Nov 13 17:28:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 17:28:53 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <4iZzCSE49Aw6EAZTMxaK10gSI27dEqPBZw7dgv6xC00=.8a2a24db-9454-49ea-8d07-b01b97ace229@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <ZgQCMQLZl6SCMccn9hN-t2BmywYF7_4j7X0UAlOEMnU=.5a7dc892-66e1-4d5c-b191-f37e506b9266@github.com>
 <vuKrVZ3dJ3bxxrN5BpVCvKMg2f5r_KBmVYbbyP6HQkU=.6452b55d-c283-4561-ac16-a87b1cea6d7a@github.com>
 <FO2diqXvcTj_B-BUN931N5XeIU-8-Y22qCXFe9YWjIY=.86274289-149d-48e6-bee8-fb60a7f67c9a@github.com>
 <4iZzCSE49Aw6EAZTMxaK10gSI27dEqPBZw7dgv6xC00=.8a2a24db-9454-49ea-8d07-b01b97ace229@github.com>
Message-ID: <nObKCD4Rt7eESpJIcpnRVAMP-cmabWPd_RhdjiM4vy0=.4b81e00e-7f9b-466d-9b44-dcd657058bf3@github.com>

On Wed, 13 Nov 2024 16:55:16 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > `InternalLock` is also in `sun.nio.cs.Stream{De,En}coder`.
> 
> Yes, these two will need to be updated. I don't mind if this is split up into several PRs but if InternalLock isn't removed by the current PR then you'll need to change its title :-)

I'll go ahead and update these and remove InternalLock.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474276336

From kdnilsen at openjdk.org  Wed Nov 13 17:29:22 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Wed, 13 Nov 2024 17:29:22 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
Message-ID: <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>

On Wed, 13 Nov 2024 15:38:35 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - Touchups: assert index, polish commits
>  - Fix

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 290:

> 288:                 list.remove(lastIdx);
> 289: 
> 290:                 // Capacity control: trim the backing storage if it looks like

I think we need to set maxIdx to lastIdx - 1 here.  Otherwise, we'll never trim back the storage.  maxIdx can only increase in insert() as currently implemented.

src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java line 71:

> 69:         this.index = -1;
> 70:         this.list = CleanerImpl.getCleanerImpl(cleaner).activeList;
> 71:         list.insert(this);

For consistency, maybe use "this.list.insert(this)", or remove "this" from the preceding two lines.

test/micro/org/openjdk/bench/java/lang/ref/CleanerChurn.java line 56:

> 54:             }
> 55:         }
> 56:     }

Can we test whether lists get shrunk after lots of removes?  Maybe not practical without leaking implementation details through the API.  It looks to me that current implementation will not shrink.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1840866070
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1840870321
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1840879995

From jvernee at openjdk.org  Wed Nov 13 17:32:48 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Nov 2024 17:32:48 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v14]
In-Reply-To: <cxSiGV-TWjxSKHsHX3dxCqMk0cXtIE9DfXCipDjFCtU=.3424bd59-fbce-4bfd-898e-43d99d5dcf2c@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <cxSiGV-TWjxSKHsHX3dxCqMk0cXtIE9DfXCipDjFCtU=.3424bd59-fbce-4bfd-898e-43d99d5dcf2c@github.com>
Message-ID: <TykF5UMUr3P4OaUDDKkLUCfcbIXc2cRyzvRYroEBiZc=.bd0b2cf6-5657-4b66-a836-d49922e1adc3@github.com>

On Wed, 13 Nov 2024 10:24:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 32 additional commits since the last revision:
> 
>  - Update after comments
>  - Merge branch 'master' into linker-padding-layout-only
>  - Simplify exception testing
>  - Merge branch 'master' into linker-padding-layout-only
>  - Remove redundant check
>  - Rephrase doc
>  - Improve language
>  - Add checks of exception messages
>  - Update test/jdk/java/foreign/TestLinker.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - Update src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java
>    
>    Co-authored-by: Jorn Vernee <JornVernee at users.noreply.github.com>
>  - ... and 22 more: https://git.openjdk.org/jdk/compare/d58b6a2d...786b1737

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 202:

> 200:                     lastUnpaddedOffset = offset;
> 201:                     if (preceedingPadding != null) {
> 202:                         assertIsAlignedBy(sl, preceedingPadding, member);

Alignment of members is already checked by `checkMemberOffset`, so `assertIsAlignedBy` should not be needed AFAICT. The only thing we should have to do in this branch is set `preceedingPadding` to `null`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1840649385

From rriggs at openjdk.org  Wed Nov 13 17:39:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 17:39:59 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs
In-Reply-To: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
Message-ID: <OBLTUf550G2FzRxV5Ta5JJKRukylk1yKUApNezVLbJw=.4661481f-26e2-444b-9f93-4f0b0f59236d@github.com>

On Wed, 13 Nov 2024 10:32:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
> 
> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
> 
> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
> 
> runtime/cds/appcds/StaticArchiveWithLambda.java is temporarily excluded as the loading of a dynamically generated class at archive time. I'm checking with Calvin and Ioi on whether this test should be updated or replaced.
> 
> Testing: tier1-5

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22063#pullrequestreview-2433993768

From mullan at openjdk.org  Wed Nov 13 17:41:04 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Nov 2024 17:41:04 GMT
Subject: RFR: 8344086: Remove security manager dependency in FFM
In-Reply-To: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
References: <96MadbUCXIMhLzo56mSuEkEwa2Wo9DfvzF_rGu36ans=.f22c33eb-37fa-40c8-81b5-c2a69c4cb4f5@github.com>
Message-ID: <56eL0zMqJAc-2BlcFfTJscY2L-D7o7DNtlES4xg2D90=.ccd03462-8780-4753-a077-805abc91a869@github.com>

On Wed, 13 Nov 2024 13:48:14 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to remove the security manager dependencies in the FFM implementing classes.

I didn't get a chance to review until now, had one small comment.

src/java.base/share/classes/jdk/internal/foreign/abi/fallback/LibFallback.java line 39:

> 37:     static final boolean SUPPORTED = tryLoadLibrary();
> 38: 
> 39:     @SuppressWarnings({"restricted"})

Nit: you no longer need the braces around "restricted".

-------------

PR Review: https://git.openjdk.org/jdk/pull/22071#pullrequestreview-2433981549
PR Review Comment: https://git.openjdk.org/jdk/pull/22071#discussion_r1840891458

From liach at openjdk.org  Wed Nov 13 17:42:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 17:42:38 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry
In-Reply-To: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
Message-ID: <nRbvoKUpTYp0mp9wOQxd9q2YNl7pKPpNX1gGJlH3naw=.78033920-79df-4f6d-8182-d572be7bc2a9@github.com>

On Sat, 26 Oct 2024 14:06:37 GMT, Naman Nigam <duke at openjdk.org> wrote:

> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
> 
> if no such entry exists, returns the entry for the least key greater than the specified key;
> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.

Changes requested by liach (Reviewer).

src/java.base/share/classes/java/util/TreeMap.java line 514:

> 512:                 }
> 513:             } else {
> 514:                 return p;

Is this from a bad merge?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21729#pullrequestreview-2434000248
PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1840903705

From jvernee at openjdk.org  Wed Nov 13 17:50:19 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Nov 2024 17:50:19 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v16]
In-Reply-To: <GSUee2bqFC9HCLW4SMRt3tFkoPnjrLK0eV4xlQ-V6lI=.89739729-ef55-4f09-a46b-abf7432c2d2c@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <GSUee2bqFC9HCLW4SMRt3tFkoPnjrLK0eV4xlQ-V6lI=.89739729-ef55-4f09-a46b-abf7432c2d2c@github.com>
Message-ID: <KEhW-Qc1w8_zVN1fsDhrdVfZ5voIc9D6ZwSYAc_ykkY=.471b4e8e-2c26-4d7b-b732-2c9022411096@github.com>

On Wed, 13 Nov 2024 15:21:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failing test

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 267:

> 265:         return gl != null
> 266:                 ? " in " + gl
> 267:                 : "";

Looks like this can be simpler now as well, since `gl` can never be `null` I think.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1840916603

From liach at openjdk.org  Wed Nov 13 17:51:28 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 17:51:28 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
Message-ID: <8V5Q5vAmzi7CBHCZnksZO6KrzqzAnbS2SL9sgZjSKy8=.62141c0f-fde3-4857-9b08-6e721c05e6fa@github.com>

On Wed, 13 Nov 2024 13:17:31 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - Eliminate cache
>  - Rework using facilities found in ObjectStreamClass
>    
>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>  - More tests
>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 80:

> 78:     private ReflectionFactory() {
> 79:         this.langReflectAccess = SharedSecrets.getJavaLangReflectAccess();
> 80:         this.javaObjectStreamReflectionAccess = SharedSecrets.getJavaObjectStreamReflectionAccess();

ReflectionFactory is created on very early bootstrap, even before `JavaLangAccess` is ready.  This extra dependency is only used when the unsupported version is used, and this dependency, calling MethodHandle, should have changed the boot class loading/initialization sequence by making MH initialization early.  Can you check with a hello world app and run it with `-Xlog:class+init` to check the initialization sequence?

I strongly recommend not caching this access object, and just call `getJavaObjectStreamReflectionAccess()` on demand.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1840918169

From liach at openjdk.org  Wed Nov 13 18:00:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 18:00:16 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs
In-Reply-To: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
Message-ID: <roxo_it0tMxRHc-SMuCD2rbQ1aYJGj5glV0OZeoQLRY=.adb7f84f-ed61-4667-b5f9-81b9d9cc80df@github.com>

On Wed, 13 Nov 2024 10:32:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
> 
> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
> 
> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
> 
> runtime/cds/appcds/StaticArchiveWithLambda.java is temporarily excluded as the loading of a dynamically generated class at archive time. I'm checking with Calvin and Ioi on whether this test should be updated or replaced.
> 
> Testing: tier1-5

Reflection and invoke changes look good.  Not sure about ServiceLoader.  Module/Package changes look innocuous but not a professional in those areas either.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22063#pullrequestreview-2434049807

From jvernee at openjdk.org  Wed Nov 13 18:00:42 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Nov 2024 18:00:42 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v4]
In-Reply-To: <uwJW7YAr6iId-G8bHfFzFunDHG72PYawAvY4NiDkpNE=.a1968afe-f881-48e0-b2ce-6cedaa8f30bf@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <uwJW7YAr6iId-G8bHfFzFunDHG72PYawAvY4NiDkpNE=.a1968afe-f881-48e0-b2ce-6cedaa8f30bf@github.com>
Message-ID: <Ll8bfHeIdNmjPrpDUZQppbFzqSrHqfRE0oOw8YkvDYc=.0141aa25-d0d1-4879-a25f-726a6226ab96@github.com>

On Wed, 13 Nov 2024 17:01:14 GMT, Chen Liang <liach at openjdk.org> wrote:

>> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
>> 
>> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
>> 
>> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wording as discussed

src/java.base/share/classes/java/lang/invoke/LambdaMetafactory.java line 243:

> 241:  * caller.  This technique reduces heap memory use, but it prevents the
> 242:  * implementation class from unloading when the caller is a {@linkplain
> 243:  * MethodHandles.Lookup.ClassOption#STRONG hidden class} and is unloaded.

Sorry but, the text still doesn't seem right to me. The caller class is unloaded when its class loader is unloaded, which would also be when the implementation class is unloaded (it's tied to the caller's class loader because of STRONG). Whether the caller is a hidden class (STRONG or not), should not matter... The point is that the _implementation class_  is a STRONG hidden class, so its lifetime gets tied to the caller's class loader.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21912#discussion_r1840933036

From henryjen at openjdk.org  Wed Nov 13 18:04:33 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Wed, 13 Nov 2024 18:04:33 GMT
Subject: RFR: 8316804: Gracefully handle the case where --release is not
 specified last [v2]
In-Reply-To: <0PNXrpbXsBRSHAM_ZR-FDk1gXllcMDIDBVZCw4jH2cM=.9a0e02e3-5e10-4914-a84e-4d4d2509eb27@github.com>
References: <P_31GGK7WG72JM2gXTV9BBgCcX5x-I8N0LH9vhdytGQ=.a40d1769-f299-4b58-9bee-5ad6008dadd4@github.com>
 <0PNXrpbXsBRSHAM_ZR-FDk1gXllcMDIDBVZCw4jH2cM=.9a0e02e3-5e10-4914-a84e-4d4d2509eb27@github.com>
Message-ID: <1_jZwi2Ukr0r1ka7v1kfTJxRfgCxVdyjNcC_m4MWMWk=.65dee372-d6dd-485a-8743-bd8c02c72526@github.com>

On Wed, 13 Nov 2024 16:08:44 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this change for the `jar` tool to gracefully handle the case where `--release` is not specified as the last arguments.
>> 
>> Prior to this commit, operation modes `-d --describe-module` and `--validate` expected to read the optional `--release` option as a file argument: `jar -d -f a.jar --release 9`
>> By adding a hidden GNU-style `--release` option, processing the optional arguments before in those two operation modes, the position is now no longer required to trail behind the `-f --file` option: `jar -d --release 9 -f a.jar`
>> 
>> 
>> ==============================
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jdk/tools/jar                             26    26     0     0
>> ==============================
>> TEST SUCCESS
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Stream argument processing and fix typo

Looks good to me. 
Relax the ordering for -d and --validate mode is reasonable even though the usage output implies the --release option should be at the end.

-------------

Marked as reviewed by henryjen (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22079#pullrequestreview-2434056644

From acobbs at openjdk.org  Wed Nov 13 18:06:50 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Wed, 13 Nov 2024 18:06:50 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v6]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <NOQPsQeegsOHLymZgFafYENdx8ZCVcECa6a_mSHvGRY=.746f8151-34fa-48e7-91d9-b614f9bd2d65@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request incrementally with one additional commit since the last revision:

  Remove more unnecessary warning suppressions.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21852/files
  - new: https://git.openjdk.org/jdk/pull/21852/files/300c0f98..378ca601

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=04-05

  Stats: 2 lines in 2 files changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

PR: https://git.openjdk.org/jdk/pull/21852

From ihse at openjdk.org  Wed Nov 13 18:11:11 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 13 Nov 2024 18:11:11 GMT
Subject: RFR: 8344056: Use markdown format for man pages
Message-ID: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>

Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.

Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.

This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

-------------

Commit messages:
 - Replace tabs with spaces
 - Remove logic for copying .1 man pages
 - Insert GPL header
 - Add missing Windows man pages for kerberos and accessibility
 - Replace generated troff man pages with markdown version

Changes: https://git.openjdk.org/jdk/pull/22081/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344056
  Stats: 41443 lines in 65 files changed: 18943 ins; 22500 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081

PR: https://git.openjdk.org/jdk/pull/22081

From jjg at openjdk.org  Wed Nov 13 18:11:11 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 13 Nov 2024 18:11:11 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <poXB1Eqc6-PMAJbrqpAf9c5t3wzhkFIRJz_r356snx0=.ff1deb7a-1842-4909-87cf-a6e205ab3187@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Without looking in detail at the changes, this is indeed a welcome and long-overdue change!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474339519

From naoto at openjdk.org  Wed Nov 13 18:20:32 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 13 Nov 2024 18:20:32 GMT
Subject: RFR: 8344039: Remove security manager dependency in java.time [v3]
In-Reply-To: <hp7BJFRImE16eDqCGvuvhS9_A6i_V4tbh8gs97uo1aA=.2018e299-f914-43b4-b8c6-481e90f76e38@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
 <hp7BJFRImE16eDqCGvuvhS9_A6i_V4tbh8gs97uo1aA=.2018e299-f914-43b4-b8c6-481e90f76e38@github.com>
Message-ID: <S1pdKdrCIG9_GD2l8Ol8X0kBwz0FcQbkYOtTnHwYyl8=.5c7e1e61-7654-4da2-9b77-4ed5ba8d2c9b@github.com>

On Wed, 13 Nov 2024 14:51:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), java.time implementation dependencies on doPriviledged and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Retain check for SecurityException until ServiceLoader cleanup is complete.

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22042#pullrequestreview-2434088653

From darcy at openjdk.org  Wed Nov 13 18:24:17 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 13 Nov 2024 18:24:17 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v16]
In-Reply-To: <eaMPSs8wcByzWRB5SpkJfTwC-LVDDxpM3nOfjxa-790=.ec358b67-0363-4f86-af06-1e95e70954a3@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <lGzuOoQml6iOyw18fvZdxINUtFdXNfDaHpq-CQSAsq8=.5a0007d3-11a2-46ba-8d85-49e11b02e3f8@github.com>
 <IUtwBMxhLcRaPgJFfGdWwRsbbsJnfs1S8OG1c4zVolY=.21933fe0-3bea-4a5b-ae43-946be4ba19b7@github.com>
 <eaMPSs8wcByzWRB5SpkJfTwC-LVDDxpM3nOfjxa-790=.ec358b67-0363-4f86-af06-1e95e70954a3@github.com>
Message-ID: <Mu1SO_b_P4ikDlBcd4FoJ7xPFw59692kvEFzZiu9QrI=.bfc14631-2432-4e08-8c2f-1a36cb364ea5@github.com>

On Wed, 13 Nov 2024 11:15:15 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 150:
>> 
>>> 148:      * A constant holding the largest positive finite value of type
>>> 149:      * {@code Float16},
>>> 150:      * (2-2<sup>-10</sup>)&middot;2<sup>15</sup>, numerically equal to 65504.0.
>> 
>> I'm curious why `MAX_VALUE` includes the "numerically equal to", while `MIN_NORMAL` and `MIN_VALUE` do not?
>> 
>> I see java.lang.Float does not use "numerically equal" in the corresponding constants.  Float instead says "It is equal to the hexadecimal floating-point literal.."
>
> Not sure if this is the reason, but in decimal notation `MIN_NORMAL` and `MIN_VALUE` are relatively unreadable: `0.00006103515625` and `5.9604644775390625E-8`, resp.

Yes, that was the reason; the other constants written out aren't particularly informative to most users.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1840964392

From liach at openjdk.org  Wed Nov 13 18:30:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 18:30:22 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v5]
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <DRxhcoZGlMJj3RpIlOEbXUwoaUuiojPJaJU6La5vXqg=.7e7728fc-f143-41c8-998c-189c6ed846c1@github.com>

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Thanks Jorn for help

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21912/files
  - new: https://git.openjdk.org/jdk/pull/21912/files/2306ceba..6b996c3a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21912&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21912&range=03-04

  Stats: 6 lines in 1 file changed: 3 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21912.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21912/head:pull/21912

PR: https://git.openjdk.org/jdk/pull/21912

From darcy at openjdk.org  Wed Nov 13 18:31:42 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Wed, 13 Nov 2024 18:31:42 GMT
Subject: Integrated: 8341260: Add Float16 to jdk.incubator.vector
In-Reply-To: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
Message-ID: <xYFoynG5UrCWtMZ2HoNTczjg19jpUnHW_qZj6XA1Srs=.22dc3adb-09c2-4949-a2a9-1def8f97f315@github.com>

On Thu, 17 Oct 2024 23:11:07 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Port of Float16 from java.lang in the lworld+fp16 branch to jdk.incubabor.vector.

This pull request has now been integrated.

Changeset: dbf23466
Author:    Joe Darcy <darcy at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dbf23466aff902836838f06bcbbf3c9e7c5e9c6a
Stats:     3426 lines in 4 files changed: 3421 ins; 0 del; 5 mod

8341260: Add Float16 to jdk.incubator.vector

Co-authored-by: Raffaello Giulietti <rgiulietti at openjdk.org>
Co-authored-by: Jatin Bhateja <jbhateja at openjdk.org>
Reviewed-by: rgiulietti

-------------

PR: https://git.openjdk.org/jdk/pull/21574

From jvernee at openjdk.org  Wed Nov 13 18:35:22 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 13 Nov 2024 18:35:22 GMT
Subject: RFR: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory [v5]
In-Reply-To: <DRxhcoZGlMJj3RpIlOEbXUwoaUuiojPJaJU6La5vXqg=.7e7728fc-f143-41c8-998c-189c6ed846c1@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
 <DRxhcoZGlMJj3RpIlOEbXUwoaUuiojPJaJU6La5vXqg=.7e7728fc-f143-41c8-998c-189c6ed846c1@github.com>
Message-ID: <21uMNJhgT49iHft1cCqDqWibisw114aziOtmR-VJsb8=.f0731e5d-c8c1-44f2-9b44-434a94ae9a60@github.com>

On Wed, 13 Nov 2024 18:30:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
>> 
>> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
>> 
>> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.
>
> Chen Liang has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Thanks Jorn for help

Marked as reviewed by jvernee (Reviewer).

Had a quick discussion with Chen offline. I had mixed up the use case the doc was talking about. The latest version mentions both problematic cases.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21912#pullrequestreview-2434119356
PR Comment: https://git.openjdk.org/jdk/pull/21912#issuecomment-2474421684

From bpb at openjdk.org  Wed Nov 13 18:45:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 18:45:53 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v2]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <baZqH9QXXEG8sQz6b4i9FlhEjjonT1fqpYNHs8g1QG4=.48bdc742-ad50-4784-92ec-54115ea57cfa@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8343039: Remove use of InternalLock from Stream{De,En}coder and throwable; remove InternalLock class; address comments on BIS and BOS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/cbaf8947..21c9c5e2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=00-01

  Stats: 392 lines in 6 files changed: 32 ins; 271 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From bpb at openjdk.org  Wed Nov 13 18:45:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 18:45:53 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <Inx1Z42fg5Cbs58X7KPXuzBF7ttW2Ot3DDVKjvtObz4=.293ef5a4-1591-4489-8512-961e4dcb2cff@github.com>

On Tue, 12 Nov 2024 21:45:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

21c9c5e addresses reviewer comments above and removes `InternalLock`. I will submit on more commit to remove `JavaIOPrint{Stream,Writer}Access`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474450426

From alanb at openjdk.org  Wed Nov 13 18:52:02 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 18:52:02 GMT
Subject: Integrated: 8343981: Remove usage of security manager from Thread and
 related classes
In-Reply-To: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
References: <dRQzwigt0FYSBOMOTB-ZZBvsw4lR-VMstswhaavvoHU=.5b3d616d-0197-4bcc-81da-1e0bc069fed1@github.com>
Message-ID: <CDUBmwV2CgLLZvhxXMf3EDmesgt_pwPGQsV-f9rn2SM=.cb7eaf0f-51f1-4d6c-aa98-fc0eed8e34a0@github.com>

On Tue, 12 Nov 2024 10:41:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Removes the SecurityManager usage from Thread + friends.
> 
> In Thread, the getContextClassLoader method is no longer caller-sensitive method.
> 
> JavaLangAccess.newThreadWithAcc is removed and jdk.internal.access is no longer exported to java.naming. The usage of newThreadWithAcc is removed from com.sun.jndi.ldap.VersionHelper. There will be further work on the java.naming module to remove usage of SM, the change here is specific to the usage of ewThreadWithAcc.

This pull request has now been integrated.

Changeset: 5e01c40b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5e01c40b19a5bf4d0266747ca73aca4193799d97
Stats:     282 lines in 10 files changed: 0 ins; 228 del; 54 mod

8343981: Remove usage of security manager from Thread and related classes

Reviewed-by: rriggs, yzheng

-------------

PR: https://git.openjdk.org/jdk/pull/22035

From bpb at openjdk.org  Wed Nov 13 19:00:36 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 19:00:36 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v3]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/21c9c5e2..d3d1e3a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=01-02

  Stats: 113 lines in 6 files changed: 0 ins; 111 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From bpb at openjdk.org  Wed Nov 13 19:00:36 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 19:00:36 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <vuKrVZ3dJ3bxxrN5BpVCvKMg2f5r_KBmVYbbyP6HQkU=.6452b55d-c283-4561-ac16-a87b1cea6d7a@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <ZgQCMQLZl6SCMccn9hN-t2BmywYF7_4j7X0UAlOEMnU=.5a7dc892-66e1-4d5c-b191-f37e506b9266@github.com>
 <vuKrVZ3dJ3bxxrN5BpVCvKMg2f5r_KBmVYbbyP6HQkU=.6452b55d-c283-4561-ac16-a87b1cea6d7a@github.com>
Message-ID: <e7eWORCMd3G2H56RtZyNEJqYgh_PLDAlZ18_SxCSoTQ=.a0371301-76ed-406b-a982-b7d0a6ffbfe5@github.com>

On Wed, 13 Nov 2024 16:08:51 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I don't mind if JavaIOPrintStreamAccess is removed now or in a later PR.

It is removed by d3d1e3a.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474479043

From shade at openjdk.org  Wed Nov 13 19:05:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 19:05:04 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
Message-ID: <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>

On Wed, 13 Nov 2024 17:19:18 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>>  - Touchups: assert index, polish commits
>>  - Fix
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 290:
> 
>> 288:                 list.remove(lastIdx);
>> 289: 
>> 290:                 // Capacity control: trim the backing storage if it looks like
> 
> I think we need to set maxIdx to lastIdx - 1 here.  Otherwise, we'll never trim back the storage.  maxIdx can only increase in insert() as currently implemented.

Right, d'oh. The unavailability of `ArrayList.capacity()` is what gets us in this mess. I'll try to rewrite to just plain arrays.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841012953

From alanb at openjdk.org  Wed Nov 13 19:05:21 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 19:05:21 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs [v2]
In-Reply-To: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
Message-ID: <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>

> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
> 
> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
> 
> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
> 
> runtime/cds/appcds/StaticArchiveWithLambda.java is updated as creating the archive no longer skips a generated class.
> 
> Testing: tier1-5

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - StaticArchiveWithLambda no longer skips dynamically generated class when creating archive
 - Merge branch 'master' into JDK-8344011
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22063/files
  - new: https://git.openjdk.org/jdk/pull/22063/files/b46c4fea..1687ad54

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22063&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22063&range=00-01

  Stats: 7342 lines in 85 files changed: 5659 ins; 433 del; 1250 mod
  Patch: https://git.openjdk.org/jdk/pull/22063.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22063/head:pull/22063

PR: https://git.openjdk.org/jdk/pull/22063

From alanb at openjdk.org  Wed Nov 13 19:05:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 19:05:22 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs
In-Reply-To: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
Message-ID: <NHzK5vgiMMCa2YHUMbQiAkMpQwpE67fOV6piG49VBGs=.e07ceb81-c6e7-4b02-b056-4a9231243345@github.com>

On Wed, 13 Nov 2024 10:32:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
> 
> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
> 
> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
> 
> runtime/cds/appcds/StaticArchiveWithLambda.java is updated as creating the archive no longer skips a generated class.
> 
> Testing: tier1-5

runtime/cds/appcds/StaticArchiveWithLambda.java is update to not assume that the archive create skips a generated classes (confirmed with Ioi).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22063#issuecomment-2474485817

From psandoz at openjdk.org  Wed Nov 13 19:10:17 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Wed, 13 Nov 2024 19:10:17 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <_J30xBDEFG5HFDhbnG9YaJH4kjns68-Tf-xpdRl7atU=.37ae41db-5962-4ad1-815a-d226cd9fe77d@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
 <vZV35ckouuZV-_7dcqf1beBbusFld507_VqkVG0Pymw=.f89d1268-1f65-44fe-af45-94543299be31@github.com>
 <_J30xBDEFG5HFDhbnG9YaJH4kjns68-Tf-xpdRl7atU=.37ae41db-5962-4ad1-815a-d226cd9fe77d@github.com>
Message-ID: <zN4lgFV1uzSqIx4QCmBT0hSkvT8sSJiuCj0uMJcYNak=.41aba5a6-a847-47c4-abf0-0f58d50ff280@github.com>

On Wed, 13 Nov 2024 06:40:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 91:
>> 
>>> 89: // JEP-401 (https://openjdk.org/jeps/401).
>>> 90: // @jdk.internal.MigratedValueClass
>>> 91: // @jdk.internal.ValueBased
>> 
>> Please uncomment value-based class annotation.
>> Float16 does comply with the semantics of value-based classes.
>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/doc-files/ValueBased.html
>
> The jdk.internal.ValueBased annotation is not exported for use outside of the java.base module.

We can do this in a subsequent PR and export the package `jdk.internal` to module `jdk.incubating.vector` like we do for other `java.base` internal packages. I believe no other changes should be necessary, but we should double check.

Classes in the `jdk.incubating.vector` module are loaded in the boot class loader and are considered privileged, therefore the internal `@ValueBased` annotation will not be ignored by the runtime.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1841020576

From aturbanov at openjdk.org  Wed Nov 13 19:29:36 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Nov 2024 19:29:36 GMT
Subject: RFR: 8344023: Unnecessary Hashtable usage in
 LdapClient.defaultBinaryAttrs
In-Reply-To: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
References: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
Message-ID: <Jg5fWcPjAeMf9xiAKXRL756DqpTxoIRXhxnGUj0oOQ4=.94645a9b-6e47-4213-8e3d-d61027a638a4@github.com>

On Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is fully initialized in `<clinit>` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.

I run `com/sun/jndi` tests on my win x64. All green.
Thank you for review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21903#issuecomment-2474527594

From aturbanov at openjdk.org  Wed Nov 13 19:29:37 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Wed, 13 Nov 2024 19:29:37 GMT
Subject: Integrated: 8344023: Unnecessary Hashtable usage in
 LdapClient.defaultBinaryAttrs
In-Reply-To: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
References: <po7h-WvBT9DZn9yM-h-ojvUOr0sZAu2BGDO6UAYNVoM=.357e6df7-1a25-41f4-ad60-6d0771814956@github.com>
Message-ID: <OXkp2dwl5QkgdbdyIgbZcJUgRUPMumXK55Dckfv0xh4=.4c37fe81-3577-41fb-9d51-9811821cbd73@github.com>

On Tue, 5 Nov 2024 12:49:04 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

> Content of Hashtable `com.sun.jndi.ldap.LdapClient#defaultBinaryAttrs` is fully initialized in `<clinit>` block.
> It means we can replace legacy synchronized `Hashtable` with immutable set.

This pull request has now been integrated.

Changeset: ffea9809
Author:    Andrey Turbanov <aturbanov at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ffea9809a72777fd6bfac5d0052c7db676aa20d1
Stats:     29 lines in 1 file changed: 1 ins; 9 del; 19 mod

8344023: Unnecessary Hashtable usage in LdapClient.defaultBinaryAttrs

Reviewed-by: dfuchs, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/21903

From jbhateja at openjdk.org  Wed Nov 13 19:29:44 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 13 Nov 2024 19:29:44 GMT
Subject: RFR: 8341260: Add Float16 to jdk.incubator.vector [v11]
In-Reply-To: <_J30xBDEFG5HFDhbnG9YaJH4kjns68-Tf-xpdRl7atU=.37ae41db-5962-4ad1-815a-d226cd9fe77d@github.com>
References: <mW2MQKb8g49GE2b45QVyvkbqk4spJbeNVeZtGT6z2gs=.58712060-3dcf-441a-bafb-78dd6ef508f1@github.com>
 <RhtvfJTckZqQqaNeeNYwU3zn2Cauf7dchByFkHQaJlc=.8133105d-20f6-4363-80d3-6e9407b6516f@github.com>
 <vZV35ckouuZV-_7dcqf1beBbusFld507_VqkVG0Pymw=.f89d1268-1f65-44fe-af45-94543299be31@github.com>
 <_J30xBDEFG5HFDhbnG9YaJH4kjns68-Tf-xpdRl7atU=.37ae41db-5962-4ad1-815a-d226cd9fe77d@github.com>
Message-ID: <HcLEJ6jNOOA0twzde3vTHH47g6JxT72VAKe46Qsz0oM=.57e8bebc-cbf1-4530-b89b-f040e0472693@github.com>

On Wed, 13 Nov 2024 06:40:15 GMT, Joe Darcy <darcy at openjdk.org> wrote:

>> src/jdk.incubator.vector/share/classes/jdk/incubator/vector/Float16.java line 91:
>> 
>>> 89: // JEP-401 (https://openjdk.org/jeps/401).
>>> 90: // @jdk.internal.MigratedValueClass
>>> 91: // @jdk.internal.ValueBased
>> 
>> Please uncomment value-based class annotation.
>> Float16 does comply with the semantics of value-based classes.
>> https://docs.oracle.com/en/java/javase/22/docs/api/java.base/java/lang/doc-files/ValueBased.html
>
> The jdk.internal.ValueBased annotation is not exported for use outside of the java.base module.

Hi @jddarcy, Would you suggest passing ?add-exports=java.base/JDK.internal=ALL-UNNAMED while compiling Float16.java to mark it as a Value-Based class.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21574#discussion_r1841041378

From duke at openjdk.org  Wed Nov 13 19:38:52 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 13 Nov 2024 19:38:52 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v10]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <or9AnCyZz3AiRy8yXOGjnze7xO5HKL6FbcHt7aJHEFU=.956062a8-d669-463f-83f0-1135473e65ad@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 39 commits:

 - Address review feedback
 - Merge remote-tracking branch 'upstream-jdk/master' into serialization
 - Merge remote-tracking branch 'upstream-jdk/master' into serialization
 - Round out the documentation of the new methods to explain the supported and unsupported cases
 - Move `serialPersistentFields` for a degree of method order consistency
 - Address review feedback
 - Test fixes and finish renaming
 - Address review feedback
 - Address review comment
 - Eliminate cache
 - ... and 29 more: https://git.openjdk.org/jdk/compare/eb240a7d...7a85d620

-------------

Changes: https://git.openjdk.org/jdk/pull/19702/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=09
  Stats: 914 lines in 6 files changed: 911 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From duke at openjdk.org  Wed Nov 13 19:38:56 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 13 Nov 2024 19:38:56 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v9]
In-Reply-To: <8V5Q5vAmzi7CBHCZnksZO6KrzqzAnbS2SL9sgZjSKy8=.62141c0f-fde3-4857-9b08-6e721c05e6fa@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <wTMrsu3s8L3ePcCXnZ2bpu2_c-rttm32Y0bqNA3VI_s=.96c2cd5c-184c-4e59-a5c5-e20cbdbaf2bb@github.com>
 <8V5Q5vAmzi7CBHCZnksZO6KrzqzAnbS2SL9sgZjSKy8=.62141c0f-fde3-4857-9b08-6e721c05e6fa@github.com>
Message-ID: <Rg9hxD06yc409w9XjjzFcMT6y3lhZX3GDWuQESxlNls=.d921b650-353f-48d3-9519-a610d5f4cc65@github.com>

On Wed, 13 Nov 2024 17:47:57 GMT, Chen Liang <liach at openjdk.org> wrote:

>> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 37 commits:
>> 
>>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>>  - Move `serialPersistentFields` for a degree of method order consistency
>>  - Address review feedback
>>  - Test fixes and finish renaming
>>  - Address review feedback
>>  - Address review comment
>>  - Eliminate cache
>>  - Rework using facilities found in ObjectStreamClass
>>    
>>    This variation has the disadvantage of requiring a couple temporary arrays to be allocated each time the method handles are used.
>>  - More tests
>>  - ... and 27 more: https://git.openjdk.org/jdk/compare/133f8f31...d57c4346
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 80:
> 
>> 78:     private ReflectionFactory() {
>> 79:         this.langReflectAccess = SharedSecrets.getJavaLangReflectAccess();
>> 80:         this.javaObjectStreamReflectionAccess = SharedSecrets.getJavaObjectStreamReflectionAccess();
> 
> ReflectionFactory is created on very early bootstrap, even before `JavaLangAccess` is ready.  This extra dependency is only used when the unsupported version is used, and this dependency, calling MethodHandle, should have changed the boot class loading/initialization sequence by making MH initialization early.  Can you check with a hello world app and run it with `-Xlog:class+init` to check the initialization sequence?
> 
> I strongly recommend not caching this access object, and just call `getJavaObjectStreamReflectionAccess()` on demand.

I only added the field for consistency with the existing one (which predates my PR), but inlining it is fine with me. I'll make that change now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19702#discussion_r1841053650

From alanb at openjdk.org  Wed Nov 13 19:45:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 19:45:20 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v3]
In-Reply-To: <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
Message-ID: <0oNShhM8j63if6X0tekb9WJ1OGuYIUb1vNB5bPXuVwM=.df02eb8c-0f22-4390-a56a-41450ef3231a@github.com>

On Wed, 13 Nov 2024 19:00:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof

src/java.base/share/classes/java/io/BufferedInputStream.java line 242:

> 240:         initialSize = size;
> 241:         if (getClass() == BufferedInputStream.class) {
> 242:             buf = EMPTY;

Maybe keep "lazily create buffer when not subclassed" as the comment.

src/java.base/share/classes/java/io/BufferedOutputStream.java line 88:

> 86:         }
> 87: 
> 88:         this.buf = new byte[initialSize]; // resizable if initialSize < maxSize

Something has got messed up here, it creates the byte[] twice now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841062387
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841064710

From liach at openjdk.org  Wed Nov 13 19:45:21 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 19:45:21 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v3]
In-Reply-To: <en5P1DrQjJUcCjPQCEY0Sqj1taXR-YmAIijXwUCYGmQ=.c4ede912-957b-4a02-bb4f-bb31c12134e0@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <uJYNUluaPl_8vhs8y5Y0AjwmwidsiAo_UumjENbM-TY=.335f062e-ddf3-49c4-9c2c-f1acd9a21527@github.com>
 <en5P1DrQjJUcCjPQCEY0Sqj1taXR-YmAIijXwUCYGmQ=.c4ede912-957b-4a02-bb4f-bb31c12134e0@github.com>
Message-ID: <mJ2Ti__OfNJ1h3lstXM_xMaqsy5ufws7r1-dRCmKIfo=.8ddb0b9e-d413-4646-8f07-0d63b2c7920d@github.com>

On Wed, 13 Nov 2024 07:15:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedOutputStream.java line 88:
>> 
>>> 86:         }
>>> 87: 
>>> 88:         this.buf = new byte[initialSize]; // resizable if initialSize < maxSize
>> 
>> Same remark as for BIS.
>> 
>> Also this initial vs max size feature was added when virtual thread was first implemented as the internal locks.  Is this implementation detail still necessary for the virtual threads?
>
> Think about 100_000 virtual threads, all blocked on sockets with input/output streams that have wrapped with buffered streams, as in BIS and BOS. This is the motivation for using a reduced initial size.

Suggestion:


Seems you forgot to remove this line after restoring the if-else below.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841061978

From raffaello.giulietti at oracle.com  Wed Nov 13 19:48:53 2024
From: raffaello.giulietti at oracle.com (Raffaello Giulietti)
Date: Wed, 13 Nov 2024 20:48:53 +0100
Subject: Math.toIntExact why only long?
In-Reply-To: <CAF+DQ5fpFeVd=vkSGSaA5biBmsB=4PB4P-YszC=D=TGU8hhvKw@mail.gmail.com>
References: <CAF+DQ5fpFeVd=vkSGSaA5biBmsB=4PB4P-YszC=D=TGU8hhvKw@mail.gmail.com>
Message-ID: <8aababce-2ce1-4876-8ace-b0a73cd6b51c@oracle.com>

The plan is to use the facilities described in "JEP 488: Primitive Types 
in Patterns, instanceof, and switch (Second Preview)" once they become a 
permanent _language_ feature.

Currently, you can perform one of the tests provided in 
https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/lang/runtime/ExactConversionsSupport.html, 
and then safely cast if the test succeeds.

But I suggest to rather wait for the JEP to become permanent, as it 
integrates much more elegantly with the ongoing "pattern" work and the 
rest of the language. You can enable preview features in JDK 23 if you'd 
like to get a feeling.


HTH
Raffaello


On 2024-11-13 13:08, Andrey Turbanov wrote:
> I wounder, why java.lang.Math.toIntExact accepts only long parameter?
> I think it will quite useful to have it with float/double parameters too.
> 
> Andrey Turbanov


From bpb at openjdk.org  Wed Nov 13 19:49:03 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 19:49:03 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v3]
In-Reply-To: <0oNShhM8j63if6X0tekb9WJ1OGuYIUb1vNB5bPXuVwM=.df02eb8c-0f22-4390-a56a-41450ef3231a@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
 <0oNShhM8j63if6X0tekb9WJ1OGuYIUb1vNB5bPXuVwM=.df02eb8c-0f22-4390-a56a-41450ef3231a@github.com>
Message-ID: <PqtSD5ob8j8d0Q_bUVINWZp5G7DhAUAiSjzAWN2gfEI=.be140dcd-b1e8-42a0-8b36-d5a05efbaaa8@github.com>

On Wed, 13 Nov 2024 19:42:29 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof
>
> src/java.base/share/classes/java/io/BufferedOutputStream.java line 88:
> 
>> 86:         }
>> 87: 
>> 88:         this.buf = new byte[initialSize]; // resizable if initialSize < maxSize
> 
> Something has got messed up here, it creates the byte[] twice now.

Yeah, @liach caught that above: fixing.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841069282

From alanb at openjdk.org  Wed Nov 13 19:52:57 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 19:52:57 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v3]
In-Reply-To: <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
Message-ID: <rn-f1Czed2ZB6qbgJrZBWeCI27j5qHeqxfbRGr7mhSU=.cd204557-2f49-426a-9c60-0e94e4b30ea2@github.com>

On Wed, 13 Nov 2024 19:00:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof

src/java.base/share/classes/java/io/PrintWriter.java line 422:

> 420:      */
> 421:     public void close() {
> 422:         Object lock = this.lock;

I assume L422 can be deleted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841074351

From bchristi at openjdk.org  Wed Nov 13 20:00:28 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 13 Nov 2024 20:00:28 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <_uqJXPm0kvj5HGR6t5Y6InoNXsqV8ZGYwTCM491k55s=.debdcf8a-d55f-4850-9a5b-c5df4922faec@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <PLJ7i4mRNGvZilXMH4zT9nklkMrpgkQrPyZgOZIUlKg=.8f35cfa4-52ce-48d8-a86d-6894221c9e8a@github.com>
 <_uqJXPm0kvj5HGR6t5Y6InoNXsqV8ZGYwTCM491k55s=.debdcf8a-d55f-4850-9a5b-c5df4922faec@github.com>
Message-ID: <NIXDZW6hFRel8MsdkPgGPVhCUDN6wFW93eYFSwLeRmE=.35251616-32a1-41f0-a790-7136a6010306@github.com>

On Wed, 13 Nov 2024 08:16:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 300:
>> 
>>> 298:                 return true;
>>> 299:             }
>>> 300:         }
>> 
>> It looks like the new `PhantomCleanableList.remove()` puts 100% trust in the correctness of the PhantomCleanable's `index`.
>> 
>> What would you think of adding some sort of check/assert that `list.get(phc.index) == phc` ?
>
> Right, tracking indexes is the part of the algo. I added asserts in most important sites, `java/lang` still passes with `-esa`. Please take a look again.

Better - thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841081278

From alanb at openjdk.org  Wed Nov 13 20:01:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 20:01:44 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v3]
In-Reply-To: <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
Message-ID: <WIDYtpYO2UWPiKh49OND5ZS7r77sxlGD6IQpdVM__tU=.6ac2c5bd-130a-45fc-91e8-8cc2f2ce1d9c@github.com>

On Wed, 13 Nov 2024 19:00:36 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof

I did a pass over the latest update, a lot of changes, it's good that Chen is reviewing too as would be too easy to introduce a bug with this refactor.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474647438

From mullan at openjdk.org  Wed Nov 13 20:01:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Nov 2024 20:01:49 GMT
Subject: RFR: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec [v5]
In-Reply-To: <1oJga566b3c4g8iZnqUVjeR4vCjFuLzhlo92debLSEc=.f18f48bf-5111-42bb-9b70-d0449d194f53@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
 <1oJga566b3c4g8iZnqUVjeR4vCjFuLzhlo92debLSEc=.f18f48bf-5111-42bb-9b70-d0449d194f53@github.com>
Message-ID: <yQdjqVb1btib4l6CKgUgMxUIumPEziaGkarsm0Yo4xA=.326ac8d0-674e-4bb7-bce2-2f3e0284823d@github.com>

On Wed, 13 Nov 2024 15:51:44 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.
>
> Roger Riggs has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Merge branch '8343958-process-sm-cleanup' of https://github.com/RogerRiggs/jdk into 8343958-process-sm-cleanup
>  - Revert unnecessary copyright change in ProcessEnvironment.java.
>    Fix code style in ProcessImpl
>    Drop unneeded suppress warnings.
>    Remove obsolete @throws SecurityExceptions
>    Correct compilation errors in Windows ProcessImpl

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22024#pullrequestreview-2434290781

From rriggs at openjdk.org  Wed Nov 13 20:06:12 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 20:06:12 GMT
Subject: Integrated: 8344039: Remove security manager dependency in java.time
In-Reply-To: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
References: <JWlgY0q0TS7r1RHK8wODwdyh_bBlhxwk6Vo1g8ywel8=.874d57a1-0990-406e-b74e-0b7207a70f02@github.com>
Message-ID: <v-E0VR1m_wp3_iFLoV2_88bc0jVQE7OB1H1TtX4tVME=.45591dc4-52c9-4703-b838-11bc0e64c95a@github.com>

On Tue, 12 Nov 2024 15:41:01 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), java.time implementation dependencies on doPriviledged and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

This pull request has now been integrated.

Changeset: 5ac330b1
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5ac330b1ac81e932924e0ea10988f2536352be04
Stats:     79 lines in 2 files changed: 1 ins; 32 del; 46 mod

8344039: Remove security manager dependency in java.time

Reviewed-by: naoto, mullan, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/22042

From bpb at openjdk.org  Wed Nov 13 20:07:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 20:07:59 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v4]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <w-ffTEQp7i81fV_As9zvX6wpPld_ofMTnukFsYhcM40=.bf247390-c1c1-4ad5-a03a-5bcddc4238c4@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8343039: Address reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/d3d1e3a5..9417b53d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=02-03

  Stats: 5 lines in 3 files changed: 2 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From bpb at openjdk.org  Wed Nov 13 20:07:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 20:07:59 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v3]
In-Reply-To: <WIDYtpYO2UWPiKh49OND5ZS7r77sxlGD6IQpdVM__tU=.6ac2c5bd-130a-45fc-91e8-8cc2f2ce1d9c@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <TTknPWPM11uyeiRsHhUQAMIhDqiCcIMPNWV03Ta2Nbs=.a4b9c053-6e3f-4aa4-94ac-71e2970e7ff4@github.com>
 <WIDYtpYO2UWPiKh49OND5ZS7r77sxlGD6IQpdVM__tU=.6ac2c5bd-130a-45fc-91e8-8cc2f2ce1d9c@github.com>
Message-ID: <NvzfJqklGvSWXGRn6CCktehBthKh5JyiuuOqeYHVNhY=.3f5deec0-d59e-4fed-8d67-7a33237b7b15@github.com>

On Wed, 13 Nov 2024 19:57:39 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> [...] it's good that Chen is reviewing too as would be too easy to introduce a bug with this refactor.

Definitely on both counts.

> src/java.base/share/classes/java/io/BufferedInputStream.java line 242:
> 
>> 240:         initialSize = size;
>> 241:         if (getClass() == BufferedInputStream.class) {
>> 242:             buf = EMPTY;
> 
> Maybe keep "lazily create buffer when not subclassed" as the comment.

See 9417b53.

> src/java.base/share/classes/java/io/PrintWriter.java line 422:
> 
>> 420:      */
>> 421:     public void close() {
>> 422:         Object lock = this.lock;
> 
> I assume L422 can be deleted.

Yep: 9417b53.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474663889
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841089672
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841090342

From bpb at openjdk.org  Wed Nov 13 20:16:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 20:16:44 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v5]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <2BC0y-mkW4MhEoiHZFr3igqnjmFZc60Szllvoiqci_w=.77e5bd50-baa0-4545-89c6-58dd4c1d2290@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8343039: Remove InternalLock reference from java/lang/ProcessBuilder/Basic.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/9417b53d..f5548c1b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=03-04

  Stats: 10 lines in 1 file changed: 0 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From bpb at openjdk.org  Wed Nov 13 20:16:45 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 20:16:45 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v4]
In-Reply-To: <w-ffTEQp7i81fV_As9zvX6wpPld_ofMTnukFsYhcM40=.bf247390-c1c1-4ad5-a03a-5bcddc4238c4@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <w-ffTEQp7i81fV_As9zvX6wpPld_ofMTnukFsYhcM40=.bf247390-c1c1-4ad5-a03a-5bcddc4238c4@github.com>
Message-ID: <XuD9qXuJOiO7QL_SCpNpeH1JodtNXi-E1BtCaNfPKTI=.49a94313-2ffc-4b45-8f58-cae0345b39c6@github.com>

On Wed, 13 Nov 2024 20:07:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Address reviewer comments

f5548c1 fixes a test failure caught during CI testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2474694195

From kevinw at openjdk.org  Wed Nov 13 20:21:08 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Wed, 13 Nov 2024 20:21:08 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <Ii7cVmWIyFLR4Q5q7TAl2NENV2_ixQJAGYEqdbdzkCc=.1bec7144-ad3e-4818-98f8-643daadba001@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

I think this means the one-true-master copy of a man page is now the public .md file.
All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes.
(Which is great, I just didn't see it being explicitly said.)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474701337

From alanb at openjdk.org  Wed Nov 13 20:25:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 13 Nov 2024 20:25:20 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v5]
In-Reply-To: <2BC0y-mkW4MhEoiHZFr3igqnjmFZc60Szllvoiqci_w=.77e5bd50-baa0-4545-89c6-58dd4c1d2290@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <2BC0y-mkW4MhEoiHZFr3igqnjmFZc60Szllvoiqci_w=.77e5bd50-baa0-4545-89c6-58dd4c1d2290@github.com>
Message-ID: <4eWa9JxqSBJ7mCWt2Cvx1njq65z203epF8LcMGYj-s0=.d659fe03-0b59-4ac2-bd13-ef7eb074b429@github.com>

On Wed, 13 Nov 2024 20:16:44 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Remove InternalLock reference from java/lang/ProcessBuilder/Basic.java

test/jdk/java/lang/ProcessBuilder/Basic.java line 2876:


Can you check if java.base/jdk.internal.misc can be dropped from the `@modules` in the test description?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841111376

From bpb at openjdk.org  Wed Nov 13 20:32:21 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 20:32:21 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v6]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <-KfgZXMP21ZIWvmwwAdFHS3ES6XdK2ObgDRrnV6C9FE=.63b096a0-f7f4-4c8e-8d8a-c11eb4f7eb3d@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8343039: Remove java.base/jdk.internal.misc from @modules in test java/lang/ProcessBuilder/Basic.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/f5548c1b..2034b5db

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=04-05

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From shade at openjdk.org  Wed Nov 13 20:33:25 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 20:33:25 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v5]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <Sx6TLaIy-9yQTYMS-uMmZWkwMzPoy-hmhklUPi1yy6c=.fb28e679-af6d-4c56-a19d-f531b254d329@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback: make sure trimming actually works, stylistic changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/0194c9bc..d4a03d85

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=03-04

  Stats: 40 lines in 2 files changed: 18 ins; 0 del; 22 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Wed Nov 13 20:33:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 20:33:26 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
Message-ID: <Kk9m6_1ky9lyCipsJOQ98D-bxbcgm7nr0x16B8_zjh0=.cf5f8853-cd54-40eb-bebf-a28da8bd49a6@github.com>

On Wed, 13 Nov 2024 17:22:21 GMT, Kelvin Nilsen <kdnilsen at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
>> 
>>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>>  - Touchups: assert index, polish commits
>>  - Fix
>
> src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java line 71:
> 
>> 69:         this.index = -1;
>> 70:         this.list = CleanerImpl.getCleanerImpl(cleaner).activeList;
>> 71:         list.insert(this);
> 
> For consistency, maybe use "this.list.insert(this)", or remove "this" from the preceding two lines.

Right, done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841120926

From bpb at openjdk.org  Wed Nov 13 20:35:31 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 20:35:31 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v6]
In-Reply-To: <4eWa9JxqSBJ7mCWt2Cvx1njq65z203epF8LcMGYj-s0=.d659fe03-0b59-4ac2-bd13-ef7eb074b429@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <2BC0y-mkW4MhEoiHZFr3igqnjmFZc60Szllvoiqci_w=.77e5bd50-baa0-4545-89c6-58dd4c1d2290@github.com>
 <4eWa9JxqSBJ7mCWt2Cvx1njq65z203epF8LcMGYj-s0=.d659fe03-0b59-4ac2-bd13-ef7eb074b429@github.com>
Message-ID: <kL7wZUnBQg35NIeJ7C3z1QvyuuflwGZG54j6D38TJqU=.4592f0c2-3189-411d-bd8f-8b7990c5db40@github.com>

On Wed, 13 Nov 2024 20:22:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343039: Remove java.base/jdk.internal.misc from @modules in test java/lang/ProcessBuilder/Basic.java
>
> test/jdk/java/lang/ProcessBuilder/Basic.java line 2876:
> 
> 
> Can you check if java.base/jdk.internal.misc can be dropped from the `@modules` in the test description?

Removed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1841122841

From vromero at openjdk.org  Wed Nov 13 20:43:44 2024
From: vromero at openjdk.org (Vicente Romero)
Date: Wed, 13 Nov 2024 20:43:44 GMT
Subject: RFR: 8335989: Implement JEP 494: Module Import Declarations
 (Second Preview) [v7]
In-Reply-To: <4ybB5B_AJXd-L8tGumK4LJz4oil4sLOO9xXtpO3eMK8=.3c6fe57d-1f1b-45d0-aae7-fd1ccb5773d1@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
 <4ybB5B_AJXd-L8tGumK4LJz4oil4sLOO9xXtpO3eMK8=.3c6fe57d-1f1b-45d0-aae7-fd1ccb5773d1@github.com>
Message-ID: <U4b-12wHJ0rQERBY8emTn-go1YXcWB7YbVXcgm6xd7I=.f5a9abb1-7df2-4f16-96c1-d3db79d7ee34@github.com>

On Wed, 13 Nov 2024 12:33:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
>> 
>> The main changes are:
>> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
>> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
>> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
>> 
>> import module java.base;
>> import module java.desktop;
>> ...
>> List l;//ambigous
>> 
>> but:
>> 
>> import module java.base;
>> import module java.desktop;
>> import java.util.*;
>> ...
>> List l;//not ambigous, reference to java.util.List
>
> Jan Lahoda has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 21 commits:
> 
>  - Merge branch 'master' into JDK-8335989
>  - Merge branch 'master' into JDK-8335989
>  - Moving operators to the beginning of line, as suggested.
>  - Updating PreviewFeature metadata
>  - Cleanup.
>  - Merge branch 'master' into JDK-8335989
>  - Merge branch 'master' into JDK-8335989
>  - Reflecting review feedback.
>  - Cleanup.
>  - Cleanup.
>  - ... and 11 more: https://git.openjdk.org/jdk/compare/79345bbb...babcfccf

looks good

-------------

Marked as reviewed by vromero (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21431#pullrequestreview-2434370098

From shade at openjdk.org  Wed Nov 13 20:49:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 13 Nov 2024 20:49:18 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
 <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
Message-ID: <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>

On Wed, 13 Nov 2024 19:00:34 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 290:
>> 
>>> 288:                 list.remove(lastIdx);
>>> 289: 
>>> 290:                 // Capacity control: trim the backing storage if it looks like
>> 
>> I think we need to set maxIdx to lastIdx - 1 here.  Otherwise, we'll never trim back the storage.  maxIdx can only increase in insert() as currently implemented.
>
> Right, d'oh. The unavailability of `ArrayList.capacity()` is what gets us in this mess. I'll try to rewrite to just plain arrays.

I pushed the array-based implementation, but ran out of time to properly test it. I'll circle back to it tomorrow. Review if you can, but it will probably have some touchups later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841138042

From rriggs at openjdk.org  Wed Nov 13 20:52:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 13 Nov 2024 20:52:16 GMT
Subject: Integrated: 8343958: Remove security manager impl in java.lang.Process
 and java.lang.Runtime.exec
In-Reply-To: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
References: <9N3S5g9EWajbHx5_NhOVa_K3b8EwtXKWCHsB7mUznFw=.113258e0-58ae-433f-bb07-f1b807581bee@github.com>
Message-ID: <rKffz4My8n1DHQrkFhptABx385U888GN-4BF3S9ZqRc=.4218a9d4-9213-49ab-859b-5e9c8d6b7337@github.com>

On Tue, 12 Nov 2024 01:41:27 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor removing the dependencies on SecurityManager, doPrivileged, and AccessController.

This pull request has now been integrated.

Changeset: 168b18ec
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/168b18ec68dd5488704cf76895d2449cd86428a6
Stats:     180 lines in 4 files changed: 8 ins; 122 del; 50 mod

8343958: Remove security manager impl in java.lang.Process and java.lang.Runtime.exec

Reviewed-by: jpai, mullan, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22024

From cstein at openjdk.org  Wed Nov 13 20:56:51 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 13 Nov 2024 20:56:51 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <PHyC5A7Ex4Q-AenCRUvAu_Jov2pnSGiIiCmmsfcRg44=.19e00289-a896-48a7-8ea8-05f63ed0b3e8@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

So glad to see progress here!

https://github.com/openjdk/jdk/blob/1484153c1a092cefc20270b35aa1e508280843a4/test/langtools/jdk/javadoc/tool/CheckManPageOptions.java#L141

should read `return findRootDir().resolve("src/jdk.javadoc/share/man/javadoc.md");` now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474760888

From jjg at openjdk.org  Wed Nov 13 21:21:32 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Wed, 13 Nov 2024 21:21:32 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <Ii7cVmWIyFLR4Q5q7TAl2NENV2_ixQJAGYEqdbdzkCc=.1bec7144-ad3e-4818-98f8-643daadba001@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <Ii7cVmWIyFLR4Q5q7TAl2NENV2_ixQJAGYEqdbdzkCc=.1bec7144-ad3e-4818-98f8-643daadba001@github.com>
Message-ID: <hs9l_aVDMpskTmhf_ovJv8cHP9FepHgxV3UCdxSe7DE=.230ad939-6314-4add-a921-7dea6249c191@github.com>

On Wed, 13 Nov 2024 20:17:24 GMT, Kevin Walls <kevinw at openjdk.org> wrote:

> I think this means the one-true-master copy of a man page is now the public .md file. All contributors can now change and improve man pages, and would be expected to make necessary man page updates when making other changes. (Which is great, I just didn't see it being explicitly said.)

Yes, related: 
Non-trivial updates to these pages should be approved in a CSR, maybe along with any code changes that may make such an update necessary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2474804913

From iklam at openjdk.org  Wed Nov 13 21:23:37 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Wed, 13 Nov 2024 21:23:37 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v11]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <WTF19ZN2XVovZOC6noW40VzEC_AOxQb1vbLcN4BbRjQ=.81d98bf4-b7b1-4650-9e25-911fb787bfb9@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 178 commits:

 - Merge branch 'master' into jep-483-candidate
 - fixed merge with UseCompactObjectHeaders
 -  Merge branch 'master' into jep-483-candidate
 - fixed merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline
 - @DanHeidinga comment -- exit VM when runtimeSetup() fails
 - fixed merge
 - Merge branch 'master' into jep-483-candidate
 - 8343493: Perform module checks during MetaspaceShared::map_archives()
 - reverted changes in modules.cpp to make it easy to merge with mainline
 - ... and 168 more: https://git.openjdk.org/jdk/compare/5e01c40b...fc86c00e

-------------

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=10
  Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From dholmes at openjdk.org  Wed Nov 13 21:35:39 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 13 Nov 2024 21:35:39 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Great to finally see this happen!

Just one glitch with the GPL headers.

Thanks

src/java.base/share/man/java.md line 9:

> 7: # published by the Free Software Foundation.  Oracle designates this
> 8: # particular file as subject to the "Classpath" exception as provided
> 9: # by Oracle in the LICENSE file that accompanied this code.

Documentation files should not have the Classpath exception.

make/data/license-templates/gpl-header

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434474132
PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841189067

From cstein at openjdk.org  Wed Nov 13 21:35:40 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 13 Nov 2024 21:35:40 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <XOo88TaSl5QEwAEJISAsUq0BYBtieHSYSBQHovdgdEU=.9894ac56-793f-4ec1-901b-eb476eec2a51@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

A missing `.1` to `.md` file extension change in `javadoc`'s manpage self-test `CheckManPageOptions.java` is causing the CI to fail.

Details in https://github.com/openjdk/jdk/pull/22081#issuecomment-2474760888

-------------

Changes requested by cstein (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2434491865

From bpb at openjdk.org  Wed Nov 13 21:39:54 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 21:39:54 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v7]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <pRF9JYoj9GYXU3_8zuTotAIzd-6AWl6ECYCRGCtVrsU=.655e2d40-3e7b-4ce1-9927-716b7b8f9d96@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8343039: Remove failing getDeclaredField call from test java/lang/ProcessBuilder/Basic.java

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/2034b5db..0b68ed08

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=05-06

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From iris at openjdk.org  Wed Nov 13 21:59:34 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 13 Nov 2024 21:59:34 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>
Message-ID: <QyBh2MR7GEWc2oQ3NimEgV8rHcbvbLEoOK_vAwVaMjo=.2fc260cc-25c2-47fd-8bc1-57d0f45e7d62@github.com>

On Wed, 13 Nov 2024 21:27:02 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> src/java.base/share/man/java.md line 9:
> 
>> 7: # published by the Free Software Foundation.  Oracle designates this
>> 8: # particular file as subject to the "Classpath" exception as provided
>> 9: # by Oracle in the LICENSE file that accompanied this code.
> 
> Documentation files should not have the Classpath exception.
> 
> make/data/license-templates/gpl-header

Agree.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1841231909

From liach at openjdk.org  Wed Nov 13 22:10:38 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 13 Nov 2024 22:10:38 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs [v2]
In-Reply-To: <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
 <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>
Message-ID: <5AvGzVkKFlzkny6IyyGN7cIoD3WRgvDINUs12zUdJxo=.f7295ff8-d50c-472f-a15a-4cbf174f54da@github.com>

On Wed, 13 Nov 2024 19:05:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
>> 
>> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
>> 
>> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
>> 
>> runtime/cds/appcds/StaticArchiveWithLambda.java is updated as creating the archive no longer skips a generated class.
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - StaticArchiveWithLambda no longer skips dynamically generated class when creating archive
>  - Merge branch 'master' into JDK-8344011
>  - Initial commit

The update to StaticArchiveWithLambda test makes sense.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22063#pullrequestreview-2434576677

From mullan at openjdk.org  Wed Nov 13 22:35:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Wed, 13 Nov 2024 22:35:23 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs [v2]
In-Reply-To: <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
 <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>
Message-ID: <eJNXZBVG_mswl9N7Q3KrvDVCadPzSP7jUho7zx7MQ6I=.1aae577e-dfad-4c25-b203-e0aac3588d14@github.com>

On Wed, 13 Nov 2024 19:05:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
>> 
>> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
>> 
>> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
>> 
>> runtime/cds/appcds/StaticArchiveWithLambda.java is updated as creating the archive no longer skips a generated class.
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - StaticArchiveWithLambda no longer skips dynamically generated class when creating archive
>  - Merge branch 'master' into JDK-8344011
>  - Initial commit

Reviewed most of it, so far only couple of minor comments, can try to finish up tomorrow.

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 1:

> 1: /*

Lines 55-57, can the "access to the constructor" part be removed from the comment?

src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 1:

> 1: /*

Line 82: is `GetReflectionFactoryAction` still needed?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22063#pullrequestreview-2434601792
PR Review Comment: https://git.openjdk.org/jdk/pull/22063#discussion_r1841266005
PR Review Comment: https://git.openjdk.org/jdk/pull/22063#discussion_r1841267049

From sviswanathan at openjdk.org  Wed Nov 13 23:00:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Wed, 13 Nov 2024 23:00:19 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v4]
In-Reply-To: <6fxu6YabwpKc13hCZ7Aw46C02K68kozOCBZY3Rn8R8g=.c42f98dc-c253-4972-b2a5-ea8ff5e6061b@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <6fxu6YabwpKc13hCZ7Aw46C02K68kozOCBZY3Rn8R8g=.c42f98dc-c253-4972-b2a5-ea8ff5e6061b@github.com>
Message-ID: <UiOLjJCREi3LmhUNxuqhgnmgvHciJcuQpZaV3NfWR9Y=.02af032f-17bd-417c-b1b9-12c550daa1a2@github.com>

On Wed, 13 Nov 2024 02:43:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains seven commits:
> 
>  - Removing target specific hooks
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - Review resoultions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - Handle new I2L pattern, IR tests, Rewiring pattern inputs to MulVL further optimizes JIT code
>  - Review resolutions
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

Looks good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2434642849

From bpb at openjdk.org  Wed Nov 13 23:04:23 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 13 Nov 2024 23:04:23 GMT
Subject: RFR: 8342086: FileInputStream.available() fails with
 "Incorrect function" for "nul" path (win)
In-Reply-To: <DSNlSoQ7EXxmctWrMZmLXsl302ZDwdjRNufp-G8S2Z4=.ecc1050c-7e10-4ae7-83fd-39624a6aa59f@github.com>
References: <DSNlSoQ7EXxmctWrMZmLXsl302ZDwdjRNufp-G8S2Z4=.ecc1050c-7e10-4ae7-83fd-39624a6aa59f@github.com>
Message-ID: <-L3Y_re3Y8bKCgClfeVRnCuJZnlUGBA71-Lu0pfRjLI=.94621d59-4829-4746-9742-54798bf5353d@github.com>

On Wed, 16 Oct 2024 16:56:38 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Modify the `handleAvailable` native code path to ignore an `ERROR_INVALID_FUNCTION` encountered by `PeekNamedPipe` and update an existing test to verify this change.

continue;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21543#issuecomment-2474997696

From swen at openjdk.org  Wed Nov 13 23:21:51 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Wed, 13 Nov 2024 23:21:51 GMT
Subject: Integrated: 8343984: Fix Unsafe address overflow
In-Reply-To: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
References: <TTG2tBzjXvbnfnGAHdM7LHHRZlDM0x0dI5I_zjP5Vz0=.f2c2b8a9-aa5a-4c03-a933-4b73535e7f5d@github.com>
Message-ID: <tRKVTDkB3E2Kxcr3K0nZZ4WTv9GrU_gv0wYgOXT0Y0E=.7e999494-1ed2-4985-9fe9-4d0d2de14852@github.com>

On Tue, 12 Nov 2024 07:30:41 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> In the JDK code, there are some places that may cause Unsafe offset overflow. The probability of occurrence is low, but if it occurs, it will cause JVM crash.

This pull request has now been integrated.

Changeset: 0dab920b
Author:    Shaojin Wen <swen at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0dab920b70560a5aea8b068080655a292908b646
Stats:     34 lines in 11 files changed: 0 ins; 0 del; 34 mod

8343984: Fix Unsafe address overflow

Reviewed-by: pminborg, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22027

From dl at openjdk.org  Thu Nov 14 00:18:55 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 14 Nov 2024 00:18:55 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v27]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <NbX5IQnp23hvtEpRseMG2C9EM3JxYKYRTbtxpBfCOV8=.a946de35-cba1-4aa9-9f17-43ea42ba8efb@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 48 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - Rename variable
 - Merge branch 'openjdk:master' into JDK-8336707
 - Improve readbility; tweak runState checks
 - Address review comments
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reconcile internal docs; renamings
 - Minor improvements
 - ... and 38 more: https://git.openjdk.org/jdk/compare/3ac4c723...cb179dda

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/a5f038f9..cb179dda

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=26
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=25-26

  Stats: 11364 lines in 225 files changed: 6033 ins; 3516 del; 1815 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From bchristi at openjdk.org  Thu Nov 14 00:33:37 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 14 Nov 2024 00:33:37 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
 <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
 <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>
Message-ID: <k0s5nWTBudBW0HYAlqPnWy-zXKIeFu4aaKXWwF7GOZE=.3737e4f3-81bd-4604-bf37-861df29043c7@github.com>

On Wed, 13 Nov 2024 20:46:09 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Right, d'oh. The unavailability of `ArrayList.capacity()` is what gets us in this mess. I'll try to rewrite to just plain arrays.
>
> I pushed the array-based implementation, but ran out of time to properly test it. I'll circle back to it tomorrow. Review if you can, but it will probably have some touchups later.

Speaking of testing, with this level of change, perhaps a new (white box?) regtest is warranted.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841361873

From liach at openjdk.org  Thu Nov 14 01:01:04 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 01:01:04 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v5]
In-Reply-To: <Sx6TLaIy-9yQTYMS-uMmZWkwMzPoy-hmhklUPi1yy6c=.fb28e679-af6d-4c56-a19d-f531b254d329@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <Sx6TLaIy-9yQTYMS-uMmZWkwMzPoy-hmhklUPi1yy6c=.fb28e679-af6d-4c56-a19d-f531b254d329@github.com>
Message-ID: <_pAw4IZ-x4LEhieEzaEWps8-NQxXYY3y6y35R04yKFg=.1a46477f-038e-4a19-9005-d94317ef55d7@github.com>

On Wed, 13 Nov 2024 20:33:25 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback: make sure trimming actually works, stylistic changes

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 236:

> 234:     static final class PhantomCleanableList {
> 235:         private static final int MIN_CAPACITY = 16;
> 236:         private final Object lock = new Object();

Why use another lock object when identity of this list is not escaped elsewhere?

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 311:

> 309:                 // want to cause an immediate resize on next insertion.
> 310:                 if ((size < arr.length / 4) && (size > MIN_CAPACITY)) {
> 311:                     int newLen = ArraysSupport.newLength(size, 1, size);

This code isn't immediately clear that it's trying to half the array size, as you are using the size computation method for array growth.  Can you add a remark for so?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841375400
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841378770

From nbenalla at openjdk.org  Thu Nov 14 01:28:15 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Thu, 14 Nov 2024 01:28:15 GMT
Subject: RFR: 8343780: Add since checker tests to the Tools area modules
 and add missing @since to  jdk.jfr.Recording [v2]
In-Reply-To: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>
References: <nEg3mkGNR5OfZpcl0O4vm_TQIY2jvvrUozdgsmusm84=.2c3d7073-4056-4f5a-9465-0c949f1d679b@github.com>
Message-ID: <PdQTZy2CNSIMP-QI9HHjlFAKXKdUpjtVmygwG6I6IrI=.d4953218-0c9a-4a63-86ea-4382189efa0b@github.com>

> Can I please get a review for this PR that add tests to verify the value of `@since` tags to the Tools area modules. The test is described in this [email](https://mail.openjdk.org/pipermail/jdk-dev/2024-October/009474.html). This issue is similar to JDK-8341399, JDK-8331051 and JDK-8343442.
> 
> The benefit from this is helping API authors and reviewer validate the accuracy of `@since` in their source code (and subsequently, in the generated documentation). And lessen the burden on Reviewers.
> 
> The test has been added for `java.base` and a few other modules and has helped catch some bugs before they make it to the JDK.
> 
> Notes: 
> - I have also added an `@since` tag that was missing.
> - You will notice there is no test for the `jdk.jfr` module, it will be added in a future PR because it requires special handling. (JFR used to be a commercial feature and this requires special handling to be added for it in the test)
> 
> TIA

Nizar Benalla has updated the pull request incrementally with one additional commit since the last revision:

  Add backticks, as they are necessary. Otherwise the `@since` is treated as a jtreg tag
  
  Revert "remove backticks"
  
  This reverts commit 83afb011685a4bc09bc994dd9a8891f6cdfe7217.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21982/files
  - new: https://git.openjdk.org/jdk/pull/21982/files/83afb011..c1615b31

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21982&range=00-01

  Stats: 6 lines in 5 files changed: 0 ins; 1 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/21982.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21982/head:pull/21982

PR: https://git.openjdk.org/jdk/pull/21982

From duke at openjdk.org  Thu Nov 14 02:29:27 2024
From: duke at openjdk.org (Naman Nigam)
Date: Thu, 14 Nov 2024 02:29:27 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v2]
In-Reply-To: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
Message-ID: <uF9q5_nAITTv5f3M69rADcZC04AAzO92nfHED6xJhFI=.b6bbd4ef-9d95-4e9f-8ae4-5e6157c63caa@github.com>

> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
> 
> if no such entry exists, returns the entry for the least key greater than the specified key;
> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.

Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8343125 : Resolve a bad merge

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21729/files
  - new: https://git.openjdk.org/jdk/pull/21729/files/47b580a8..905865a6

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21729&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21729&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21729/head:pull/21729

PR: https://git.openjdk.org/jdk/pull/21729

From duke at openjdk.org  Thu Nov 14 02:29:27 2024
From: duke at openjdk.org (Naman Nigam)
Date: Thu, 14 Nov 2024 02:29:27 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v2]
In-Reply-To: <nRbvoKUpTYp0mp9wOQxd9q2YNl7pKPpNX1gGJlH3naw=.78033920-79df-4f6d-8182-d572be7bc2a9@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <nRbvoKUpTYp0mp9wOQxd9q2YNl7pKPpNX1gGJlH3naw=.78033920-79df-4f6d-8182-d572be7bc2a9@github.com>
Message-ID: <V9FOCNGsQy8XJJHQCW-MWMuwzTvfHbNQvhlLE697YAs=.d6a84ccc-56d0-48cd-a862-bf15e7d43c32@github.com>

On Wed, 13 Nov 2024 17:38:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8343125 : Resolve a bad merge
>
> src/java.base/share/classes/java/util/TreeMap.java line 514:
> 
>> 512:                 }
>> 513:             } else {
>> 514:                 return p;
> 
> Is this from a bad merge?

seemingly, made a commit to resolve

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1841474519

From acobbs at openjdk.org  Thu Nov 14 02:40:24 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 02:40:24 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v2]
In-Reply-To: <uF9q5_nAITTv5f3M69rADcZC04AAzO92nfHED6xJhFI=.b6bbd4ef-9d95-4e9f-8ae4-5e6157c63caa@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <uF9q5_nAITTv5f3M69rADcZC04AAzO92nfHED6xJhFI=.b6bbd4ef-9d95-4e9f-8ae4-5e6157c63caa@github.com>
Message-ID: <RuAiKQ7AdNs09YyqHrQj1ZNWJeUR69eZ-Xl6N6RFFu0=.cc9a1ceb-292c-4feb-b6d7-8358629d7952@github.com>

On Thu, 14 Nov 2024 02:29:27 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
>> 
>> if no such entry exists, returns the entry for the least key greater than the specified key;
>> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
>> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.
>
> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8343125 : Resolve a bad merge

src/java.base/share/classes/java/util/TreeMap.java line 424:

> 422:     /**
> 423:      * Returns the entry for the least key greater than or equal to the specified key;
> 424:      * if no such entry exists (i.e. the specified key is greater than any key in the tree),

I'd suggest changing "the specified key is greater than any key in the tree" ? "the specified key is greater than any key in the tree, or the tree is empty"; same thing for `getFloorEntry()`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1841482450

From vlivanov at openjdk.org  Thu Nov 14 03:04:57 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 14 Nov 2024 03:04:57 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v4]
In-Reply-To: <6fxu6YabwpKc13hCZ7Aw46C02K68kozOCBZY3Rn8R8g=.c42f98dc-c253-4972-b2a5-ea8ff5e6061b@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <6fxu6YabwpKc13hCZ7Aw46C02K68kozOCBZY3Rn8R8g=.c42f98dc-c253-4972-b2a5-ea8ff5e6061b@github.com>
Message-ID: <Re_yhAsBMuDkfa1MYOCpTvHupP999c-uArmNN4PXh2M=.c6cc9d4c-671f-4119-9c43-07f90888c366@github.com>

On Wed, 13 Nov 2024 02:43:12 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains seven commits:
> 
>  - Removing target specific hooks
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - Review resoultions
>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>  - Handle new I2L pattern, IR tests, Rewiring pattern inputs to MulVL further optimizes JIT code
>  - Review resolutions
>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction

Overall, looks good.

Some minor refactoring suggestions follow.

src/hotspot/share/opto/vectornode.cpp line 2092:

> 2090:          n->in(1)->is_Con() &&
> 2091:          n->in(1)->bottom_type()->isa_long() &&
> 2092:          n->in(1)->bottom_type()->is_long()->get_con() <= 4294967295L;

Is it clearer to use `0xFFFFFFFFL` representation here?

src/hotspot/share/opto/vectornode.cpp line 2114:

> 2112: 
> 2113: static bool has_vector_elements_fit_int(Node* n) {
> 2114:   auto is_cast_integer_to_long_pattern = [](const Node* n) {

I like how you use lambda expressions for node predicates. 
Please, shape `has_vector_elements_fit_uint()` in a similar fashion.

test/hotspot/jtreg/compiler/vectorapi/VectorMultiplyOpt.java line 51:

> 49: 
> 50:     public static final int SIZE = 1024;
> 51:     public static final Random r = new Random(1024);

For reproducibility purposes, it's better to use `jdk.test.lib.Utils.getRandomInstance()`. It reports the seed and supports overriding it.

test/hotspot/jtreg/compiler/vectorapi/VectorMultiplyOpt.java line 105:

> 103:             LongVector vsrc2 = LongVector.fromArray(LSP, lsrc2, i);
> 104:             vsrc1.lanewise(VectorOperators.AND, 0xFFFFFFFFL)
> 105:                  .lanewise(VectorOperators.MUL, vsrc2.lanewise(VectorOperators.AND, 0xFFFFFFFFL))

It would be nice to randomize the constants (masks and shifts) to improve test coverage.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2434942773
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1841495626
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1841496794
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1841491826
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1841492208

From duke at openjdk.org  Thu Nov 14 03:23:29 2024
From: duke at openjdk.org (Naman Nigam)
Date: Thu, 14 Nov 2024 03:23:29 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v3]
In-Reply-To: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
Message-ID: <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>

> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
> 
> if no such entry exists, returns the entry for the least key greater than the specified key;
> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.

Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:

  JDK-8343125 : Empty tree case explicitly specified.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21729/files
  - new: https://git.openjdk.org/jdk/pull/21729/files/905865a6..48a0fc1a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21729&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21729&range=01-02

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21729.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21729/head:pull/21729

PR: https://git.openjdk.org/jdk/pull/21729

From duke at openjdk.org  Thu Nov 14 03:23:29 2024
From: duke at openjdk.org (Naman Nigam)
Date: Thu, 14 Nov 2024 03:23:29 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v2]
In-Reply-To: <RuAiKQ7AdNs09YyqHrQj1ZNWJeUR69eZ-Xl6N6RFFu0=.cc9a1ceb-292c-4feb-b6d7-8358629d7952@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <uF9q5_nAITTv5f3M69rADcZC04AAzO92nfHED6xJhFI=.b6bbd4ef-9d95-4e9f-8ae4-5e6157c63caa@github.com>
 <RuAiKQ7AdNs09YyqHrQj1ZNWJeUR69eZ-Xl6N6RFFu0=.cc9a1ceb-292c-4feb-b6d7-8358629d7952@github.com>
Message-ID: <ZzZGL_XkP9nd_QRWEduBEUoKo9BFd-amf9R9Abt8i4s=.106ffb01-686b-4b87-983b-7badc003fa87@github.com>

On Thu, 14 Nov 2024 02:36:38 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   JDK-8343125 : Resolve a bad merge
>
> src/java.base/share/classes/java/util/TreeMap.java line 424:
> 
>> 422:     /**
>> 423:      * Returns the entry for the least key greater than or equal to the specified key;
>> 424:      * if no such entry exists (i.e. the specified key is greater than any key in the tree),
> 
> I'd suggest changing "the specified key is greater than any key in the tree" ? "the specified key is greater than any key in the tree, or the tree is empty"; same thing for `getFloorEntry()`.

@archiecobbs Thank you for your suggestion. Yes, the tree being an empty case could be made explicit, though I was assuming it to be inferrable by the words 'any key' earlier. Updating with that as a change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1841506639

From acobbs at openjdk.org  Thu Nov 14 03:53:46 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 03:53:46 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v2]
In-Reply-To: <ZzZGL_XkP9nd_QRWEduBEUoKo9BFd-amf9R9Abt8i4s=.106ffb01-686b-4b87-983b-7badc003fa87@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <uF9q5_nAITTv5f3M69rADcZC04AAzO92nfHED6xJhFI=.b6bbd4ef-9d95-4e9f-8ae4-5e6157c63caa@github.com>
 <RuAiKQ7AdNs09YyqHrQj1ZNWJeUR69eZ-Xl6N6RFFu0=.cc9a1ceb-292c-4feb-b6d7-8358629d7952@github.com>
 <ZzZGL_XkP9nd_QRWEduBEUoKo9BFd-amf9R9Abt8i4s=.106ffb01-686b-4b87-983b-7badc003fa87@github.com>
Message-ID: <sjBrjUdt6bzwkSCHZ3Eu4hrz6kmwYgF0BKpg2H5c0HY=.28fac920-fb0c-468f-b93b-a8dd07abbcf1@github.com>

On Thu, 14 Nov 2024 03:19:01 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/TreeMap.java line 424:
>> 
>>> 422:     /**
>>> 423:      * Returns the entry for the least key greater than or equal to the specified key;
>>> 424:      * if no such entry exists (i.e. the specified key is greater than any key in the tree),
>> 
>> I'd suggest changing "the specified key is greater than any key in the tree" ? "the specified key is greater than any key in the tree, or the tree is empty"; same thing for `getFloorEntry()`.
>
> @archiecobbs Thank you for your suggestion. Yes, the tree being an empty case could be made explicit, though I was assuming it to be inferrable by the words 'any key' earlier. Updating with that as a change.

It's definitely inferrable (and the phrasing was from the original, so not your fault) but it's good to eliminate any ambiguity, however minimal, for a diverse public readership. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21729#discussion_r1841523077

From jpai at openjdk.org  Thu Nov 14 04:14:03 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Nov 2024 04:14:03 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v5]
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <WDw6WO-9RwCsJiqg-318U_v2Dd4omv0-7mHXxWp_cNw=.dadeb973-9649-419d-a322-e9c5ec092dbe@github.com>

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:

 - merge latest from master branch
 - update tests to match the new specification
 - Stuart's review - update the close() and end() expectations
 - Stuart's review - improve class level javadoc
 - merge latest from master branch
 - merge latest from master branch
 - Chen's suggestion - improve code comment
 - convert the tests to junit
 - fix whitespace
 - 8225763: Inflater and Deflater should implement AutoCloseable

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19675/files
  - new: https://git.openjdk.org/jdk/pull/19675/files/c4e84dd4..f1c57d0b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=03-04

  Stats: 105636 lines in 2776 files changed: 27046 ins; 69829 del; 8761 mod
  Patch: https://git.openjdk.org/jdk/pull/19675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675

PR: https://git.openjdk.org/jdk/pull/19675

From asemenyuk at openjdk.org  Thu Nov 14 04:20:55 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Nov 2024 04:20:55 GMT
Subject: Integrated: 8343875: Minor improvements of jpackage test library
In-Reply-To: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
References: <JVHvEjaXnOdxCIs5upgZV9pZ46YRU-titbqvhuJwJRk=.c9306f6e-b33e-4d6f-b6ad-e0085e81bdc4@github.com>
Message-ID: <1-Ssiup_F0CDEk7XHMdMMJjdnTWM-arosGgE1KWAdX4=.22dc4d7b-9206-4bcf-80ff-ffc829f0667e@github.com>

On Fri, 8 Nov 2024 23:57:58 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The PR affects jpackage test library only. Changes:
> 
> - Removed dependencies on `java.io.File`. `java.io.File.pathSeparator` is still used as there is no better alternative.
> - Use `TKit.concatMessages()` instead of `String.format()` in TKit.assert...() methods.
> - Added unit tests for all TKit.assert...() modified methods.
> - Added unit tests for `JavaAppDesc` class.
> - Added `jdk.jpackage.test.TestSuite` class to automatically run all jpackage test library unit tests. This eliminates the need to add jtreg comments to every jpackage test library unit test java source.

This pull request has now been integrated.

Changeset: 95a00f8a
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/95a00f8a188048952871a10dc428566b18b91cb8
Stats:     536 lines in 11 files changed: 473 ins; 30 del; 33 mod

8343875: Minor improvements of jpackage test library

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/21995

From prr at openjdk.org  Thu Nov 14 04:37:13 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Nov 2024 04:37:13 GMT
Subject: RFR: 8343490: Update copyright year for JDK-8341692
In-Reply-To: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com>
References: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com>
Message-ID: <9R5gF8dIqwO0TbBhICMDC7c2g4gvY0tXA82LcvmAEpI=.4159e63b-4899-48d9-9829-0f13c6307446@github.com>

On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The copyright year of some files which has been changed by  [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk.

FWIW this whole PR seems like a waste of a bug id. Copyright year is implied anyway.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21891#issuecomment-2475394959

From liach at openjdk.org  Thu Nov 14 05:03:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 05:03:46 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v3]
In-Reply-To: <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
Message-ID: <8tAkOnCYVUZpYmwhKMbUXJ2kcAu1fMx-trxWFcXzvaw=.a811436a-24a3-45f4-be10-55012e2c0b31@github.com>

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
>> 
>> if no such entry exists, returns the entry for the least key greater than the specified key;
>> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
>> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.
>
> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8343125 : Empty tree case explicitly specified.

Looks good.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21729#pullrequestreview-2435047333

From liach at openjdk.org  Thu Nov 14 05:04:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 05:04:43 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <HaROiuwLaPbPqU0yCkjrF_sErOyFu9SmyJ2Kz7mq1rw=.5dcd201b-6fe4-4c2b-a4c1-d9598bbdf641@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
 <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
 <HaROiuwLaPbPqU0yCkjrF_sErOyFu9SmyJ2Kz7mq1rw=.5dcd201b-6fe4-4c2b-a4c1-d9598bbdf641@github.com>
Message-ID: <45vdxLi7glsU82ec1dPxT-FEfrJVxAWliwOQ_-sGKko=.8795c8d8-c690-4df1-a98e-47fe44e32429@github.com>

On Thu, 7 Nov 2024 14:43:41 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/Deflater.java line 902:
>> 
>>> 900:      */
>>> 901:     @Override
>>> 902:     public void close() {
>> 
>> Can/should this method be final?  The real/original cleanup method is `end` and if both `close()` and `end()` are overriddable, there may be some confusion about which to implement.
>
> Hello Roger, I think that's a good idea. At least until there is a real reason for `close()` to be overridden by subclasses. I went back and checked the mailing list discussions (linked in this PR description) and I don't think marking `close()` as `final` has been suggested or rejected before. I will give others a chance to provide their inputs before I do this change.

I agree with marking these close methods as final as long as the previous corpus search did not find any user-defined close method in subclasses.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1841561300

From darcy at openjdk.org  Thu Nov 14 05:15:30 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Thu, 14 Nov 2024 05:15:30 GMT
Subject: RFR: 8342693: Use byte[] as parameter in a FDBigInteger
 constructor and as field
In-Reply-To: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>
References: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>
Message-ID: <6m3r3K-G8-1GcmfoA8-Y25XSIkXR8qYLv7_PEylwFu4=.89d7b083-ffbf-45ca-bc95-2c72c98b52d7@github.com>

On Mon, 21 Oct 2024 14:25:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This helps in reducing memory consumption, especially for long inputs.

Marked as reviewed by darcy (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21614#pullrequestreview-2435061028

From swen at openjdk.org  Thu Nov 14 05:47:12 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 14 Nov 2024 05:47:12 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
Message-ID: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>

The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.

@liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

-------------

Commit messages:
 - long Unsafe offset

Changes: https://git.openjdk.org/jdk/pull/22095/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344168
  Stats: 70 lines in 21 files changed: 0 ins; 0 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/22095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22095/head:pull/22095

PR: https://git.openjdk.org/jdk/pull/22095

From alanb at openjdk.org  Thu Nov 14 05:47:41 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 05:47:41 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs [v2]
In-Reply-To: <eJNXZBVG_mswl9N7Q3KrvDVCadPzSP7jUho7zx7MQ6I=.1aae577e-dfad-4c25-b203-e0aac3588d14@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
 <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>
 <eJNXZBVG_mswl9N7Q3KrvDVCadPzSP7jUho7zx7MQ6I=.1aae577e-dfad-4c25-b203-e0aac3588d14@github.com>
Message-ID: <k3ZX_DpzOumaNzusUgZbvYW2nK3XXI_8IN1Hfo966Y0=.874df46c-2d97-4217-8a68-d5f9872aa493@github.com>

On Wed, 13 Nov 2024 22:26:35 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
>> 
>>  - StaticArchiveWithLambda no longer skips dynamically generated class when creating archive
>>  - Merge branch 'master' into JDK-8344011
>>  - Initial commit
>
> src/java.base/share/classes/jdk/internal/reflect/ReflectionFactory.java line 1:
> 
>> 1: /*
> 
> Line 82: is `GetReflectionFactoryAction` still needed?

There's a sequencing issue here, this can't be removed until Roger's work on removing SM use from serialization are in. In general, we'll the efforts to remove usage of the SM from the JDK will require multiple passes due to dependencies like this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22063#discussion_r1841596240

From syan at openjdk.org  Thu Nov 14 06:16:22 2024
From: syan at openjdk.org (SendaoYan)
Date: Thu, 14 Nov 2024 06:16:22 GMT
Subject: Withdrawn: 8343490: Update copyright year for JDK-8341692
In-Reply-To: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com>
References: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com>
Message-ID: <hTeOO27LJUJcXohLvmn_8h_1LOT2N5WCTPpsFPvTI1s=.387b3447-70aa-4348-bbfa-e8c7454f21e3@github.com>

On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan <syan at openjdk.org> wrote:

> Hi all,
> The copyright year of some files which has been changed by  [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update correctly. This PR update the copyright year of [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21891

From jlahoda at openjdk.org  Thu Nov 14 06:16:56 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Nov 2024 06:16:56 GMT
Subject: Integrated: 8335989: Implement JEP 494: Module Import Declarations
 (Second Preview)
In-Reply-To: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
References: <WjPJaeiRNmminGplndbyAoPWixQ24m6THvudz50dSDI=.43bad947-2d64-4daa-b87e-6f26a4ec4a30@github.com>
Message-ID: <JkE9oXRZo6VVxhbGIy4P3kTDms8cCjAy1S0JECbmyjw=.4b342b90-e065-4d6c-ae92-cb6dfdf16f3b@github.com>

On Wed, 9 Oct 2024 19:22:01 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a current patch for module imports declarations, second preview. At least the JEP number and preview revision will need to be updated in `jdk.internal.javac.PreviewFeature.Feature`, but otherwise I believe this is ready to receive feedback.
> 
> The main changes are:
> - `requires transitive java.base;` is permitted, under the preview flag. Both javac and the runtime module system are updated to accept this directive when preview is enabled.
> - the `java.se` module is using `requires transitive java.base;`, and is deemed to be participating in preview, so its classfile version is not tainted. Runtime is updated to access `requires transitive java.base;` in any `java.*`, considering all of them to be participating in preview. Can be tighten up to only `java.se` is desired.
> - the types imported through module imports can be shadowed using on-demand imports. So, for example, having:
> 
> import module java.base;
> import module java.desktop;
> ...
> List l;//ambigous
> 
> but:
> 
> import module java.base;
> import module java.desktop;
> import java.util.*;
> ...
> List l;//not ambigous, reference to java.util.List

This pull request has now been integrated.

Changeset: 1e97c1c9
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1e97c1c913220b07ff0c1c977cea80bc9436729d
Stats:     762 lines in 28 files changed: 580 ins; 46 del; 136 mod

8335989: Implement JEP 494: Module Import Declarations (Second Preview)

Reviewed-by: vromero, abimpoudis, mcimadamore, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/21431

From pkoppula at openjdk.org  Thu Nov 14 06:30:53 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Thu, 14 Nov 2024 06:30:53 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v11]
In-Reply-To: <XTQ-TYPeAhQwhk7O73SJY1WycSkshAZgVhrhImCFSaI=.7b10a7ca-42c2-49c7-bd6a-4374e80e90e8@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <e9XneE4CQS0xlG3zIFZbOCt6j-gz0kRRUTLh45Pjxbs=.6f4cf332-68e1-4546-a859-435a72669094@github.com>
 <XTQ-TYPeAhQwhk7O73SJY1WycSkshAZgVhrhImCFSaI=.7b10a7ca-42c2-49c7-bd6a-4374e80e90e8@github.com>
Message-ID: <w-_vx9k8mompiYC2JYkW1qED5qShwJZdg5kZPutHjfY=.14e98e97-e66f-48c6-8bdd-ef6f07407ca2@github.com>

On Thu, 7 Nov 2024 18:46:42 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Prasadrao Koppula has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge master
>>  - initialized storeName with empty string
>>  - Replaced Paths.get with Path.of
>>  - Removed unnecessary code
>>  - Removed unnecessary code
>>  - Handled nested wrappers around FileInputStream
>>  - Handled BIS case as well
>>  - JDK-8329251
>>  - JDK-8329251
>>  - JDK-8329251
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2316f68...c90b4f30
>
> src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 283:
> 
>> 281:         if (ks != null && SSLLogger.isOn && SSLLogger.isOn("trustmanager")) {
>> 282:             String keystorePath = SharedSecrets
>> 283:                     .getJavaSecurityKeyStoreAccess()
> 
> This code only works if `java.security.debug=keystore` is also enabled, otherwise it will always return `null`. I think that dependency is not intuitive, and will be hard for users to remember. I think you should change `KeyStore.java` to always cache the filename, whether debug is on or not.

The primary concern is the repeated calls to SharedSecrets to access the inputStream, even though the keystore name is needed in minimal cases ( only when debug enabled) . To optimize, we can cache the filename and access it only when debugging is enabled, reducing unnecessary overhead in the common case.

I agree that dependency is not intuitive and hard for users to remember.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1841634533

From yzheng at openjdk.org  Thu Nov 14 07:36:14 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 14 Nov 2024 07:36:14 GMT
Subject: RFR: 8344011: Remove usage of security manager from Class and
 reflective APIs [v2]
In-Reply-To: <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
 <vQ6EPwOMkK16wU8aY3xnlvrLAXnTNGc2YBnm-nF2seI=.6fa5bcbd-ef4f-49e7-bdb1-dd36c29179c0@github.com>
Message-ID: <Qkhao_RgUXSnOzwffPTGe2a07XWIkeQlT-LbCws6cX8=.5b041a3a-5fef-4d14-9db8-e5b0e34b7c9f@github.com>

On Wed, 13 Nov 2024 19:05:21 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
>> 
>> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
>> 
>> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
>> 
>> runtime/cds/appcds/StaticArchiveWithLambda.java is updated as creating the archive no longer skips a generated class.
>> 
>> Testing: tier1-5
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - StaticArchiveWithLambda no longer skips dynamically generated class when creating archive
>  - Merge branch 'master' into JDK-8344011
>  - Initial commit

LGTM. Graal changes are ready

-------------

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22063#pullrequestreview-2435251121

From alanb at openjdk.org  Thu Nov 14 07:42:24 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 07:42:24 GMT
Subject: Integrated: 8344011: Remove usage of security manager from Class and
 reflective APIs
In-Reply-To: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
References: <zOMH__TAvmi6t1oFkNbeeGdcmsXpcbvsryslfQbsNi8=.da325988-e6d3-4d9b-85de-d8976299179e@github.com>
Message-ID: <aTe0NwDudHsBnKTUSomoER8v8m_5tLkBM2UVH5ru63k=.ae2f2a37-726b-4096-bfde-0f6506dd712b@github.com>

On Wed, 13 Nov 2024 10:32:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove code required for the now defunct SecurityManager execution mode from java.lang.Class, friends, and reflection APIs. Careful review is required so I've set Reviewer to 2. I've tried to keep the changes as easy to review as possible and not go over board with cleanup.
> 
> sun.reflect.misc.ReflectUtil are been hollowed out. A future pass will remove empty methods and qualified exports once the changes in "far away" code and modules is done.
> 
> In Lookup's class description, the removal of the sentence "avoid package access checks for classes accessible to the lookup class"  and the link to the removed "Security manager interactions" section is in discussion/non-normative text, just missed in the JEP 486 update that remove the linked section.
> 
> runtime/cds/appcds/StaticArchiveWithLambda.java is updated as creating the archive no longer skips a generated class.
> 
> Testing: tier1-5

This pull request has now been integrated.

Changeset: abacece8
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/abacece8265996aaec888c8f109f2e476ec7a8e3
Stats:     1254 lines in 26 files changed: 6 ins; 1094 del; 154 mod

8344011: Remove usage of security manager from Class and reflective APIs

Reviewed-by: liach, yzheng, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/22063

From dholmes at openjdk.org  Thu Nov 14 08:20:21 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 14 Nov 2024 08:20:21 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <cTJGh15MhcznWk1mgnet3mhaRrxbalcoQv-VPBI4JvI=.3f9cdb00-96aa-43d0-af6a-1d3674ccf9ab@github.com>

On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

Looking at this I'm not at all convinced this is the right thing to do. The `ARRAY_BYTE_BASE_OFFSET` is a small value - it is an `int`.

I understand there is concern about integer arithmetic overflow, but I'm not convinced this is where it needs to be addressed.

src/java.base/share/classes/java/util/zip/CRC32C.java line 227:

> 225:             long alignLength
> 226:                     = (8 - ((Unsafe.ARRAY_BYTE_BASE_OFFSET + off) & 0x7)) & 0x7;
> 227:             for (long alignEnd = off + alignLength; off < alignEnd; off++) {

I think casting the (now) long expression back to `int` makes more sense here.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22095#pullrequestreview-2435312059
PR Review Comment: https://git.openjdk.org/jdk/pull/22095#discussion_r1841736158

From jlahoda at openjdk.org  Thu Nov 14 08:26:31 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Nov 2024 08:26:31 GMT
Subject: Integrated: 8342936: Enhance java.io.IO with parameter-less println()
 and readln()
In-Reply-To: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
References: <O5G5fg6g32p4GTr5PMibH7sSMCMr4C8rQ-c7-ChV_4w=.072b449f-2a57-4360-b406-b1d89ca43ea4@github.com>
Message-ID: <wKRTRSG5GtR8ghs8xoE_PI6FlNEF94TYP3Ab9eysiEM=.b1f0d92a-1af1-4082-b0f8-c7adc0ed7e0e@github.com>

On Thu, 24 Oct 2024 19:27:47 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This PR is simply adding parameter-less `java.io.IO.{println(),readln()}`, with the (hopefully) obvious semantics, plus the corresponding wiring to make those work. This may become part of JEP 495:
> https://openjdk.org/jeps/495

This pull request has now been integrated.

Changeset: c3776db4
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c3776db498193d45088ed19e2a1d2697281fd590
Stats:     231 lines in 14 files changed: 212 ins; 8 del; 11 mod

8342936: Enhance java.io.IO with parameter-less println() and readln()

Reviewed-by: asotona, jpai, naoto

-------------

PR: https://git.openjdk.org/jdk/pull/21693

From swen at openjdk.org  Thu Nov 14 08:55:02 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 14 Nov 2024 08:55:02 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <cTJGh15MhcznWk1mgnet3mhaRrxbalcoQv-VPBI4JvI=.3f9cdb00-96aa-43d0-af6a-1d3674ccf9ab@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <cTJGh15MhcznWk1mgnet3mhaRrxbalcoQv-VPBI4JvI=.3f9cdb00-96aa-43d0-af6a-1d3674ccf9ab@github.com>
Message-ID: <X4-DzBjQRnI_TOwo7Pc6WPUnaWGqIdyfP0GANXraUfs=.21437081-1170-4536-a984-6d673fe6e387@github.com>

On Thu, 14 Nov 2024 08:08:08 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
>> 
>> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.
>
> src/java.base/share/classes/java/util/zip/CRC32C.java line 227:
> 
>> 225:             long alignLength
>> 226:                     = (8 - ((Unsafe.ARRAY_BYTE_BASE_OFFSET + off) & 0x7)) & 0x7;
>> 227:             for (long alignEnd = off + alignLength; off < alignEnd; off++) {
> 
> I think casting the (now) long expression back to `int` makes more sense here.

alignLength is a very small value, which is an int, but alignEnd needs to be a long. Here, changing alignLength to a long can avoid alignEnd overflow.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22095#discussion_r1841800097

From dfuchs at openjdk.org  Thu Nov 14 09:05:42 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 14 Nov 2024 09:05:42 GMT
Subject: RFR: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <AycUeSLX9L93ofeVSrDSkhF7_vgwwoT0_h8_Hq_4qko=.03fef401-4f94-41bf-82c7-1b50d35e2ee0@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

The jwebserver.md looks OK to me.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2435435938

From alanb at openjdk.org  Thu Nov 14 09:17:00 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 09:17:00 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader and
 related classes
Message-ID: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>

Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.

URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that require special attention.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22097/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22097&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343982
  Stats: 437 lines in 7 files changed: 6 ins; 361 del; 70 mod
  Patch: https://git.openjdk.org/jdk/pull/22097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22097/head:pull/22097

PR: https://git.openjdk.org/jdk/pull/22097

From vklang at openjdk.org  Thu Nov 14 09:20:54 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 14 Nov 2024 09:20:54 GMT
Subject: RFR: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <M2JoLgysYkeL2xLVp-gybrDFJRe00XRA0VxGw9Rv8d8=.0bafa449-a556-4b01-9b5f-1a20ad5e2eb7@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
 <Gkde-5XL0_HkPDtXrDMzo8CSqyBmfHgpbWXHAlwJx4Y=.2688ad88-a4f2-48c9-b0c2-e525ab09ce25@github.com>
 <N8uDMPKAmNoIHcrPL5ANsekTo_EZgAx5A3vcPG1TAGs=.ec289464-d1ea-41e1-8b4b-6f9efea115fe@github.com>
 <yHivhZDbDe8LDmYozE9q5jfsncP2PVtuiq92CIRpAXs=.2cf17315-7cef-4a5a-9aed-0ee1c7cc19b8@github.com>
 <M2JoLgysYkeL2xLVp-gybrDFJRe00XRA0VxGw9Rv8d8=.0bafa449-a556-4b01-9b5f-1a20ad5e2eb7@github.com>
Message-ID: <XA58EEswvf1fNlsgnyTSoOLGnLSJ7tnGuQZEs6vIXf0=.e320c126-0ecd-466f-8567-adf1cb4af174@github.com>

On Tue, 12 Nov 2024 19:31:21 GMT, kabutz <duke at openjdk.org> wrote:

>>> @kabutz Let me know how you want to proceed. ?
>> 
>> 've made the changes and sent another PR to the branch holding the changes. Hope that's the right way of doing it...
>
>> @kabutz The update for CSLM is based on @DougLea's proposal on the JBS issue, right? (Assuming that's the case I will add him as a co-contributor)
> 
> Yes, correct.

Thanks @kabutz & @DougLea!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21820#issuecomment-2475805806

From duke at openjdk.org  Thu Nov 14 09:20:55 2024
From: duke at openjdk.org (kabutz)
Date: Thu, 14 Nov 2024 09:20:55 GMT
Subject: Integrated: 8343426: ConcurrentSkipListMap.spliterator() can no longer
 split the stream
In-Reply-To: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
References: <tgm_j_IzQeAgZV9b8fUjtYL_s9leG6ucuaaeeDyslCM=.d27b38f0-9f35-4c42-ba81-215308cd6ff6@github.com>
Message-ID: <YV5790fnWOgSjJI17sD3fC7ruDeBFzqYC4xZ2grlHS4=.a02c6553-717b-4243-86ee-e8c8a10a1ef2@github.com>

On Fri, 1 Nov 2024 10:13:15 GMT, kabutz <duke at openjdk.org> wrote:

> Since Java 10, spliterators for the ConcurrentSkipListMap were pointing to the head, which has item == null, rather than to the first element. The trySplit() method no longer worked, and always returned null. Therefore, parallel streams have not worked for ConcurrentSkipListMap and ConcurrentSkipListSet since Java 10. It worked correctly in Java 8 and 9.
> 
> The problem lies in the constructor calls for the various spliterators. In Java 9, we pass in head.node.next as "origin" into the  constructor. In Java 10, this was changed to just head.node as "origin". Since the "item" field is always null on head.node, we never enter the first if() statement in the trySplit() method and thus it always returns null.

This pull request has now been integrated.

Changeset: 2b57f402
Author:    Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
Committer: Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2b57f402c46104d4aba784a891ba90604f5e9e4c
Stats:     40 lines in 2 files changed: 31 ins; 0 del; 9 mod

8343426: ConcurrentSkipListMap.spliterator() can no longer split the stream

Co-authored-by: Doug Lea <dl at openjdk.org>
Reviewed-by: vklang

-------------

PR: https://git.openjdk.org/jdk/pull/21820

From viktor.klang at oracle.com  Thu Nov 14 09:22:15 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 14 Nov 2024 09:22:15 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
Message-ID: <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>

The issue here is that the operation cannot advertise this, as it depends on the combination of operations.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David Alayachew <davidalayachew at gmail.com>
Sent: Wednesday, 13 November 2024 14:07
To: Rob Spoor <openjdk at icemanx.nl>
Cc: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

That is a good point Rob.

Then let me correct myself -- I think the terminal operations don't do a great job of advertising whether or not they pre-fetch everything when parallelism is activated. Collector fetches as needed. FindAny pre-fetches everything. I understand that later releases might change their behaviour, but I still want to document the current behaviour in the official javadocs so that we can limit undocumented tripping hazards.


On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>> wrote:
distinct() doesn't require everything to be pulled. It can push elements
to the downstream as they come along for the first time. When
downstream.push returns false the gatherer is done.

As part of some experimentation I've implemented all intermediary
operations using gatherers. Most of them are pretty straightforward and
will stop integrating once the downstream starts rejecting elements
(although some use Gatherer.ofSequential to keep it easy). I only found
two exceptions that don't return the result of downstream.push:

* mapMulti. The downstream.push is passed as the mapper which is a
Consumer - the return value is ignored. With some more effort it's
probably possible to capture any false return value and return that from
the integrator, but I haven't tried that yet.

* sorted. Obviously every element needs to be inspected.


On 13/11/2024 00:37, David Alayachew wrote:
> Oh sure, I expect something like distinct() to pull everything. In order to
> know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
>
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
>
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
>
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
>
>
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>
>>> We are told how Streams can process unbounded data sets, but when it
>> tries to do a findAny() with parallel(), it runs into an OOME because it
>> fetched all the data ahead of time. In fact, almost of the terminal
>> operations will hit an OOME in the exact same way if they are parallel and
>> have a big enough data set. It's definitely not the end of the world, but
>> it seems that I have to fit everything into a Collector and/or a Gatherer
>> if I want to avoid pre-fetching everything.
>>
>> Yeah, I think it is important to distinguish "can process unbounded data
>> sets" from "always able to process unbounded data sets".
>>
>> Some operations inherently need the end of the stream, so even something
>> somple like: stream.distinct() or stream.sorted() can end up pulling in all
>> data (which of course won't terminate).
>>
>> Fortunately, I think Gatherers can unlock much more situations where
>> unbounded streams can be processed.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 15:08
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
>> as I thought of it.
>>
>>
>> I hand-waved away the idea because I thought that the method would turn
>> the stream pipeline parallel, thus, recreating the same problem I currently
>> have of parallelism causing all of the elements to be fetched ahead of
>> time, causing an OOME.
>>
>>
>> It did NOT occur to me that the pipeline would stay sequential, and just
>> kick these off sequentially, but have them executing in parallel. I can't
>> see why I came to that incorrect conclusion. I have read the javadocs of
>> this method several times. Though, to be fair, I came to the same,
>> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
>> until someone pointed out what the documentation was actually saying that I
>> realized it's true properties.
>>
>> Thanks. That definitely solves at least part of my problem. Obviously, I
>> would prefer to write to S3 in parallel too, but at the very least, the
>> calculation part is being done in parallel. And worst case scenario, I can
>> be really bad and just do the write to S3 in the mapConcurrent, and then
>> just return the metadata of each write, and just bundle that up with
>> collect.
>>
>>
>> And that's ignoring the fact that I can just use the workaround too.
>>
>>
>> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
>> from a performance perspective, but is rather unintuitive to me from a
>> usability perspective. We are told how Streams can process unbounded data
>> sets, but when it tries to do a findAny() with parallel(), it runs into an
>> OOME because it fetched all the data ahead of time. In fact, almost of the
>> terminal operations will hit an OOME in the exact same way if they are
>> parallel and have a big enough data set. It's definitely not the end of the
>> world, but it seems that I have to fit everything into a Collector and/or a
>> Gatherer if I want to avoid pre-fetching everything.
>>
>> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Have you considered Gatherers.mapConcurrent(?)?
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 01:53
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> Good to know, ty vm.
>>
>> At the very least, I have this workaround. This will meet my needs for now.
>>
>> I guess my final question would be -- is this type of problem better
>> suited to something besides parallel streams? Maybe an ExecutorService?
>>
>> Really, all I am doing is taking a jumbo file, splitting it into batches,
>> and then doing some work on those batches. My IO speeds are pretty fast,
>> and the compute work is non-trivial, so there is performance being left on
>> the table if I give up parallelism. And I am in a position where completion
>> time is very important to us.
>>
>> I just naturally assumed parallel streams were the right choice because
>> the compute work is simple. A pure function that I can break out, and then
>> call in a map. Once I do that, I just call forEach to write the batches
>> back out to S3. Maybe I should look into a different part of the std lib
>> instead because I am using the wrong tool for the job? My nose says
>> ExecutorService, but I figure I should ask before I dive too deep in.
>>
>>
>> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> You're most welcome!
>>
>> In a potential future where all intermediate operations are
>> Gatherer-based, and all terminal operations are Collector-based, it would
>> just work as expected. But with that said, I'm not sure it is practically
>> achievable because some operations might not have the same
>> performance-characteristics as before.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 18:32
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Thanks for the workaround. It's running beautifully.
>>
>> Is there a future where this island concept is extended to the rest of
>> streams? Tbh, I don't fully understand it.
>>
>> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Hi David,
>>
>> This is the effect of how parallel streams are implemented, where
>> different stages, which are not representible as a join-less Spliterator
>> are executed as a series of "islands" where the next isn't started until
>> the former has completed.
>>
>> If you think about it, parallelization of a Stream works best when the
>> entire data set can be split amongst a set of worker threads, and that sort
>> of implies that you want eager pre-fetch of data, so if your dataset does
>> not fit in memory, that is likely to lead to less desirable outcomes.
>>
>> What I was able to do for Gatherers is to implement "gather(?) +
>> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> immediately followed by a collect(?) is run in the same "island".
>>
>> So with that said, you could try something like the following:
>>
>> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
>> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> }
>>
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .collect(forEach(eachList -> println(eachList.getFirst())));
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David
>> Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 14:52
>> *To:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> elements
>>
>> And just to avoid the obvious question, I can hold about 30 batches in
>> memory before the Out of Memory error occurs. So this is not an issue of my
>> batch size being too high.
>>
>> But just to confirm, I set the batch size to 1, and it still ran into an
>> out of memory error. So I feel fairly confident saying that the Gatherer is
>> trying to grab all available data before sending any of it downstream.
>>
>> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> wrote:
>>
>> Hello Core Libs Dev Team,
>>
>> I was trying out Gatherers for a project at work, and ran into a rather
>> sad scenario.
>>
>> I need to process a large file in batches. Each batch is small enough that
>> I can hold it in memory, but I cannot hold the entire file (and thus, all
>> of the batches) in memory at once.
>>
>> Looking at the Gatherers API, I saw windowFixed and thought that it would
>> be a great match for my use case.
>>
>> However, when trying it out, I was disappointed to see that it ran out of
>> memory very quickly. Here is my attempt at using it.
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .forEach(eachList -> println(eachList.getFirst()))
>> ;
>>
>> As you can see, I am just splitting the file into batches, and printing
>> out the first of each batch. This is purely for example's sake, of course.
>> I had planned on building even more functionality on top of this, but I
>> couldn't even get past this example.
>>
>> But anyways, not even a single one of them printed out. Which leads me to
>> believe that it's pulling all of them in the Gatherer.
>>
>> I can get it to run successfully if I go sequentially, but not parallel.
>> Parallel gives me that out of memory error.
>>
>> Is there any way for me to be able to have the Gatherer NOT pull in
>> everything while still remaining parallel and unordered?
>>
>> Thank you for your time and help.
>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241114/6e0f0392/attachment-0001.htm>

From shade at openjdk.org  Thu Nov 14 09:57:43 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 09:57:43 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v5]
In-Reply-To: <_pAw4IZ-x4LEhieEzaEWps8-NQxXYY3y6y35R04yKFg=.1a46477f-038e-4a19-9005-d94317ef55d7@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <Sx6TLaIy-9yQTYMS-uMmZWkwMzPoy-hmhklUPi1yy6c=.fb28e679-af6d-4c56-a19d-f531b254d329@github.com>
 <_pAw4IZ-x4LEhieEzaEWps8-NQxXYY3y6y35R04yKFg=.1a46477f-038e-4a19-9005-d94317ef55d7@github.com>
Message-ID: <Y5flaKKhJfZgCX-JUg5DCPlVPxltIaTsAQfCGc5EXtU=.d99646e7-ce23-4674-a5ed-df6bf2d743ea@github.com>

On Thu, 14 Nov 2024 00:50:51 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback: make sure trimming actually works, stylistic changes
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 236:
> 
>> 234:     static final class PhantomCleanableList {
>> 235:         private static final int MIN_CAPACITY = 16;
>> 236:         private final Object lock = new Object();
> 
> Why use another lock object when identity of this list is not escaped elsewhere?

Mostly hygiene for not exposing the lock to external classes. But yeah, we can simplify by just doing `synchronized`. I'll push the update soon.

> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 311:
> 
>> 309:                 // want to cause an immediate resize on next insertion.
>> 310:                 if ((size < arr.length / 4) && (size > MIN_CAPACITY)) {
>> 311:                     int newLen = ArraysSupport.newLength(size, 1, size);
> 
> This code isn't immediately clear that it's trying to half the array size, as you are using the size computation method for array growth.  Can you add a remark for so?

None of this is actually needed once we do smarter thing than relying on array resizes (and copies). I'll push new implementation soon.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841897671
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841899531

From shade at openjdk.org  Thu Nov 14 10:04:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 10:04:04 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v6]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <GohujhoWhH3zrdOrclUW19nVHbPl4J9dB8UCbT7KSNU=.6b038ee7-dff7-474c-9938-64eebb588da9@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with the `ArrayList` wrapper that manages synchronization, search and replacements efficiently. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Reimplement with segmented linked list of arrays

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/d4a03d85..cf3a93b8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=04-05

  Stats: 102 lines in 2 files changed: 40 ins; 23 del; 39 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Thu Nov 14 10:04:04 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 10:04:04 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <k0s5nWTBudBW0HYAlqPnWy-zXKIeFu4aaKXWwF7GOZE=.3737e4f3-81bd-4604-bf37-861df29043c7@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
 <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
 <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>
 <k0s5nWTBudBW0HYAlqPnWy-zXKIeFu4aaKXWwF7GOZE=.3737e4f3-81bd-4604-bf37-861df29043c7@github.com>
Message-ID: <_8tJj0lTY7DTBd_M4vZxFAdGL5ekCc5DmrSq3fq3078=.35798b85-c920-4cfd-a52b-ff9e8e9ec2b5@github.com>

On Thu, 14 Nov 2024 00:30:27 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> I pushed the array-based implementation, but ran out of time to properly test it. I'll circle back to it tomorrow. Review if you can, but it will probably have some touchups later.
>
> Speaking of testing, with this level of change, perhaps a new (white box?) regtest is warranted.

I see that existing `Cleaner` tests are quite rich already. Array-based implementation does rise question about testing the resizes, that's obvious. But I have discovered that copying arrays is not really that good in this scenario which balloons cleaner lists and shrinks them rapidly in our reproducers. So I have reimplemented the whole thing as the linked list of arrays, which makes capacity management code much less problematic. The new asserts around that code should IMO test enough with existing tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1841914579

From pminborg at openjdk.org  Thu Nov 14 10:09:34 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 14 Nov 2024 10:09:34 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <9Lke5h9iGZnEavl4k2VHwfh0oL2unmcdLIKcacn7cyI=.4596ad3b-4dd2-4ad4-aec6-ee9b23328681@github.com>

On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

While `jdk.internal.misc.Unsafe` is an internal class, it is used in many third-party libraries and applications. It would be interesting to run a _corpus analysis_ on how the proposed changes would impact existing code. I wonder if a CSR would be prudent here despite `Unsafe` being an internal class?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2475920098

From jpai at openjdk.org  Thu Nov 14 10:47:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Nov 2024 10:47:12 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader
 and related classes
In-Reply-To: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
Message-ID: <X_Qq8ss_5X-8TpJ5kU4q2OkinnEXAPKlqsOF8ZRm3VM=.b0016729-2ea8-4312-a3ab-219a8f08a3b7@github.com>

On Thu, 14 Nov 2024 09:00:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
> 
> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.

src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 296:

> 294:             }
> 295:         } else {
> 296:             URL url = findResource(name);

Hello Alan, before the change in this PR, when the module name `mn` was `null`, we used to call `findResource(mn, name)` (on previously line number 298). The `findResource(String, String)` would then effectively end up calling `findResourceOnClassPath(name)` without doing anything more. 

With this change, we now call `findResource(String)` when module name is `null`. The implementation of `findResource(String)` has additional code which does resource's package name to module mapping and few other things before it can decide whether `findResourceOnClassPath(String)` needs to be called for this resource name. 

Should the change on this line instead have been `findResource(null, name)`?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22097#discussion_r1842001221

From jpai at openjdk.org  Thu Nov 14 10:54:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Nov 2024 10:54:47 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader
 and related classes
In-Reply-To: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
Message-ID: <6m5xMihRJUhNgF85-LfS0pLuuymH722aeV1S0029-9U=.6b56d56d-e122-4f4f-a38a-8f1ed25576f4@github.com>

On Thu, 14 Nov 2024 09:00:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
> 
> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.

BootLoader.java and BuiltinClassLoader.java are missing a copyright year update.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22097#issuecomment-2476026277

From rgiulietti at openjdk.org  Thu Nov 14 10:54:52 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 14 Nov 2024 10:54:52 GMT
Subject: RFR: 8342693: Use byte[] as parameter in a FDBigInteger
 constructor and as field
In-Reply-To: <OSHvk1om1LqpXFZ2TAtRE2K7CaEcH1V-XkdM3pjYbX0=.b555fb19-42d1-42de-b6db-5d5fa5e5eb5b@github.com>
References: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>
 <OSHvk1om1LqpXFZ2TAtRE2K7CaEcH1V-XkdM3pjYbX0=.b555fb19-42d1-42de-b6db-5d5fa5e5eb5b@github.com>
Message-ID: <cN5RXai2ttWbqcOQpZrHSEG4sM2IVvLMBY5n0cbNMqU=.d1be8f7b-a42b-4fcd-bd61-d4173cef5383@github.com>

On Thu, 7 Nov 2024 06:32:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> This helps in reducing memory consumption, especially for long inputs.
>
> src/java.base/share/classes/jdk/internal/math/FloatingDecimal.java line 1875:
> 
>> 1873:             }  // look for and process decimal floating-point string
>> 1874: 
>> 1875:             byte[] digits = new byte[ len ];
> 
> Suggestion:
> 
>             byte[] digits = new byte[len];

@turbanoff I'll apply your suggestions later, in [PR 21840](https://github.com/openjdk/jdk/pull/21840)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21614#discussion_r1842008188

From rgiulietti at openjdk.org  Thu Nov 14 10:54:53 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 14 Nov 2024 10:54:53 GMT
Subject: Integrated: 8342693: Use byte[] as parameter in a FDBigInteger
 constructor and as field
In-Reply-To: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>
References: <gzOKfNXTQsz4DJbzP-0egyolmftcZ7zurKuy7eEjzfE=.c2251e8d-0496-4946-8c9c-22b88d5132dd@github.com>
Message-ID: <jZUxYAQ9kibJ_RQLxA6zAsE7wsb4KB1MxFEN57fmgdM=.0908226d-c8c0-4369-bf0f-aa573be35554@github.com>

On Mon, 21 Oct 2024 14:25:06 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> This helps in reducing memory consumption, especially for long inputs.

This pull request has now been integrated.

Changeset: 8523880f
Author:    Raffaello Giulietti <rgiulietti at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8523880f065efc8e0e527ddf2f14743fc0185593
Stats:     13 lines in 3 files changed: 0 ins; 0 del; 13 mod

8342693: Use byte[] as parameter in a FDBigInteger constructor and as field

Reviewed-by: darcy

-------------

PR: https://git.openjdk.org/jdk/pull/21614

From alanb at openjdk.org  Thu Nov 14 11:01:09 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 11:01:09 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader
 and related classes
In-Reply-To: <X_Qq8ss_5X-8TpJ5kU4q2OkinnEXAPKlqsOF8ZRm3VM=.b0016729-2ea8-4312-a3ab-219a8f08a3b7@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
 <X_Qq8ss_5X-8TpJ5kU4q2OkinnEXAPKlqsOF8ZRm3VM=.b0016729-2ea8-4312-a3ab-219a8f08a3b7@github.com>
Message-ID: <DoIXamFbKtD-z22g_sF9vu6lBtiuCFNLDrTA43ff3Hs=.f382f1ee-0b65-4af7-a021-29563e90f094@github.com>

On Thu, 14 Nov 2024 10:44:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
>> 
>> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.
>
> src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 296:
> 
>> 294:             }
>> 295:         } else {
>> 296:             URL url = findResource(name);
> 
> Hello Alan, before the change in this PR, when the module name `mn` was `null`, we used to call `findResource(mn, name)` (on previously line number 298). The `findResource(String, String)` would then effectively end up calling `findResourceOnClassPath(name)` without doing anything more. 
> 
> With this change, we now call `findResource(String)` when module name is `null`. The implementation of `findResource(String)` has additional code which does resource's package name to module mapping and few other things before it can decide whether `findResourceOnClassPath(String)` needs to be called for this resource name. 
> 
> Should the change on this line instead have been `findResource(null, name)`?

The change was deliberate but you are right that when we know we are looking for a resource on the class path that it would be better to stick with findResource(null, name).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22097#discussion_r1842021462

From ihse at openjdk.org  Thu Nov 14 11:11:54 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 11:11:54 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Fix CheckManPageOptions test
 - Remove classpath exception

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22081/files
  - new: https://git.openjdk.org/jdk/pull/22081/files/ffb41ba0..a8d4ea50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=00-01

  Stats: 106 lines in 36 files changed: 0 ins; 70 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/22081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081

PR: https://git.openjdk.org/jdk/pull/22081

From ihse at openjdk.org  Thu Nov 14 11:12:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 11:12:52 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <QyBh2MR7GEWc2oQ3NimEgV8rHcbvbLEoOK_vAwVaMjo=.2fc260cc-25c2-47fd-8bc1-57d0f45e7d62@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <ZLu8_dld82FRJWl9AYY_4d8oRvBl1G0uPk6VG-QmEdc=.4175dfca-a423-4296-a24c-069ce3264dc0@github.com>
 <QyBh2MR7GEWc2oQ3NimEgV8rHcbvbLEoOK_vAwVaMjo=.2fc260cc-25c2-47fd-8bc1-57d0f45e7d62@github.com>
Message-ID: <Y-yOZblThvBgNy5r1E59_WVTTgFIunkj4KdvlR3Aq7M=.cbfd247a-a955-482c-a150-621a0f683637@github.com>

On Wed, 13 Nov 2024 21:55:53 GMT, Iris Clark <iris at openjdk.org> wrote:

>> src/java.base/share/man/java.md line 9:
>> 
>>> 7: # published by the Free Software Foundation.  Oracle designates this
>>> 8: # particular file as subject to the "Classpath" exception as provided
>>> 9: # by Oracle in the LICENSE file that accompanied this code.
>> 
>> Documentation files should not have the Classpath exception.
>> 
>> make/data/license-templates/gpl-header
>
> Agree.

Yeah, sorry for that, and thanks for catching it. 

I just copied the header from a build file, since it was conveniently already formatted with the leading `#`. I just assumed that this was the pure GPL and did not check close enough to verify. But it turns out that most of the build system files actually have the classpath exception, which makes no sense. 

I've filed https://bugs.openjdk.org/browse/JDK-8344191 to deal with that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1842039722

From alanb at openjdk.org  Thu Nov 14 11:25:08 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 11:25:08 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader
 and related classes [v2]
In-Reply-To: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
Message-ID: <Yzup9r6TYApQey2FJtWTUVJvOKNdsnX5FhUrSQmSvJE=.c5ea09f3-6daa-49fc-a2e8-4cbe4677ac08@github.com>

> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
> 
> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:

 - Change 2-arg findResource to use findResourceOnClassPath when finding resources on class path
 - Merge branch 'master' into JDK-8343982
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22097/files
  - new: https://git.openjdk.org/jdk/pull/22097/files/dd2db35b..742fe89c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22097&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22097&range=00-01

  Stats: 525 lines in 30 files changed: 435 ins; 19 del; 71 mod
  Patch: https://git.openjdk.org/jdk/pull/22097.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22097/head:pull/22097

PR: https://git.openjdk.org/jdk/pull/22097

From eirbjo at openjdk.org  Thu Nov 14 11:29:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 11:29:06 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
Message-ID: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>

Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:

* `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
*  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
* `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`

The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately.

Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.

-------------

Commit messages:
 - Cleanup SM-dependent code in ZIP and JAR areas

Changes: https://git.openjdk.org/jdk/pull/22099/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22099&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344179
  Stats: 17 lines in 3 files changed: 0 ins; 12 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22099.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22099/head:pull/22099

PR: https://git.openjdk.org/jdk/pull/22099

From eirbjo at openjdk.org  Thu Nov 14 11:29:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 11:29:41 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
Message-ID: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>

Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.

* `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
* `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
*  The test `TestPosix` is updated to perform `AccessController.doPrivileged`

This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.

Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

-------------

Commit messages:
 - Cleanup SM-dependent code in the ZipFs area

Changes: https://git.openjdk.org/jdk/pull/22101/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22101&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344183
  Stats: 80 lines in 3 files changed: 3 ins; 53 del; 24 mod
  Patch: https://git.openjdk.org/jdk/pull/22101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22101/head:pull/22101

PR: https://git.openjdk.org/jdk/pull/22101

From jpai at openjdk.org  Thu Nov 14 11:32:42 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Nov 2024 11:32:42 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader
 and related classes [v2]
In-Reply-To: <Yzup9r6TYApQey2FJtWTUVJvOKNdsnX5FhUrSQmSvJE=.c5ea09f3-6daa-49fc-a2e8-4cbe4677ac08@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
 <Yzup9r6TYApQey2FJtWTUVJvOKNdsnX5FhUrSQmSvJE=.c5ea09f3-6daa-49fc-a2e8-4cbe4677ac08@github.com>
Message-ID: <jXOdDl21BsjhXliNVL3r72VKMwOe8TVwOrw3Hp0koBw=.fda25ddd-c7e6-48b3-be98-fae90fd34123@github.com>

On Thu, 14 Nov 2024 11:25:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
>> 
>> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Change 2-arg findResource to use findResourceOnClassPath when finding resources on class path
>  - Merge branch 'master' into JDK-8343982
>  - Initial commit

The update to use `findResourceOnClassPath()` and the rest of the changes in this PR look good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22097#pullrequestreview-2435825047

From jlahoda at openjdk.org  Thu Nov 14 11:36:06 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Thu, 14 Nov 2024 11:36:06 GMT
Subject: Integrated: 8335991: Implement Simple Source Files and Instance Main
 Methods (Fourth Preview)
In-Reply-To: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
References: <BD_7_vcsdshFyuzsuZ39CuxpIRI1f3z38lzNhcbGxlg=.8ed21d5f-2f36-4659-a0eb-0c97af292352@github.com>
Message-ID: <NtcwESgpSWeYWM_vBDkzBdAzwc9E-hq2pbRPgbvt1pA=.cc28b23c-f42b-4c3f-a914-dcc5b12385b5@github.com>

On Wed, 30 Oct 2024 13:01:29 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

> This is a partial implementation of JEP 495 - adjustments of the JEP metadata in `PreviewFeature`. There are no language changes associated with this JEP. Changes to the `java.io.IO` class are covered by https://github.com/openjdk/jdk/pull/21693.

This pull request has now been integrated.

Changeset: 5731ab7f
Author:    Jan Lahoda <jlahoda at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5731ab7fed22391e1dea777f6d76b7e75ccf5084
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8335991: Implement Simple Source Files and Instance Main Methods (Fourth Preview)

Reviewed-by: asotona, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/21787

From davidalayachew at gmail.com  Thu Nov 14 11:36:59 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 14 Nov 2024 06:36:59 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>

Then let me correct myself again, while simplifying -- I just want that
detail, that certain combinations might lead to pre-fetching everything, to
be documented on the stream api. Package level, or on the Stream interface
itself, seems like a good spot.

On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> The issue here is that the operation cannot advertise this, as it depends
> on the combination of operations.
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Wednesday, 13 November 2024 14:07
> *To:* Rob Spoor <openjdk at icemanx.nl>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> That is a good point Rob.
>
> Then let me correct myself -- I think the terminal operations don't do a
> great job of advertising whether or not they pre-fetch everything when
> parallelism is activated. Collector fetches as needed. FindAny pre-fetches
> everything. I understand that later releases might change their behaviour,
> but I still want to document the current behaviour in the official javadocs
> so that we can limit undocumented tripping hazards.
>
>
> On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl> wrote:
>
> distinct() doesn't require everything to be pulled. It can push elements
> to the downstream as they come along for the first time. When
> downstream.push returns false the gatherer is done.
>
> As part of some experimentation I've implemented all intermediary
> operations using gatherers. Most of them are pretty straightforward and
> will stop integrating once the downstream starts rejecting elements
> (although some use Gatherer.ofSequential to keep it easy). I only found
> two exceptions that don't return the result of downstream.push:
>
> * mapMulti. The downstream.push is passed as the mapper which is a
> Consumer - the return value is ignored. With some more effort it's
> probably possible to capture any false return value and return that from
> the integrator, but I haven't tried that yet.
>
> * sorted. Obviously every element needs to be inspected.
>
>
> On 13/11/2024 00:37, David Alayachew wrote:
> > Oh sure, I expect something like distinct() to pull everything. In order
> to
> > know if something is distinct, you have to do some variant of "check
> > against everyone else". Whether that is holding all instances in memory
> or
> > their hashes, it's clear from a glance that you will need to look at
> > everything, and therefore, pre-fetching makes intuitive sense to me.
> >
> > I 100% did not expect terminal operations like findAny() or reduce() to
> > pull the whole data set. That was a complete whiplash for me. The method
> > findAny() advertises itself as a short-circuiting operation, so to find
> out
> > that it actually pulls the whole data set anyways was shocking.
> >
> > And that was my biggest pain point -- looking at the documentation, it is
> > not clear to me at all that methods like findAny() would pull in all data
> > upon becoming parallel().
> >
> > Do you think it would make sense to add documentation about this to the
> > javadocs for Stream/java.util.stream? Or maybe it is already there and I
> > misunderstood it (even after reading through it thoroughly over 5 times).
> >
> >
> > On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
> >
> >>> We are told how Streams can process unbounded data sets, but when it
> >> tries to do a findAny() with parallel(), it runs into an OOME because it
> >> fetched all the data ahead of time. In fact, almost of the terminal
> >> operations will hit an OOME in the exact same way if they are parallel
> and
> >> have a big enough data set. It's definitely not the end of the world,
> but
> >> it seems that I have to fit everything into a Collector and/or a
> Gatherer
> >> if I want to avoid pre-fetching everything.
> >>
> >> Yeah, I think it is important to distinguish "can process unbounded data
> >> sets" from "always able to process unbounded data sets".
> >>
> >> Some operations inherently need the end of the stream, so even something
> >> somple like: stream.distinct() or stream.sorted() can end up pulling in
> all
> >> data (which of course won't terminate).
> >>
> >> Fortunately, I think Gatherers can unlock much more situations where
> >> unbounded streams can be processed.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 15:08
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Oh woah. I certainly did not. Or rather, I had dismissed the idea as
> soon
> >> as I thought of it.
> >>
> >>
> >> I hand-waved away the idea because I thought that the method would turn
> >> the stream pipeline parallel, thus, recreating the same problem I
> currently
> >> have of parallelism causing all of the elements to be fetched ahead of
> >> time, causing an OOME.
> >>
> >>
> >> It did NOT occur to me that the pipeline would stay sequential, and just
> >> kick these off sequentially, but have them executing in parallel. I
> can't
> >> see why I came to that incorrect conclusion. I have read the javadocs of
> >> this method several times. Though, to be fair, I came to the same,
> >> incorrect conclusion about Collectors.groupingByConcurrent(), and it
> wasn't
> >> until someone pointed out what the documentation was actually saying
> that I
> >> realized it's true properties.
> >>
> >> Thanks. That definitely solves at least part of my problem. Obviously, I
> >> would prefer to write to S3 in parallel too, but at the very least, the
> >> calculation part is being done in parallel. And worst case scenario, I
> can
> >> be really bad and just do the write to S3 in the mapConcurrent, and then
> >> just return the metadata of each write, and just bundle that up with
> >> collect.
> >>
> >>
> >> And that's ignoring the fact that I can just use the workaround too.
> >>
> >>
> >> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
> >> from a performance perspective, but is rather unintuitive to me from a
> >> usability perspective. We are told how Streams can process unbounded
> data
> >> sets, but when it tries to do a findAny() with parallel(), it runs into
> an
> >> OOME because it fetched all the data ahead of time. In fact, almost of
> the
> >> terminal operations will hit an OOME in the exact same way if they are
> >> parallel and have a big enough data set. It's definitely not the end of
> the
> >> world, but it seems that I have to fit everything into a Collector
> and/or a
> >> Gatherer if I want to avoid pre-fetching everything.
> >>
> >> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Have you considered Gatherers.mapConcurrent(?)?
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 01:53
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >> Good to know, ty vm.
> >>
> >> At the very least, I have this workaround. This will meet my needs for
> now.
> >>
> >> I guess my final question would be -- is this type of problem better
> >> suited to something besides parallel streams? Maybe an ExecutorService?
> >>
> >> Really, all I am doing is taking a jumbo file, splitting it into
> batches,
> >> and then doing some work on those batches. My IO speeds are pretty fast,
> >> and the compute work is non-trivial, so there is performance being left
> on
> >> the table if I give up parallelism. And I am in a position where
> completion
> >> time is very important to us.
> >>
> >> I just naturally assumed parallel streams were the right choice because
> >> the compute work is simple. A pure function that I can break out, and
> then
> >> call in a map. Once I do that, I just call forEach to write the batches
> >> back out to S3. Maybe I should look into a different part of the std lib
> >> instead because I am using the wrong tool for the job? My nose says
> >> ExecutorService, but I figure I should ask before I dive too deep in.
> >>
> >>
> >> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> You're most welcome!
> >>
> >> In a potential future where all intermediate operations are
> >> Gatherer-based, and all terminal operations are Collector-based, it
> would
> >> just work as expected. But with that said, I'm not sure it is
> practically
> >> achievable because some operations might not have the same
> >> performance-characteristics as before.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 18:32
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Thanks for the workaround. It's running beautifully.
> >>
> >> Is there a future where this island concept is extended to the rest of
> >> streams? Tbh, I don't fully understand it.
> >>
> >> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Hi David,
> >>
> >> This is the effect of how parallel streams are implemented, where
> >> different stages, which are not representible as a join-less Spliterator
> >> are executed as a series of "islands" where the next isn't started until
> >> the former has completed.
> >>
> >> If you think about it, parallelization of a Stream works best when the
> >> entire data set can be split amongst a set of worker threads, and that
> sort
> >> of implies that you want eager pre-fetch of data, so if your dataset
> does
> >> not fit in memory, that is likely to lead to less desirable outcomes.
> >>
> >> What I was able to do for Gatherers is to implement "gather(?) +
> >> collect(?)"-fusion so any number of consecutive gather(?)-operations
> >> immediately followed by a collect(?) is run in the same "island".
> >>
> >> So with that said, you could try something like the following:
> >>
> >> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T>
> *each*) {
> >>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e),
> (*l*,
> >> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> >> }
> >>
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .collect(forEach(eachList -> println(eachList.getFirst())));
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> David
> >> Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 14:52
> >> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> >> elements
> >>
> >> And just to avoid the obvious question, I can hold about 30 batches in
> >> memory before the Out of Memory error occurs. So this is not an issue
> of my
> >> batch size being too high.
> >>
> >> But just to confirm, I set the batch size to 1, and it still ran into an
> >> out of memory error. So I feel fairly confident saying that the
> Gatherer is
> >> trying to grab all available data before sending any of it downstream.
> >>
> >> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com
> >
> >> wrote:
> >>
> >> Hello Core Libs Dev Team,
> >>
> >> I was trying out Gatherers for a project at work, and ran into a rather
> >> sad scenario.
> >>
> >> I need to process a large file in batches. Each batch is small enough
> that
> >> I can hold it in memory, but I cannot hold the entire file (and thus,
> all
> >> of the batches) in memory at once.
> >>
> >> Looking at the Gatherers API, I saw windowFixed and thought that it
> would
> >> be a great match for my use case.
> >>
> >> However, when trying it out, I was disappointed to see that it ran out
> of
> >> memory very quickly. Here is my attempt at using it.
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .forEach(eachList -> println(eachList.getFirst()))
> >> ;
> >>
> >> As you can see, I am just splitting the file into batches, and printing
> >> out the first of each batch. This is purely for example's sake, of
> course.
> >> I had planned on building even more functionality on top of this, but I
> >> couldn't even get past this example.
> >>
> >> But anyways, not even a single one of them printed out. Which leads me
> to
> >> believe that it's pulling all of them in the Gatherer.
> >>
> >> I can get it to run successfully if I go sequentially, but not parallel.
> >> Parallel gives me that out of memory error.
> >>
> >> Is there any way for me to be able to have the Gatherer NOT pull in
> >> everything while still remaining parallel and unordered?
> >>
> >> Thank you for your time and help.
> >> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241114/344cdebc/attachment-0001.htm>

From ogillespie at openjdk.org  Thu Nov 14 11:53:25 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 14 Nov 2024 11:53:25 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v6]
In-Reply-To: <GohujhoWhH3zrdOrclUW19nVHbPl4J9dB8UCbT7KSNU=.6b038ee7-dff7-474c-9938-64eebb588da9@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <GohujhoWhH3zrdOrclUW19nVHbPl4J9dB8UCbT7KSNU=.6b038ee7-dff7-474c-9938-64eebb588da9@github.com>
Message-ID: <sopWs4DaSqKTrutr2uZkqbeaaTMBGgj-tiiFkADvdlM=.ca815eef-4b6d-4ff7-a1ad-50e52b4d0866@github.com>

On Thu, 14 Nov 2024 10:04:04 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Reimplement with segmented linked list of arrays

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 310:

> 308:                Node newHead = head.next;
> 309:                newHead.prev = null;
> 310:                head = newHead;

Does this allow removing the final head node when the list is empty? Seems we need to avoid that (`if (head.size == 0 && head.next != null)`?.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1842091029

From alanb at openjdk.org  Thu Nov 14 12:02:15 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 12:02:15 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v7]
In-Reply-To: <pRF9JYoj9GYXU3_8zuTotAIzd-6AWl6ECYCRGCtVrsU=.655e2d40-3e7b-4ce1-9927-716b7b8f9d96@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <pRF9JYoj9GYXU3_8zuTotAIzd-6AWl6ECYCRGCtVrsU=.655e2d40-3e7b-4ce1-9927-716b7b8f9d96@github.com>
Message-ID: <k5byHEo6WqCFq7_EWPX_C_YjVDerdtfFWox2TbDa7F4=.ae3a3d89-418d-4837-8bb7-a8bd435d3942@github.com>

On Wed, 13 Nov 2024 21:39:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Remove failing getDeclaredField call from test java/lang/ProcessBuilder/Basic.java

I've changed the PR to require at least two reviewers as I think the changes could benefit from a second reviewer.

src/java.base/share/classes/java/io/BufferedOutputStream.java line 89:

> 87: 
> 88:         if (getClass() == BufferedOutputStream.class) {
> 89:             // resizable if initialSize < maxSize

I think the comment is confusing, can it just say resizable when not sub-classed as it did previously?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2476163286
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1842102399

From alanb at openjdk.org  Thu Nov 14 12:13:30 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 12:13:30 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v7]
In-Reply-To: <pRF9JYoj9GYXU3_8zuTotAIzd-6AWl6ECYCRGCtVrsU=.655e2d40-3e7b-4ce1-9927-716b7b8f9d96@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <pRF9JYoj9GYXU3_8zuTotAIzd-6AWl6ECYCRGCtVrsU=.655e2d40-3e7b-4ce1-9927-716b7b8f9d96@github.com>
Message-ID: <nV9Tt0ufP3r4sTz3asCTHEobW5N_YpHfL_OaQUZVezE=.04617156-eb32-4ad8-ae39-f856d00131e8@github.com>

On Wed, 13 Nov 2024 21:39:54 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Remove failing getDeclaredField call from test java/lang/ProcessBuilder/Basic.java

I did another pass over this and don't see any issues except the confusing comment in the BOS constructor.  Overall good cleanup as InternalLock was a temporary crutch to avoid pinning in the java.io area for common usages.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22048#pullrequestreview-2435909813

From alanb at openjdk.org  Thu Nov 14 12:23:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 12:23:13 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
In-Reply-To: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
Message-ID: <Jguh6wJO_MB9uUvAwZTaMFDd1OH6QluT1jqB2uE6rkE=.b5a91e27-be1b-42dc-b0c5-ef579376eb3e@github.com>

On Thu, 14 Nov 2024 10:18:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
> 
> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
> 
> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
> 
> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.

This looks okay to me. It's likely that others may wish to review this too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22099#issuecomment-2476215902

From ihse at openjdk.org  Thu Nov 14 12:28:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 12:28:23 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
Message-ID: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>

In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 

I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.

The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.

This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

-------------

Commit messages:
 - Update build tools, data and IDE support
 - Update makefiles, autoconf, shell scripts, properties files and configuration files

Changes: https://git.openjdk.org/jdk/pull/22104/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22104&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344191
  Stats: 2054 lines in 555 files changed: 0 ins; 1118 del; 936 mod
  Patch: https://git.openjdk.org/jdk/pull/22104.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22104/head:pull/22104

PR: https://git.openjdk.org/jdk/pull/22104

From cstein at openjdk.org  Thu Nov 14 12:31:46 2024
From: cstein at openjdk.org (Christian Stein)
Date: Thu, 14 Nov 2024 12:31:46 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <B5wPJ1nOlZ8FqUq_BanQIjs_CFKZPbhmTHd_MwKHnYk=.4e63cd9e-02be-4e45-b79c-bc325ccd75e5@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). A candidate for an ignore list as fixing it is out of scope of this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476233883

From jpai at openjdk.org  Thu Nov 14 12:31:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Nov 2024 12:31:47 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <45vdxLi7glsU82ec1dPxT-FEfrJVxAWliwOQ_-sGKko=.8795c8d8-c690-4df1-a98e-47fe44e32429@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
 <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
 <HaROiuwLaPbPqU0yCkjrF_sErOyFu9SmyJ2Kz7mq1rw=.5dcd201b-6fe4-4c2b-a4c1-d9598bbdf641@github.com>
 <45vdxLi7glsU82ec1dPxT-FEfrJVxAWliwOQ_-sGKko=.8795c8d8-c690-4df1-a98e-47fe44e32429@github.com>
Message-ID: <_CPEGrm4gbzEuIVwTRde89XK1U7swqb-qCFf8l_RWyc=.6078e00c-4f3f-4925-8052-ba4d6a07919c@github.com>

On Thu, 14 Nov 2024 04:59:48 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hello Roger, I think that's a good idea. At least until there is a real reason for `close()` to be overridden by subclasses. I went back and checked the mailing list discussions (linked in this PR description) and I don't think marking `close()` as `final` has been suggested or rejected before. I will give others a chance to provide their inputs before I do this change.
>
> I agree with marking these close methods as final as long as the previous corpus search did not find any user-defined close method in subclasses.

Hello Chen, corpus analysis shows that there are no subclasses of Inflater/Deflater which have a `close()` method.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1842137395

From asemenyuk at openjdk.org  Thu Nov 14 12:39:47 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Nov 2024 12:39:47 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib
Message-ID: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>

Make jpackage test lib more practical. List of changes:

Support multiple args and var args in `@Parameter` annotation:

@Test
@Parameter({"12", "foo"})
@Parameter({"-89", "bar", "more"})
@Parameter({"-89", "bar", "more", "moore"})
public void testVarArg(int a, String b, String ... other) {}


Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:

class FooTest {
    public FooTest(String... args) {}
    public FooTest(int o) {}
    public FooTest(int a, Boolean[] b, String c, String ... other) {}

    @Parameters
    public static Collection<Object[]> input() {
        return List.of(new Object[][] {
            {},
            {"str"},
            {55, new Boolean[]{false, true, false}, "foo", "bar"},
        });
    }

    @Parameters
    public static Collection<Object[]> input2() {
        return List.of(new Object[][] {
            {78},
            {34, null, null},
        });
    }
}


Static test method will be executed only once and not as many times as the number of the test class instances.

Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:


class FooTest {
    @Test
    @ParameterSupplier("dateSupplier")
    @ParameterSupplier("AnotherClass.dateSupplier")
    public void testDates(LocalDate v) {}

    public static Collection<Object[]> dateSupplier() {
        return List.of(new Object[][] {
            { LocalDate.parse("2018-05-05") },
            { LocalDate.parse("2018-07-11") },
        });
    }
}

class AnotherClass {
    public static Collection<Object[]> dateSupplier() {
        return List.of(new Object[][] {
            { LocalDate.parse("2028-07-11") },
        });
    }
}


All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:


@Test(ifOS = OperatingSystem.LINUX)
public void testRunIfLinux() {}

@Test(ifNotOS = OperatingSystem.LINUX)
public void testRunIfNotLinux() {}

@Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
public void testRunIfNotLinuxOrMacOS() {}

@Test
@Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
@Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
@Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
@ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSystem.WINDOWS)
public void test(String ... args) {}

public static List<Object[]> getWindowsStrings() { ... }



class FooTest {
    public FooTest(int a, String b) {
        super(a, b);
    }

    @Parameters(ifOS = OperatingSystem.LINUX)
    public static Collection<Object[]> input() {
        return List.of(new Object[][] {
            {7, null},
        });
    }

    @Parameters(ifNotOS = {OperatingSystem.LINUX, OperatingSystem.MACOS})
    public static Collection<Object[]> input2() {
        return List.of(new Object[][] {
            {10, "hello"},
        });
    }
}


The test case description contains a fully qualified test class name instead of the short name earlier.

Added `JPackageCommand.validateOutput()` and adjusted `ErrorTest.java` to use it.

Tighten tests in `LinuxHelper`: if the jpackage command is not using an external app image it will test that all "*.desktop" files match app launchers of the app. Earlier it validated the contents of "*.desktop" files without relation to app launchers.

Add support for `@command` files to `Main.main()` method. 
E.g.: 


%> java ... Main.main @args.txt


will result in reading arguments from "args.txt" file. Arguments will be split at whitespaces and line breaks. If `@` is followed by `=`, arguments will be split at line breaks.

`InstallDirTest.java` and `InOutPath.java` tests updated to use new features. Other tests may be refactored later if appropriate.

-------------

Commit messages:
 - Minor cleanup
 - Merge branch 'master' into JDK-8343876
 - Use "validate" instead of "verify" for the new API
 - Don't run static test methods with test instances
 - Don't create intermediate set of expected test descs for very test class when building the total set of all test descs
 - Add test case to validate static test case will be executed only once in parameterized test
 - Full test class name in test case description
 - Use Comparator
 - Merge branch 'master' into JDK-8343876
 - - add test coverage to @Parameters.ifOS and @Parameters.ifNotOS.
 - ... and 23 more: https://git.openjdk.org/jdk/compare/95a00f8a...1c7e0592

Changes: https://git.openjdk.org/jdk/pull/21996/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343876
  Stats: 1889 lines in 17 files changed: 1515 ins; 208 del; 166 mod
  Patch: https://git.openjdk.org/jdk/pull/21996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21996/head:pull/21996

PR: https://git.openjdk.org/jdk/pull/21996

From rriggs at openjdk.org  Thu Nov 14 12:42:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 12:42:00 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
In-Reply-To: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
Message-ID: <-ZPca6O90gEy7qNw9ZlD2r1ns-DZ7hoj5vD_MRDi2Cw=.1bcfa300-55fd-460e-a0d3-943cae1c3d8f@github.com>

On Thu, 14 Nov 2024 10:18:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
> 
> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
> 
> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
> 
> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.

src/java.base/share/classes/java/util/jar/JarFile.java line 183:

> 181:         RUNTIME_VERSION = Runtime.Version.parse(Integer.toString(runtimeVersion));
> 182:         String enableMultiRelease = System.
> 183:                 getProperty("jdk.util.jar.enableMultiRelease", "true");

I'd fold this to a single line.

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 60:

> 58:      */
> 59:     private static final boolean inhibitZip64 =
> 60:         Boolean.getBoolean("jdk.util.zip.inhibitZip64");

fold to a single line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842150272
PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842150753

From ihse at openjdk.org  Thu Nov 14 12:44:45 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Thu, 14 Nov 2024 12:44:45 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <B5wPJ1nOlZ8FqUq_BanQIjs_CFKZPbhmTHd_MwKHnYk=.4e63cd9e-02be-4e45-b79c-bc325ccd75e5@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
 <B5wPJ1nOlZ8FqUq_BanQIjs_CFKZPbhmTHd_MwKHnYk=.4e63cd9e-02be-4e45-b79c-bc325ccd75e5@github.com>
Message-ID: <hGn-UQ8cj7rW04rBdwPSG7vy4_fy-L3GIw_IDz3CXvc=.cf326c7c-0f31-483c-939d-8e5193c1e609@github.com>

On Thu, 14 Nov 2024 12:29:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad). 

*sigh*

> A candidate for an ignore list as fixing it is out of scope of this PR?

Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2476258243

From mullan at openjdk.org  Thu Nov 14 12:54:58 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 12:54:58 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
In-Reply-To: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
Message-ID: <EKq2YDxiPgGng1PsXxdyHZTumFa_t9iqspDhsu_Z5JI=.2eb8260b-684b-4243-bf4a-71d116e90690@github.com>

On Thu, 14 Nov 2024 10:18:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
> 
> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
> 
> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
> 
> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.

Please don't integrate until I review this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22099#issuecomment-2476280047

From mcimadamore at openjdk.org  Thu Nov 14 12:58:20 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 12:58:20 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v16]
In-Reply-To: <GSUee2bqFC9HCLW4SMRt3tFkoPnjrLK0eV4xlQ-V6lI=.89739729-ef55-4f09-a46b-abf7432c2d2c@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <GSUee2bqFC9HCLW4SMRt3tFkoPnjrLK0eV4xlQ-V6lI=.89739729-ef55-4f09-a46b-abf7432c2d2c@github.com>
Message-ID: <k7AU3hlD-hDUClcZ4LQ3UzwoORrVFaONdYDa8yiFmiw=.20799cc8-b19a-4463-8229-3a1734e5f7f6@github.com>

On Wed, 13 Nov 2024 15:21:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failing test

src/java.base/share/classes/java/lang/foreign/Linker.java line 253:

> 251:  * <li>{@code L.byteAlignment()} is equal to the sequence layout's <em>natural alignment</em>
> 252:  *     , and</li>
> 253:  * <li>{@code S.elementLayout()} is a well-defined layout.</li>

Suggestion:

 * <li>{@code S.elementLayout()} is a well-formed layout.</li>

src/java.base/share/classes/java/lang/foreign/Linker.java line 261:

> 259:  * <li>{@code G.byteSize()} is a multiple of {@code G.byteAlignment()}</li>
> 260:  * <li>Each member layout in {@code G.memberLayouts()} is either a padding layout or a
> 261:  *     well-defined layout</li>

Suggestion:

 *     well-formed layout</li>

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1842174338
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1842175387

From mcimadamore at openjdk.org  Thu Nov 14 13:15:02 2024
From: mcimadamore at openjdk.org (Maurizio Cimadamore)
Date: Thu, 14 Nov 2024 13:15:02 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v16]
In-Reply-To: <GSUee2bqFC9HCLW4SMRt3tFkoPnjrLK0eV4xlQ-V6lI=.89739729-ef55-4f09-a46b-abf7432c2d2c@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <GSUee2bqFC9HCLW4SMRt3tFkoPnjrLK0eV4xlQ-V6lI=.89739729-ef55-4f09-a46b-abf7432c2d2c@github.com>
Message-ID: <hUkk50rSuEsDu79oTVi6hFNJPU9EVeI1EJf72TZZar8=.3299b3cd-5b4c-497a-b539-4adfe7d46383@github.com>

On Wed, 13 Nov 2024 15:21:24 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix failing test

src/java.base/share/classes/java/lang/foreign/Linker.java line 271:

> 269:  * </ul>
> 270:  * <p>
> 271:  * Well-formed layouts in function descriptions consumed by a native linker constitute

Let's simplify this, and make it more direct:


A function descriptors is well-formed if its argument and return layouts are well-formed and are not sequence layouts. A native linker is guaranteed to reject function descriptors that are not well-formed. However, a native linker can still reject well-formed function descriptors, according to platform-specific rules. For example, some native linkers may reject <em>packed</em> struct layouts -- struct layouts whose member layouts feature relaxed alignment constraints, to avoid the insertion of additional padding.


Let's skip the example -- we're not after a tutorial of what packed structs are or aren't. We're just making an example of a layout that, while being well-formed, might still not be accepted by all linkers.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1842199959

From eirbjo at openjdk.org  Thu Nov 14 13:21:33 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 13:21:33 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
Message-ID: <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>

> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
> 
> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
> 
> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
> 
> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22099/files
  - new: https://git.openjdk.org/jdk/pull/22099/files/42bee788..6a72b060

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22099&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22099&range=00-01

  Stats: 4 lines in 2 files changed: 0 ins; 2 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22099.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22099/head:pull/22099

PR: https://git.openjdk.org/jdk/pull/22099

From eirbjo at openjdk.org  Thu Nov 14 13:21:33 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 13:21:33 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <-ZPca6O90gEy7qNw9ZlD2r1ns-DZ7hoj5vD_MRDi2Cw=.1bcfa300-55fd-460e-a0d3-943cae1c3d8f@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <-ZPca6O90gEy7qNw9ZlD2r1ns-DZ7hoj5vD_MRDi2Cw=.1bcfa300-55fd-460e-a0d3-943cae1c3d8f@github.com>
Message-ID: <RK5jLqB_xP_bery0ioOGODqLwy6J3d7L8Pfc_jxjG8g=.fdd172e8-094e-459b-9baa-95adc3b93a55@github.com>

On Thu, 14 Nov 2024 12:37:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 183:
> 
>> 181:         RUNTIME_VERSION = Runtime.Version.parse(Integer.toString(runtimeVersion));
>> 182:         String enableMultiRelease = System.
>> 183:                 getProperty("jdk.util.jar.enableMultiRelease", "true");
> 
> I'd fold this to a single line.

Thanks, makes sense. This makes this line the fifth longest line in `JarFile.java`.

> src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 60:
> 
>> 58:      */
>> 59:     private static final boolean inhibitZip64 =
>> 60:         Boolean.getBoolean("jdk.util.zip.inhibitZip64");
> 
> fold to a single line.

Thanks, makes sense. This makes this line the longest line in `ZipOutputStream.java`, the next longest being one character shorer.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842207585
PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842207626

From duke at openjdk.org  Thu Nov 14 13:21:56 2024
From: duke at openjdk.org (ExE Boss)
Date: Thu, 14 Nov 2024 13:21:56 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v7]
In-Reply-To: <k5byHEo6WqCFq7_EWPX_C_YjVDerdtfFWox2TbDa7F4=.ae3a3d89-418d-4837-8bb7-a8bd435d3942@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <pRF9JYoj9GYXU3_8zuTotAIzd-6AWl6ECYCRGCtVrsU=.655e2d40-3e7b-4ce1-9927-716b7b8f9d96@github.com>
 <k5byHEo6WqCFq7_EWPX_C_YjVDerdtfFWox2TbDa7F4=.ae3a3d89-418d-4837-8bb7-a8bd435d3942@github.com>
Message-ID: <CpJWT9_Vu-7qO2EILCnqbK3BBNLGOk65rfVmkrSZfMI=.e5632c62-3082-41b3-9d5b-79cc47853334@github.com>

On Thu, 14 Nov 2024 11:59:47 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8343039: Remove failing getDeclaredField call from test java/lang/ProcessBuilder/Basic.java
>
> src/java.base/share/classes/java/io/BufferedOutputStream.java line 89:
> 
>> 87: 
>> 88:         if (getClass() == BufferedOutputStream.class) {
>> 89:             // resizable if initialSize < maxSize
> 
> I think the comment is confusing, can it just say resizable when not sub-classed as it did previously?

Suggestion:

            // resizable when not sub-classed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1842207003

From shade at openjdk.org  Thu Nov 14 13:24:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 13:24:26 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Avoid NPE on empty list, add tests, touchups

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/cf3a93b8..c511c9bb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=05-06

  Stats: 251 lines in 5 files changed: 241 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Thu Nov 14 13:24:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 13:24:26 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <_8tJj0lTY7DTBd_M4vZxFAdGL5ekCc5DmrSq3fq3078=.35798b85-c920-4cfd-a52b-ff9e8e9ec2b5@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
 <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
 <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>
 <k0s5nWTBudBW0HYAlqPnWy-zXKIeFu4aaKXWwF7GOZE=.3737e4f3-81bd-4604-bf37-861df29043c7@github.com>
 <_8tJj0lTY7DTBd_M4vZxFAdGL5ekCc5DmrSq3fq3078=.35798b85-c920-4cfd-a52b-ff9e8e9ec2b5@github.com>
Message-ID: <j1ATGzp3JUUnpEzTq-gpIcznZS2TMz_qNGC2Dm9uEs4=.ce7b8b68-ff84-4b6d-93f5-25be822a93cd@github.com>

On Thu, 14 Nov 2024 10:00:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Speaking of testing, with this level of change, perhaps a new (white box?) regtest is warranted.
>
> I see that existing `Cleaner` tests are quite rich already. Array-based implementation does rise question about testing the resizes, that's obvious. But I have discovered that copying arrays is not really that good in this scenario which balloons cleaner lists and shrinks them rapidly in our reproducers. So I have reimplemented the whole thing as the linked list of arrays, which makes capacity management code much less problematic. The new asserts around that code should IMO test enough with existing tests.

Nevermind, I added a directed regression test for it now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1842210127

From shade at openjdk.org  Thu Nov 14 13:24:26 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 13:24:26 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v6]
In-Reply-To: <sopWs4DaSqKTrutr2uZkqbeaaTMBGgj-tiiFkADvdlM=.ca815eef-4b6d-4ff7-a1ad-50e52b4d0866@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <GohujhoWhH3zrdOrclUW19nVHbPl4J9dB8UCbT7KSNU=.6b038ee7-dff7-474c-9938-64eebb588da9@github.com>
 <sopWs4DaSqKTrutr2uZkqbeaaTMBGgj-tiiFkADvdlM=.ca815eef-4b6d-4ff7-a1ad-50e52b4d0866@github.com>
Message-ID: <qiNmnOpMaNTuSZE8g44LhVjf_anzvgf41WfOkHAk0fg=.45681586-2903-4d87-b39a-07e0f82a80f7@github.com>

On Thu, 14 Nov 2024 11:50:31 GMT, Oli Gillespie <ogillespie at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Reimplement with segmented linked list of arrays
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 310:
> 
>> 308:                Node newHead = head.next;
>> 309:                newHead.prev = null;
>> 310:                head = newHead;
> 
> Does this allow removing the final head node when the list is empty? Seems we need to avoid that (`if (head.size == 0 && head.next != null)`?.

Good spot. Fixed it exactly like that. Managed to create a direct unit test that captures it, among other things.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1842209760

From rgiulietti at openjdk.org  Thu Nov 14 13:28:57 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Thu, 14 Nov 2024 13:28:57 GMT
Subject: RFR: 8343453: Modernize FloatingDecimal tests [v3]
In-Reply-To: <WjnZQkldHSP1qqSvR00nM7vtLhh2-XGrajwcejgY1qM=.482cd2d4-4e42-4d03-9fa3-43f3ace94f5a@github.com>
References: <WjnZQkldHSP1qqSvR00nM7vtLhh2-XGrajwcejgY1qM=.482cd2d4-4e42-4d03-9fa3-43f3ace94f5a@github.com>
Message-ID: <pFsJpk_vuP-_gthRMLLQJkCX7OxI7Xg-UYH9znGu3oM=.584a8dd5-2a09-41b7-bb76-ea8122777b38@github.com>

> Simplify tests.

Raffaello Giulietti has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Cosmetic change.
 - Merge branch 'master' into 8343453
 - Remove test jdk/jdk/internal/math/ToString.java as well.
 - Merge branch 'master' into 8343453
 - 8343453: Modernize FloatingDecimal tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21840/files
  - new: https://git.openjdk.org/jdk/pull/21840/files/e1f8b895..43d6b5a5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21840&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21840&range=01-02

  Stats: 239072 lines in 3462 files changed: 131612 ins; 80588 del; 26872 mod
  Patch: https://git.openjdk.org/jdk/pull/21840.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21840/head:pull/21840

PR: https://git.openjdk.org/jdk/pull/21840

From aboldtch at openjdk.org  Thu Nov 14 13:32:45 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 14 Nov 2024 13:32:45 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
Message-ID: <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>

On Thu, 14 Nov 2024 13:24:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid NPE on empty list, add tests, touchups

This seem to handle excessive allocations when churning around an empty list by keeping the head node always allocated. I wonder if there is any worth adding some hysteresis if it churns around a multiple of the `NODE_CAPACITY`, by for example pooling one node.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2476360805

From duke at openjdk.org  Thu Nov 14 13:34:44 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Thu, 14 Nov 2024 13:34:44 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <_LlSFeUxsE5NIZ1tl6Fx_PV0NiHyVfwlkYD-91GkfOQ=.a5f09f9e-6116-4f3b-8860-c1e21474e213@github.com>

On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22104#pullrequestreview-2436096366

From jpai at openjdk.org  Thu Nov 14 13:41:44 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 14 Nov 2024 13:41:44 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
Message-ID: <BOarELLY2NpZN8Sxwzr-19_D_ogRnVWuUoFQny2Hyfs=.bcaf1720-6e27-4f35-946d-910ea9a60c6b@github.com>

On Thu, 14 Nov 2024 13:21:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
>> 
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
>> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
>> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
>> 
>> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
>> 
>> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64

This looks reasonable to me. I see that you have already acknowledged Sean's message to wait for his review before integrating. So I'll mark this as approved.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22099#pullrequestreview-2436111794

From viktor.klang at oracle.com  Thu Nov 14 13:45:27 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 14 Nov 2024 13:45:27 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
Message-ID: <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>

I see what you're saying, the problem is that it depends on the Stream implementation (given that Stream is an interface).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Thursday, 14 November 2024 12:36
To: Viktor Klang <viktor.klang at oracle.com>
Cc: Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Then let me correct myself again, while simplifying -- I just want that detail, that certain combinations might lead to pre-fetching everything, to be documented on the stream api. Package level, or on the Stream interface itself, seems like a good spot.

On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
The issue here is that the operation cannot advertise this, as it depends on the combination of operations.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Wednesday, 13 November 2024 14:07
To: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

That is a good point Rob.

Then let me correct myself -- I think the terminal operations don't do a great job of advertising whether or not they pre-fetch everything when parallelism is activated. Collector fetches as needed. FindAny pre-fetches everything. I understand that later releases might change their behaviour, but I still want to document the current behaviour in the official javadocs so that we can limit undocumented tripping hazards.


On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>> wrote:
distinct() doesn't require everything to be pulled. It can push elements
to the downstream as they come along for the first time. When
downstream.push returns false the gatherer is done.

As part of some experimentation I've implemented all intermediary
operations using gatherers. Most of them are pretty straightforward and
will stop integrating once the downstream starts rejecting elements
(although some use Gatherer.ofSequential to keep it easy). I only found
two exceptions that don't return the result of downstream.push:

* mapMulti. The downstream.push is passed as the mapper which is a
Consumer - the return value is ignored. With some more effort it's
probably possible to capture any false return value and return that from
the integrator, but I haven't tried that yet.

* sorted. Obviously every element needs to be inspected.


On 13/11/2024 00:37, David Alayachew wrote:
> Oh sure, I expect something like distinct() to pull everything. In order to
> know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
>
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
>
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
>
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
>
>
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>
>>> We are told how Streams can process unbounded data sets, but when it
>> tries to do a findAny() with parallel(), it runs into an OOME because it
>> fetched all the data ahead of time. In fact, almost of the terminal
>> operations will hit an OOME in the exact same way if they are parallel and
>> have a big enough data set. It's definitely not the end of the world, but
>> it seems that I have to fit everything into a Collector and/or a Gatherer
>> if I want to avoid pre-fetching everything.
>>
>> Yeah, I think it is important to distinguish "can process unbounded data
>> sets" from "always able to process unbounded data sets".
>>
>> Some operations inherently need the end of the stream, so even something
>> somple like: stream.distinct() or stream.sorted() can end up pulling in all
>> data (which of course won't terminate).
>>
>> Fortunately, I think Gatherers can unlock much more situations where
>> unbounded streams can be processed.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 15:08
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
>> as I thought of it.
>>
>>
>> I hand-waved away the idea because I thought that the method would turn
>> the stream pipeline parallel, thus, recreating the same problem I currently
>> have of parallelism causing all of the elements to be fetched ahead of
>> time, causing an OOME.
>>
>>
>> It did NOT occur to me that the pipeline would stay sequential, and just
>> kick these off sequentially, but have them executing in parallel. I can't
>> see why I came to that incorrect conclusion. I have read the javadocs of
>> this method several times. Though, to be fair, I came to the same,
>> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
>> until someone pointed out what the documentation was actually saying that I
>> realized it's true properties.
>>
>> Thanks. That definitely solves at least part of my problem. Obviously, I
>> would prefer to write to S3 in parallel too, but at the very least, the
>> calculation part is being done in parallel. And worst case scenario, I can
>> be really bad and just do the write to S3 in the mapConcurrent, and then
>> just return the metadata of each write, and just bundle that up with
>> collect.
>>
>>
>> And that's ignoring the fact that I can just use the workaround too.
>>
>>
>> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
>> from a performance perspective, but is rather unintuitive to me from a
>> usability perspective. We are told how Streams can process unbounded data
>> sets, but when it tries to do a findAny() with parallel(), it runs into an
>> OOME because it fetched all the data ahead of time. In fact, almost of the
>> terminal operations will hit an OOME in the exact same way if they are
>> parallel and have a big enough data set. It's definitely not the end of the
>> world, but it seems that I have to fit everything into a Collector and/or a
>> Gatherer if I want to avoid pre-fetching everything.
>>
>> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Have you considered Gatherers.mapConcurrent(?)?
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 01:53
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> Good to know, ty vm.
>>
>> At the very least, I have this workaround. This will meet my needs for now.
>>
>> I guess my final question would be -- is this type of problem better
>> suited to something besides parallel streams? Maybe an ExecutorService?
>>
>> Really, all I am doing is taking a jumbo file, splitting it into batches,
>> and then doing some work on those batches. My IO speeds are pretty fast,
>> and the compute work is non-trivial, so there is performance being left on
>> the table if I give up parallelism. And I am in a position where completion
>> time is very important to us.
>>
>> I just naturally assumed parallel streams were the right choice because
>> the compute work is simple. A pure function that I can break out, and then
>> call in a map. Once I do that, I just call forEach to write the batches
>> back out to S3. Maybe I should look into a different part of the std lib
>> instead because I am using the wrong tool for the job? My nose says
>> ExecutorService, but I figure I should ask before I dive too deep in.
>>
>>
>> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> You're most welcome!
>>
>> In a potential future where all intermediate operations are
>> Gatherer-based, and all terminal operations are Collector-based, it would
>> just work as expected. But with that said, I'm not sure it is practically
>> achievable because some operations might not have the same
>> performance-characteristics as before.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 18:32
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Thanks for the workaround. It's running beautifully.
>>
>> Is there a future where this island concept is extended to the rest of
>> streams? Tbh, I don't fully understand it.
>>
>> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Hi David,
>>
>> This is the effect of how parallel streams are implemented, where
>> different stages, which are not representible as a join-less Spliterator
>> are executed as a series of "islands" where the next isn't started until
>> the former has completed.
>>
>> If you think about it, parallelization of a Stream works best when the
>> entire data set can be split amongst a set of worker threads, and that sort
>> of implies that you want eager pre-fetch of data, so if your dataset does
>> not fit in memory, that is likely to lead to less desirable outcomes.
>>
>> What I was able to do for Gatherers is to implement "gather(?) +
>> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> immediately followed by a collect(?) is run in the same "island".
>>
>> So with that said, you could try something like the following:
>>
>> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
>> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> }
>>
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .collect(forEach(eachList -> println(eachList.getFirst())));
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David
>> Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 14:52
>> *To:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> elements
>>
>> And just to avoid the obvious question, I can hold about 30 batches in
>> memory before the Out of Memory error occurs. So this is not an issue of my
>> batch size being too high.
>>
>> But just to confirm, I set the batch size to 1, and it still ran into an
>> out of memory error. So I feel fairly confident saying that the Gatherer is
>> trying to grab all available data before sending any of it downstream.
>>
>> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> wrote:
>>
>> Hello Core Libs Dev Team,
>>
>> I was trying out Gatherers for a project at work, and ran into a rather
>> sad scenario.
>>
>> I need to process a large file in batches. Each batch is small enough that
>> I can hold it in memory, but I cannot hold the entire file (and thus, all
>> of the batches) in memory at once.
>>
>> Looking at the Gatherers API, I saw windowFixed and thought that it would
>> be a great match for my use case.
>>
>> However, when trying it out, I was disappointed to see that it ran out of
>> memory very quickly. Here is my attempt at using it.
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .forEach(eachList -> println(eachList.getFirst()))
>> ;
>>
>> As you can see, I am just splitting the file into batches, and printing
>> out the first of each batch. This is purely for example's sake, of course.
>> I had planned on building even more functionality on top of this, but I
>> couldn't even get past this example.
>>
>> But anyways, not even a single one of them printed out. Which leads me to
>> believe that it's pulling all of them in the Gatherer.
>>
>> I can get it to run successfully if I go sequentially, but not parallel.
>> Parallel gives me that out of memory error.
>>
>> Is there any way for me to be able to have the Gatherer NOT pull in
>> everything while still remaining parallel and unordered?
>>
>> Thank you for your time and help.
>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241114/9ab1606a/attachment-0001.htm>

From liach at openjdk.org  Thu Nov 14 13:47:17 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 13:47:17 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <sjKkHTRBDaJ8Q1z1-N2xsSJAnMZn7NI0vCb6sUrvDUE=.c59cc225-b640-4dad-92de-2d898761c9b6@github.com>

On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

I think you should convert all array index scales to long too.  They are susceptible to the same overflow problem (actually more susceptible as they involve in integer multiplications)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2476393412

From shade at openjdk.org  Thu Nov 14 13:59:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 13:59:40 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
 <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>
Message-ID: <nNqG5StavW_fzll_TJz8JwR8myElGIoxGDyg8giuLQY=.56af70f1-0301-4169-b70f-b83dfec8f8f6@github.com>

On Thu, 14 Nov 2024 13:28:46 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> This seem to handle excessive allocations when churning around an empty list by keeping the head node always allocated. 

Realistically, the list is almost never empty: there is a `Cleaner` instance itself recorded in the list. The only (?) state when the list is fully empty is when `Cleaner` itself is also dead, AFAICS. We pre-allocate head node for the implementation simplicity: if `head` is always available, we don't need to null-check it, for example.

> I wonder if there is any worth adding some hysteresis if it churns around a multiple of the `NODE_CAPACITY`, by for example pooling one node.

I don't think we should care about this case: it seems the rare benefit does not outweigh the cost for common case? The goal for this implementation is to avoid wasting more space than necessary. Caching a node would take another bunch of KBs per Cleaner, at very least.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2476419160

From lancea at openjdk.org  Thu Nov 14 13:59:42 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 13:59:42 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
Message-ID: <5CH1vfCH01gqHpqRVwVpj0mJZ_yHYv60ejNMjL7tg9A=.e0a6a177-3cf2-4c57-9300-e16ba53fed3e@github.com>

On Thu, 14 Nov 2024 13:21:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
>> 
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
>> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
>> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
>> 
>> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
>> 
>> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64

The changes look reasonable to me.

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22099#pullrequestreview-2436155762

From mullan at openjdk.org  Thu Nov 14 14:01:58 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 14:01:58 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v6]
In-Reply-To: <iC-cWokw4nc5UHR3tB7SbIrqheofd8wFW8Vbl2l13zY=.77db0c69-28a1-49cb-a4b7-831e119f136f@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <iC-cWokw4nc5UHR3tB7SbIrqheofd8wFW8Vbl2l13zY=.77db0c69-28a1-49cb-a4b7-831e119f136f@github.com>
Message-ID: <EhBh8vVJ3lEjhx2mmGnkrQsxSOTqGw_0VNPZOHeXjv0=.9d6f6253-4216-4836-afa1-001b1f6a488d@github.com>

On Wed, 13 Nov 2024 15:35:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

src/java.base/share/classes/java/io/ObjectOutputStream.java line 225:

> 223:      * as true or false for extended information about exception's place
> 224:      */
> 225:     private static final boolean extendedDebugInfo = Boolean.getBoolean("sun.io.serialization.extendedDebugInfo");

Nit: bit of a long line, consider breaking into 2 lines.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1842268579

From lancea at openjdk.org  Thu Nov 14 14:07:31 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 14:07:31 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>

On Thu, 14 Nov 2024 11:21:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

Thank you for the PR Eirik, overall it looks OK.  See comments below WRT to exception messages in the test

test/jdk/jdk/nio/zipfs/TestPosix.java line 224:

> 222:         } catch (IOException e) {
> 223:             System.out.println("Caught " + e.getClass().getName() + "(" + e.getMessage() +
> 224:                     ") when running a privileged operation to get the default owner.");

Given we are not running a privileged operation, we should probably tweak the exception message

test/jdk/jdk/nio/zipfs/TestPosix.java line 239:

> 237:             return defaultOwner;
> 238:         } catch (IOException e) {
> 239:             System.out.println("Caught an exception when running a privileged operation to get the default group.");

Same comment WRT "privileged operation"

-------------

PR Review: https://git.openjdk.org/jdk/pull/22101#pullrequestreview-2436170504
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842273651
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842274986

From eirbjo at openjdk.org  Thu Nov 14 14:15:28 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 14:15:28 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
Message-ID: <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>

On Thu, 14 Nov 2024 14:01:45 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> test/jdk/jdk/nio/zipfs/TestPosix.java line 224:
> 
>> 222:         } catch (IOException e) {
>> 223:             System.out.println("Caught " + e.getClass().getName() + "(" + e.getMessage() +
>> 224:                     ") when running a privileged operation to get the default owner.");
> 
> Given we are not running a privileged operation, we should probably tweak the exception message

Thanks, I was a bit of a robot here and didn't read the exception message :-)

I think it might be better to simply propagate this IOException to the calling method `testPosixDefaults`. This method throws IOException. Catching this IOException here provides limited value.

What do you think?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842289557

From mullan at openjdk.org  Thu Nov 14 14:16:54 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 14:16:54 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v6]
In-Reply-To: <iC-cWokw4nc5UHR3tB7SbIrqheofd8wFW8Vbl2l13zY=.77db0c69-28a1-49cb-a4b7-831e119f136f@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <iC-cWokw4nc5UHR3tB7SbIrqheofd8wFW8Vbl2l13zY=.77db0c69-28a1-49cb-a4b7-831e119f136f@github.com>
Message-ID: <WQnnAF0kS4zvJRPVJn34gGpnzdSA2wG3rgZ99rbzZ3k=.69c3fbfc-1b38-4382-ae79-d1a4ca394167@github.com>

On Wed, 13 Nov 2024 15:35:42 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove unused imports

Looks good other than 2 small comments.

src/java.base/share/classes/java/io/ObjectInputStream.java line 281:

> 279:          * throwing {@link ClassNotFoundException}.
> 280:          */
> 281:         private static final boolean GETFIELD_CNFE_RETURNS_NULL = Boolean.getBoolean("jdk.serialGetFieldCnfeReturnsNull");

Nit: a bit of a long line, suggest breaking in two lines.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22041#pullrequestreview-2436176284
PR Review Comment: https://git.openjdk.org/jdk/pull/22041#discussion_r1842276926

From asemenyuk at openjdk.org  Thu Nov 14 14:19:57 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 14 Nov 2024 14:19:57 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <BguSFxenyD-4a0siuiUzLbsFzwW7ix-1vMjCOvL6Udg=.94211802-60e9-413f-bb7d-2571470b25de@github.com>

On Sat, 9 Nov 2024 00:51:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21996#issuecomment-2476469047

From lancea at openjdk.org  Thu Nov 14 14:34:25 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 14:34:25 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
 <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>
Message-ID: <7YV23xxU54tyJeP4ZcYnppIJ4cERBOO92Q8RSiiSPos=.441209d4-1c81-40ff-8285-0534100f8ee0@github.com>

On Thu, 14 Nov 2024 14:11:57 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> test/jdk/jdk/nio/zipfs/TestPosix.java line 224:
>> 
>>> 222:         } catch (IOException e) {
>>> 223:             System.out.println("Caught " + e.getClass().getName() + "(" + e.getMessage() +
>>> 224:                     ") when running a privileged operation to get the default owner.");
>> 
>> Given we are not running a privileged operation, we should probably tweak the exception message
>
> Thanks, I was a bit of a robot here and didn't read the exception message :-)
> 
> I think it might be better to simply propagate this IOException to the calling method `testPosixDefaults`. This method throws IOException. Catching this IOException here provides limited value.
> 
> What do you think?

For this specific PR, I might just change the error message and revisit once we deal with the SM to avoid any unexpected surprises (one bitten twice shy ;-) )

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842323725

From swen at openjdk.org  Thu Nov 14 14:38:09 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 14 Nov 2024 14:38:09 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <sjKkHTRBDaJ8Q1z1-N2xsSJAnMZn7NI0vCb6sUrvDUE=.c59cc225-b640-4dad-92de-2d898761c9b6@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <sjKkHTRBDaJ8Q1z1-N2xsSJAnMZn7NI0vCb6sUrvDUE=.c59cc225-b640-4dad-92de-2d898761c9b6@github.com>
Message-ID: <JbQ5bLN33qdiQ3yckFxrFTYuBYe0Ry8ap3hsE0XSVBQ=.cb285939-ab91-4b94-9d54-8af9edbeb201@github.com>

On Thu, 14 Nov 2024 13:44:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think you should convert all array index scales to long too. They are susceptible to the same overflow problem (actually more susceptible as they involve in integer multiplications)

Changing the index scale to long type will cause a lot of code related to ArraysSupport.vectorizedMismatch to change. There are too many places to change and I am not sure.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2476510756

From archie.cobbs at gmail.com  Thu Nov 14 14:43:34 2024
From: archie.cobbs at gmail.com (Archie Cobbs)
Date: Thu, 14 Nov 2024 08:43:34 -0600
Subject: RFR: 8343490: Update copyright year for JDK-8341692
In-Reply-To: <9R5gF8dIqwO0TbBhICMDC7c2g4gvY0tXA82LcvmAEpI=.4159e63b-4899-48d9-9829-0f13c6307446@github.com>
References: <2BwWuKdm5FwggsXPwo3P2xRD6CGr5QDdn3gVG5x5fo0=.41d944e6-6737-4d7d-8654-986149b41c9d@github.com>
 <9R5gF8dIqwO0TbBhICMDC7c2g4gvY0tXA82LcvmAEpI=.4159e63b-4899-48d9-9829-0f13c6307446@github.com>
Message-ID: <CANSoFxvmRap-j8nkzAX1F3vb2S-p2tn4PFrPSqbpoHkGZeJGAg@mail.gmail.com>

On Wed, Nov 13, 2024 at 10:39?PM Phil Race <prr at openjdk.org> wrote:

> On Tue, 5 Nov 2024 01:41:00 GMT, SendaoYan <syan at openjdk.org> wrote:
> > The copyright year of some files which has been changed by
> [JDK-8341692](https://bugs.openjdk.org/browse/JDK-8341692) wasn't update
> correctly. This PR update the copyright year of [JDK-8341692](
> https://bugs.openjdk.org/browse/JDK-8341692). Trivial fix, no risk.
>
> FWIW this whole PR seems like a waste of a bug id. Copyright year is
> implied anyway.
>

Hang on a second...

In SendaoYan's defense: Either we have a policy that says copyright years
must be updated, or we don't. Which is it?

There is plenty of room for debate about the policy (and I agree with you
that the policy could in fact be wasting everyone's time for no actual
legal purpose), but at any given point in time, whatever the policy is, we
should be following it, right?

Or - if the policy is wrong, let's change it!

-Archie

-- 
Archie L. Cobbs
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241114/03c8aeed/attachment.htm>

From eirbjo at openjdk.org  Thu Nov 14 14:43:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 14:43:50 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Update debug logging to not reference privileged operations

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22101/files
  - new: https://git.openjdk.org/jdk/pull/22101/files/d8936a5c..37104a91

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22101&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22101&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22101/head:pull/22101

PR: https://git.openjdk.org/jdk/pull/22101

From eirbjo at openjdk.org  Thu Nov 14 14:43:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 14:43:50 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <7YV23xxU54tyJeP4ZcYnppIJ4cERBOO92Q8RSiiSPos=.441209d4-1c81-40ff-8285-0534100f8ee0@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <6XKWAiGX5ZsXmYCaQRDfhfOL46rCU3W1BARmxv5fclQ=.e7d5142a-22fe-4814-bca7-b4d2020a5f8c@github.com>
 <eGoX3KA6_Qc_qhqWjjFHZO-9Fa2yw5VXVYqH3n9MtjY=.1b222a3e-276b-4172-aa90-d798237f5cc9@github.com>
 <7YV23xxU54tyJeP4ZcYnppIJ4cERBOO92Q8RSiiSPos=.441209d4-1c81-40ff-8285-0534100f8ee0@github.com>
Message-ID: <kOopkDSgmViIYeVWjg2rfczeI3iBl5A0JpQF5v9ikgo=.d00f4446-cc4b-4efa-b959-cb308ddb46fd@github.com>

On Thu, 14 Nov 2024 14:31:03 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Thanks, I was a bit of a robot here and didn't read the exception message :-)
>> 
>> I think it might be better to simply propagate this IOException to the calling method `testPosixDefaults`. This method throws IOException. Catching this IOException here provides limited value.
>> 
>> What do you think?
>
> For this specific PR, I might just change the error message and revisit once we deal with the SM to avoid any unexpected surprises (one bitten twice shy ;-) )

Okay, I've tweaked the debug messages to not reference privileged actions.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842339786

From duke at openjdk.org  Thu Nov 14 14:44:46 2024
From: duke at openjdk.org (Glavo)
Date: Thu, 14 Nov 2024 14:44:46 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <OXo3ZuxChVuO0hhp_WRMwqFA69qKowY51KED77AncuA=.db76b074-5e3e-46fd-9f0e-4b7cee43f9bd@github.com>

On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

I'm concerned that such a change could have unintended consequences, and perhaps deprecating them and providing new long constants would be a better option.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2476528184

From yzheng at openjdk.org  Thu Nov 14 14:47:40 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Thu, 14 Nov 2024 14:47:40 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader
 and related classes [v2]
In-Reply-To: <Yzup9r6TYApQey2FJtWTUVJvOKNdsnX5FhUrSQmSvJE=.c5ea09f3-6daa-49fc-a2e8-4cbe4677ac08@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
 <Yzup9r6TYApQey2FJtWTUVJvOKNdsnX5FhUrSQmSvJE=.c5ea09f3-6daa-49fc-a2e8-4cbe4677ac08@github.com>
Message-ID: <0uUAxOargB8tumQzju9BQY-OH4P0QyRnKtlz3EnWcNk=.63598313-b5dc-419a-b70e-61f61bba63c7@github.com>

On Thu, 14 Nov 2024 11:25:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
>> 
>> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Change 2-arg findResource to use findResourceOnClassPath when finding resources on class path
>  - Merge branch 'master' into JDK-8343982
>  - Initial commit

LGTM

-------------

Marked as reviewed by yzheng (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22097#pullrequestreview-2436292670

From aboldtch at openjdk.org  Thu Nov 14 14:54:36 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Thu, 14 Nov 2024 14:54:36 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <nNqG5StavW_fzll_TJz8JwR8myElGIoxGDyg8giuLQY=.56af70f1-0301-4169-b70f-b83dfec8f8f6@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
 <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>
 <nNqG5StavW_fzll_TJz8JwR8myElGIoxGDyg8giuLQY=.56af70f1-0301-4169-b70f-b83dfec8f8f6@github.com>
Message-ID: <WkErNXO5MrQfZF-9CItQHXVcjSJPX5dY1J9AJ1lUjKo=.0b58ad33-1bda-4364-8094-c6100099d4cf@github.com>

On Thu, 14 Nov 2024 13:56:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> I don't think we should care about this case: it seems the rare benefit does not outweigh the cost for common case? The goal for this implementation is to avoid wasting more space than necessary. Caching a node would take another bunch of KBs per Cleaner, at very least.

That is probably correct. I was however thinking that it would only be pooled asymmetrically as some type of hystereses. So you pool when you remove a node (switch the head) and keep it far an arbitrary amount of removals. So it would only really waste memory for cleaners that have this behaviour that they keep adding and removing cleanable around a NODE_CAPACITY boundary.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2476557406

From liach at openjdk.org  Thu Nov 14 15:01:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 15:01:22 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <OXo3ZuxChVuO0hhp_WRMwqFA69qKowY51KED77AncuA=.db76b074-5e3e-46fd-9f0e-4b7cee43f9bd@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <OXo3ZuxChVuO0hhp_WRMwqFA69qKowY51KED77AncuA=.db76b074-5e3e-46fd-9f0e-4b7cee43f9bd@github.com>
Message-ID: <RwhtfUdxQ3Ug1ua6dksbg0VOM7ucLwLGWA3kJpGnCWw=.7678e31a-d738-4a60-8600-e2462ff874b4@github.com>

On Thu, 14 Nov 2024 14:41:13 GMT, Glavo <duke at openjdk.org> wrote:

>> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
>> 
>> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.
>
> I'm concerned that such a change could have unintended consequences, and perhaps deprecating them and providing new long constants would be a better option.

@Glavo This change only happens to jdk.internal.misc.Unsafe.  The values in sun.misc.Unsafe are untouched, and they are already deprecated for removal.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2476590198

From lancea at openjdk.org  Thu Nov 14 15:04:38 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 15:04:38 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
Message-ID: <gTkaHj9td9gnqmv8Oop9dWp98Z74QoN8fWaNL4_WyRw=.026ef8f1-3145-4385-b7e2-316f3c9997e5@github.com>

On Thu, 14 Nov 2024 14:43:50 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update debug logging to not reference privileged operations

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22101#pullrequestreview-2436338832

From swen at openjdk.org  Thu Nov 14 15:09:22 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Thu, 14 Nov 2024 15:09:22 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <sjKkHTRBDaJ8Q1z1-N2xsSJAnMZn7NI0vCb6sUrvDUE=.c59cc225-b640-4dad-92de-2d898761c9b6@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <sjKkHTRBDaJ8Q1z1-N2xsSJAnMZn7NI0vCb6sUrvDUE=.c59cc225-b640-4dad-92de-2d898761c9b6@github.com>
Message-ID: <iMngJ3_rUYePbPTCKpdubOhYVcqI9Atg7An-O1mt7dI=.b8832d1c-dc6a-41ff-ad7d-51f324e2d34a@github.com>

On Thu, 14 Nov 2024 13:44:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> I think you should convert all array index scales to long too. They are susceptible to the same overflow problem (actually more susceptible as they involve in integer multiplications)

The only places in JDK where there is a risk of offset overflow using Unsafe index scale are jdk.incubator.vector.XXXVector, and they are all explicitly converted to long type. Can we not change it yet?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2476627886

From duke at openjdk.org  Thu Nov 14 15:10:37 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 14 Nov 2024 15:10:37 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:

 - Merge remote-tracking branch 'upstream-jdk/master' into serialization
 - Address review feedback
 - Merge remote-tracking branch 'upstream-jdk/master' into serialization
 - Merge remote-tracking branch 'upstream-jdk/master' into serialization
 - Round out the documentation of the new methods to explain the supported and unsupported cases
 - Move `serialPersistentFields` for a degree of method order consistency
 - Address review feedback
 - Test fixes and finish renaming
 - Address review feedback
 - Address review comment
 - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

-------------

Changes: https://git.openjdk.org/jdk/pull/19702/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19702&range=10
  Stats: 914 lines in 6 files changed: 911 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/19702.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19702/head:pull/19702

PR: https://git.openjdk.org/jdk/pull/19702

From jjg at openjdk.org  Thu Nov 14 15:26:22 2024
From: jjg at openjdk.org (Jonathan Gibbons)
Date: Thu, 14 Nov 2024 15:26:22 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
Message-ID: <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>

On Thu, 14 Nov 2024 12:22:36 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> In several (most? all?) of the build system files, the copyright header includes the classpath exception. This makes no sense, and should be removed. 
> 
> I have removed the classpath exception from makefiles, autoconf, shell scripts, properties files, configuration files, IDE support files, build tools and data.
> 
> The only places where the classpath exception is still kept in the make directory is as text strings in some build tools, which generate source code that is bundled with `src.zip`, and thus *must* have the classpath exception.
> 
> This is a huge and autogenerated, but content-wise trivial, PR, and I know such are hard to review. I recommend looking at the entire diff file instead of checking this file-by-file in the Github web GUI. (That's bound to be a painful experience)

The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2476698524

From ogillespie at openjdk.org  Thu Nov 14 15:26:24 2024
From: ogillespie at openjdk.org (Oli Gillespie)
Date: Thu, 14 Nov 2024 15:26:24 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
Message-ID: <P_8xfFGBlyzCP8pb5gY3oeKFXz2oqhYiz1SzuBJXv-0=.eb5ea827-50dd-4418-9f71-62b1271bcddb@github.com>

On Thu, 14 Nov 2024 13:24:26 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Avoid NPE on empty list, add tests, touchups

Marked as reviewed by ogillespie (Author).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22043#pullrequestreview-2436402153

From liach at openjdk.org  Thu Nov 14 15:51:16 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 15:51:16 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <jqX65R12-PYPeghtw0lPlBcoQYmtecV3J3P9F87mMvA=.323ebcc7-61f4-49d4-8595-5f4f25431ba8@github.com>

On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

I am currently busy with a few things in ClassFile API.  I can soon come back onto this and might send PRs to you to migrate risky use of array index scales too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2476760257

From rriggs at openjdk.org  Thu Nov 14 15:56:42 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 15:56:42 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v7]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <VuJD8wHNifkw69IZpp7cZFJOXi_KYlK6hqUkVeekpHI=.29fcfd4f-06b5-4574-a1ac-0b3c8ad9f205@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 232 commits:

 - Fix test to longer check for CallerSensistive on ObjectStreamField.getType.
 - Merge branch 'master' into 8344034-sm-removal-serialization
 - Remove unused imports
 - Remove CallerSensitive and suppress warnings
 - Remove overlooked SecurityManager use in ObjectInputFilter and ObjectStreamClass
 - Cleanup of suppress warnings and caller sensitive from review comments.
 - Merge branch 'master' into 8344034-sm-removal-serialization
 - JDK-8344034: Remove security manager dependency in Serialization
 - Merge remote-tracking branch 'jdk-sandbox/jep486' into JDK-8338411
 - Merge branch 'master' into jep486
 - ... and 222 more: https://git.openjdk.org/jdk/compare/752e1629...b8e8d420

-------------

Changes: https://git.openjdk.org/jdk/pull/22041/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=06
  Stats: 420 lines in 7 files changed: 7 ins; 323 del; 90 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From asotona at openjdk.org  Thu Nov 14 15:58:05 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Nov 2024 15:58:05 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName() method
 should return Utf8Entry
Message-ID: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>

Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.

This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.

Please review.

Thanks,
Adam

-------------

Commit messages:
 - suggested patch
 - Fixed AbstractAttributeMapper and typo in UnboundAttribute
 - Reversion of AttributeMapper changes
 - 8343881: java.lang.classfile.Attribute attributeName() method should return Utf8Entry

Changes: https://git.openjdk.org/jdk/pull/22107/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22107&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343881
  Stats: 399 lines in 18 files changed: 375 ins; 5 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/22107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22107/head:pull/22107

PR: https://git.openjdk.org/jdk/pull/22107

From liach at openjdk.org  Thu Nov 14 15:58:06 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 15:58:06 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry
In-Reply-To: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
Message-ID: <e6fqiQ1jMZKx92cMBbi9r7zhUH99RqIa84Mmhe5Ewvw=.8fbdc0eb-3b1d-4e64-abe9-942e3c0726e8@github.com>

On Thu, 14 Nov 2024 14:19:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
> 
> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
> 
> Please review.
> 
> Thanks,
> Adam

Can you change `AbstractAttributeMapper` to write the `attributeName` utf8 entry instead of looking up on write?

This changeset looks good to me.

src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 445:

> 443:         @Override
> 444:         public Utf8Entry attributeName() {
> 445:             return NAME;

Maybe `buf.constantPool().utf8Entry(NAME_LINE_NUMBER_TABLE)`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22107#pullrequestreview-2436361636
Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22107#pullrequestreview-2436478500
PR Review Comment: https://git.openjdk.org/jdk/pull/22107#discussion_r1842434757

From asotona at openjdk.org  Thu Nov 14 15:58:06 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Nov 2024 15:58:06 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry
In-Reply-To: <e6fqiQ1jMZKx92cMBbi9r7zhUH99RqIa84Mmhe5Ewvw=.8fbdc0eb-3b1d-4e64-abe9-942e3c0726e8@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
 <e6fqiQ1jMZKx92cMBbi9r7zhUH99RqIa84Mmhe5Ewvw=.8fbdc0eb-3b1d-4e64-abe9-942e3c0726e8@github.com>
Message-ID: <ysv4vFb-OEoq4XpeF3FwBsUV8rgc0r9i8gsBiV5u49s=.7bdb1c75-ede7-419d-8b5b-d115d2b0f634@github.com>

On Thu, 14 Nov 2024 15:35:17 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
>> 
>> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> src/java.base/share/classes/jdk/internal/classfile/impl/DirectCodeBuilder.java line 445:
> 
>> 443:         @Override
>> 444:         public Utf8Entry attributeName() {
>> 445:             return NAME;
> 
> Maybe `buf.constantPool().utf8Entry(NAME_LINE_NUMBER_TABLE)`?

Good catch, I missed there is buf field initialized.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22107#discussion_r1842448941

From mullan at openjdk.org  Thu Nov 14 16:01:53 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 16:01:53 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
Message-ID: <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>

On Thu, 14 Nov 2024 14:43:50 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update debug logging to not reference privileged operations

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 252:

> 250:         if (o == null) {
> 251:             try {
> 252:                 PrivilegedExceptionAction<UserPrincipal> pa = ()->Files.getOwner(zfpath);

Can you also remove the `@SuppressWarnings("removal")` on line 239?

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 294:

> 292:                     return defaultOwner::getName;
> 293:                 }
> 294:                 PrivilegedExceptionAction<GroupPrincipal> pa = ()->zfpv.readAttributes().group();

Can you also remove the @SuppressWarnings("removal") on line 269?

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 483:

> 481:         beginWrite();                // lock and sync
> 482:         try {
> 483:             AccessController.doPrivileged((PrivilegedExceptionAction<Void>)() -> {

Can you also remove the @SuppressWarnings("removal") on line 442?

src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystemProvider.java line 317:

> 315: 
> 316:     //////////////////////////////////////////////////////////////
> 317:     @SuppressWarnings("removal")

You can remove the annotation now.

test/jdk/jdk/nio/zipfs/TestPosix.java line 236:

> 234:             }
> 235:             return zfpv.readAttributes().group().getName();
> 236:         } catch (UnsupportedOperationException | NoSuchFileException e) {

In the prior code, I think `NoSuchFileException` would have been the cause of the `SecurityException`, so the code would have returned `null`. Just wondering why you changed it here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842463056
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842467210
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842466546
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842445637
PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842456357

From sgehwolf at openjdk.org  Thu Nov 14 16:14:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 14 Nov 2024 16:14:30 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early
In-Reply-To: <xN7uGi3rA6o-GskzEnRHsyR6iIOplY6lfMi-FIIdjiI=.b61ac634-ceb2-49ec-a7cb-94676afe4aec@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
 <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
 <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
 <xN7uGi3rA6o-GskzEnRHsyR6iIOplY6lfMi-FIIdjiI=.b61ac634-ceb2-49ec-a7cb-94676afe4aec@github.com>
Message-ID: <REaAODrWKvg4KtWt98si_j-Wifm9sdcZDGyLx81eoZs=.9ecd938d-34b7-46ae-bcc5-eb3025e3d407@github.com>

On Tue, 12 Nov 2024 14:29:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> Instead, I think we should look at adding a property such as jdk.patched
>> 
>> You mean a new standard property - observable with `System.getProperty("jdk.patched")` as well - which would also show up with `java -XshowSettings:properties`? Is that the direction you are envisioning?
>
> Yes, I'm wondering if a JDK-specific (rather than standard) property could be more widely useful as it would allow observability tools to know that the JDK has been patched. It would be good to get wider input on this.

@AlanBateman The discussion doesn't see to gain much traction. Should I go ahead and propose a bug/patch - with CSR -  which adds the JDK specific property and make it dependent on this fix? Thoughts?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1842509475

From vklang at openjdk.org  Thu Nov 14 16:39:54 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 14 Nov 2024 16:39:54 GMT
Subject: RFR: 8342380: Implement JEP 498: Warn upon Use of Memory-Access
 Methods in sun.misc.Unsafe [v2]
In-Reply-To: <8jaBPHqLI5QJ826RlbsnXPImPUSXmUx7ORfRaLa5J1s=.2e14927e-8de1-421b-a258-cb1201a85913@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
 <8jaBPHqLI5QJ826RlbsnXPImPUSXmUx7ORfRaLa5J1s=.2e14927e-8de1-421b-a258-cb1201a85913@github.com>
Message-ID: <6-oRee8EPEdAz5NfpJf3sWExbLP0FlxswYqY9Ns4tSw=.9b73d791-a795-41c5-aff0-e223a9d484f4@github.com>

On Wed, 13 Nov 2024 12:05:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Change default value of the command line option --sun-misc-unsafe-memory-access from "allow" to "warn".
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:
> 
>  - Merge branch 'master' into JDK-8342380
>  - Update test
>  - Merge branch 'master' into JDK-8342380
>  - Update usage/man page
>  - Initial commit

LGTM

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21762#pullrequestreview-2436641304

From bpb at openjdk.org  Thu Nov 14 16:41:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Nov 2024 16:41:12 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v8]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <XOSUzWfnqvNkYM3o4tnwW54iLSrUpaEethSI7msFQuY=.45699af9-5d56-4912-8dbf-c3d48c959511@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8343039: Change "resizble" comment in BOS

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/0b68ed08..15bf969a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=06-07

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From bpb at openjdk.org  Thu Nov 14 16:41:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Nov 2024 16:41:12 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v7]
In-Reply-To: <CpJWT9_Vu-7qO2EILCnqbK3BBNLGOk65rfVmkrSZfMI=.e5632c62-3082-41b3-9d5b-79cc47853334@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <pRF9JYoj9GYXU3_8zuTotAIzd-6AWl6ECYCRGCtVrsU=.655e2d40-3e7b-4ce1-9927-716b7b8f9d96@github.com>
 <k5byHEo6WqCFq7_EWPX_C_YjVDerdtfFWox2TbDa7F4=.ae3a3d89-418d-4837-8bb7-a8bd435d3942@github.com>
 <CpJWT9_Vu-7qO2EILCnqbK3BBNLGOk65rfVmkrSZfMI=.e5632c62-3082-41b3-9d5b-79cc47853334@github.com>
Message-ID: <gaVS3W5P31pWoTfWTNjCe-nkcKA_n5f-R9BkohaqafY=.50834d3c-b9eb-4e91-8ca9-29a895860cd9@github.com>

On Thu, 14 Nov 2024 13:18:03 GMT, ExE Boss <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/io/BufferedOutputStream.java line 89:
>> 
>>> 87: 
>>> 88:         if (getClass() == BufferedOutputStream.class) {
>>> 89:             // resizable if initialSize < maxSize
>> 
>> I think the comment is confusing, can it just say resizable when not sub-classed as it did previously?
>
> Suggestion:
> 
>             // resizable when not sub-classed

Changed in 15bf969.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1842560653

From alanb at openjdk.org  Thu Nov 14 16:46:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 16:46:47 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v8]
In-Reply-To: <XOSUzWfnqvNkYM3o4tnwW54iLSrUpaEethSI7msFQuY=.45699af9-5d56-4912-8dbf-c3d48c959511@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <XOSUzWfnqvNkYM3o4tnwW54iLSrUpaEethSI7msFQuY=.45699af9-5d56-4912-8dbf-c3d48c959511@github.com>
Message-ID: <o5G9-72-_FoDWWAk-laBZ2o88m-ACAt1oLpA9onctiY=.322dd4fe-8661-4182-aea9-3fd4fa8ab7c2@github.com>

On Thu, 14 Nov 2024 16:41:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8343039: Change "resizble" comment in BOS

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22048#pullrequestreview-2436664471

From jvernee at openjdk.org  Thu Nov 14 16:58:14 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 14 Nov 2024 16:58:14 GMT
Subject: Integrated: 8342963: TestLargeStub::testUpcall doesn't test upcalls
 stubs
In-Reply-To: <4v3pSjmkMF8A7UxoVvkwQsNt_4PG4NvjkHv9tCVGEhs=.f37c49c9-9c44-429b-9627-197476d1e52a@github.com>
References: <4v3pSjmkMF8A7UxoVvkwQsNt_4PG4NvjkHv9tCVGEhs=.f37c49c9-9c44-429b-9627-197476d1e52a@github.com>
Message-ID: <TnNqNoQK2KaRI2Tcne5Pl4v88KWE7qFifoGONpKDDcw=.1b13bb05-f14d-42c4-9426-d801578bd5e0@github.com>

On Thu, 24 Oct 2024 18:29:18 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> We were made aware of the fact the `TestLargeStub::testUpcall` was not actually calling `Linker::upcallStub`. This PR addresses that issue.

This pull request has now been integrated.

Changeset: 002b985a
Author:    Jorn Vernee <jvernee at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/002b985a4633b6cf11143f589bcecc51490c739e
Stats:     15 lines in 1 file changed: 12 ins; 0 del; 3 mod

8342963: TestLargeStub::testUpcall doesn't test upcalls stubs

Reviewed-by: mcimadamore

-------------

PR: https://git.openjdk.org/jdk/pull/21691

From eirbjo at openjdk.org  Thu Nov 14 17:01:48 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 17:01:48 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v3]
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <J8U8nHjdYG2RZafj32txzwpS0gm4iSx7kWFd7IbsOfQ=.0faf9322-ef63-4d1c-b0a9-afc31c1045f3@github.com>

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Revert catching of NoSuchFileException in expectedDefaultOwner and expectedDefaultGroup
 - Remove @SuppressWarnings("removal")

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22101/files
  - new: https://git.openjdk.org/jdk/pull/22101/files/37104a91..c13e5519

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22101&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22101&range=01-02

  Stats: 6 lines in 3 files changed: 0 ins; 4 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22101.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22101/head:pull/22101

PR: https://git.openjdk.org/jdk/pull/22101

From eirbjo at openjdk.org  Thu Nov 14 17:01:49 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 17:01:49 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v3]
In-Reply-To: <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
Message-ID: <XVVemab-eMvwilig-QhiH-EqxEfI3g_56pG6LZWvatY=.945297fc-5ed9-46b1-b086-3167b08ef649@github.com>

On Thu, 14 Nov 2024 15:52:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert catching of NoSuchFileException in expectedDefaultOwner and expectedDefaultGroup
>>  - Remove @SuppressWarnings("removal")
>
> src/jdk.zipfs/share/classes/jdk/nio/zipfs/ZipFileSystem.java line 252:
> 
>> 250:         if (o == null) {
>> 251:             try {
>> 252:                 PrivilegedExceptionAction<UserPrincipal> pa = ()->Files.getOwner(zfpath);
> 
> Can you also remove the `@SuppressWarnings("removal")` on line 239?

Removed this and the others.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842588438

From eirbjo at openjdk.org  Thu Nov 14 17:01:51 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 17:01:51 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
Message-ID: <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>

On Thu, 14 Nov 2024 15:48:30 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Update debug logging to not reference privileged operations
>
> test/jdk/jdk/nio/zipfs/TestPosix.java line 236:
> 
>> 234:             }
>> 235:             return zfpv.readAttributes().group().getName();
>> 236:         } catch (UnsupportedOperationException | NoSuchFileException e) {
> 
> In the prior code, I think `NoSuchFileException` would have been the cause of the `SecurityException`, so the code would have returned `null`. Just wondering why you changed it here.

Interesting catch..

My understanding is that the purpose of `expectedDefaultOwner` and `expectedDefaultGroup` is to mimic the behavior of `ZipFileSystem:initOwner` and `ZipFileSystem::initGroup`.

The ZipFileSystem methods both check for `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, while the TestPosix expect methods do not. This is why I added them, to make them consistent with the implementation code.

This inconsistency is a however a preexisting issue. Attempting to fixing them here might just clutter this review. So I have reverted the catch for `NoSuchFileException`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842587185

From asotona at openjdk.org  Thu Nov 14 17:02:49 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Nov 2024 17:02:49 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry [v2]
In-Reply-To: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
Message-ID: <8D1Elkxg68xP-5YxU3wGd_iKeU_2MIfgZ_nD5jBvxRc=.78f647e5-aee5-4b2d-86bd-a461488f463f@github.com>

> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
> 
> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  fixed tests

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22107/files
  - new: https://git.openjdk.org/jdk/pull/22107/files/dbf27666..6fb11386

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22107&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22107&range=00-01

  Stats: 18 lines in 10 files changed: 0 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/22107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22107/head:pull/22107

PR: https://git.openjdk.org/jdk/pull/22107

From liach at openjdk.org  Thu Nov 14 17:08:11 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 17:08:11 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry [v2]
In-Reply-To: <8D1Elkxg68xP-5YxU3wGd_iKeU_2MIfgZ_nD5jBvxRc=.78f647e5-aee5-4b2d-86bd-a461488f463f@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
 <8D1Elkxg68xP-5YxU3wGd_iKeU_2MIfgZ_nD5jBvxRc=.78f647e5-aee5-4b2d-86bd-a461488f463f@github.com>
Message-ID: <fZyXsLf2K0VCmtvTnczdVD_Zmrq6_DTLzwjoHrPOA44=.082bd9ce-1fe4-43a8-8585-b8d90d09f2c8@github.com>

On Thu, 14 Nov 2024 17:02:49 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
>> 
>> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed tests

test/langtools/tools/javap/T6716452.java line 73:

> 71:                     error(mm + ": unexpected attribute found,"
> 72:                             + " expected " + c.getName()
> 73:                             + " found " + mm.attributes().get(index).attributeName());

Is this one redundant?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22107#discussion_r1842600288

From shade at openjdk.org  Thu Nov 14 17:11:45 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 17:11:45 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <WkErNXO5MrQfZF-9CItQHXVcjSJPX5dY1J9AJ1lUjKo=.0b58ad33-1bda-4364-8094-c6100099d4cf@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
 <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>
 <nNqG5StavW_fzll_TJz8JwR8myElGIoxGDyg8giuLQY=.56af70f1-0301-4169-b70f-b83dfec8f8f6@github.com>
 <WkErNXO5MrQfZF-9CItQHXVcjSJPX5dY1J9AJ1lUjKo=.0b58ad33-1bda-4364-8094-c6100099d4cf@github.com>
Message-ID: <t3Y8Pt8nU8EbLyPIdWrPWhKladUVmXBvGCVvIYkuAPI=.d0499e1c-c1ce-40df-9aae-66581a48d0f3@github.com>

On Thu, 14 Nov 2024 14:50:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> I was however thinking that it would only be pooled asymmetrically as some type of hystereses. So you pool when you remove a node (switch the head) and keep it far an arbitrary amount of removals. So it would only really waste memory for cleaners that have this behaviour that they keep adding and removing cleanable around a NODE_CAPACITY boundary.

I really do not want to make an improvement that is more complicated than it needs to be :) As it stands, current thing improves performance across the board, so chasing minor inefficiencies looks like venturing into diminishing returns territory. We can do this as the follow-up, if you want to explore that. I don't see clearly how this would work, and I would prefer to hold off more advanced heuristics in favor of simplicity here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2476972428

From asotona at openjdk.org  Thu Nov 14 17:12:55 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Nov 2024 17:12:55 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry [v3]
In-Reply-To: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
Message-ID: <3IKnLe_6l7xNYRdVphmiCfVEdvpKbL_u5iubSndVW9Y=.a05e4bb6-ee8b-4834-8cb7-519b845c5b04@github.com>

> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
> 
> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:

  more fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22107/files
  - new: https://git.openjdk.org/jdk/pull/22107/files/6fb11386..e9dbf2c2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22107&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22107&range=01-02

  Stats: 3 lines in 2 files changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22107.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22107/head:pull/22107

PR: https://git.openjdk.org/jdk/pull/22107

From asotona at openjdk.org  Thu Nov 14 17:12:56 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 14 Nov 2024 17:12:56 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry [v3]
In-Reply-To: <fZyXsLf2K0VCmtvTnczdVD_Zmrq6_DTLzwjoHrPOA44=.082bd9ce-1fe4-43a8-8585-b8d90d09f2c8@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
 <8D1Elkxg68xP-5YxU3wGd_iKeU_2MIfgZ_nD5jBvxRc=.78f647e5-aee5-4b2d-86bd-a461488f463f@github.com>
 <fZyXsLf2K0VCmtvTnczdVD_Zmrq6_DTLzwjoHrPOA44=.082bd9ce-1fe4-43a8-8585-b8d90d09f2c8@github.com>
Message-ID: <r2tI7EbDzsVdQgEEUypSIRTJAj-WvE9jdGCDdBhhOjc=.d2c6aa01-359a-48e0-93f3-27ff7d0a1ae7@github.com>

On Thu, 14 Nov 2024 17:04:55 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   more fixes
>
> test/langtools/tools/javap/T6716452.java line 73:
> 
>> 71:                     error(mm + ": unexpected attribute found,"
>> 72:                             + " expected " + c.getName()
>> 73:                             + " found " + mm.attributes().get(index).attributeName());
> 
> Is this one redundant?

Unfortunately no, toString includes Utf8Entry info.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22107#discussion_r1842605385

From rriggs at openjdk.org  Thu Nov 14 17:15:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 17:15:09 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v8]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <rP4srosaNcwLf66sd0XbLrLmQlGazYGVLSya9IsgI5g=.a4503d9f-b9ef-471d-b32b-cabb1bc12238@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Wrap long lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22041/files
  - new: https://git.openjdk.org/jdk/pull/22041/files/b8e8d420..bd823042

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=06-07

  Stats: 4 lines in 1 file changed: 1 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From rriggs at openjdk.org  Thu Nov 14 17:15:30 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 17:15:30 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
Message-ID: <ovgug48O8r4e4pEkLiIeDPkyK27AWwNxHbbpZNYJDD4=.9ce9c201-c255-46ad-838a-f0ab4c7acb7c@github.com>

On Thu, 14 Nov 2024 13:21:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
>> 
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
>> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
>> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
>> 
>> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
>> 
>> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64

Thanks for the updates.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22099#pullrequestreview-2436729530

From rriggs at openjdk.org  Thu Nov 14 17:19:02 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 17:19:02 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v9]
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <2L6AgFqUJgAKu8fmdDR2yiPaf3D3ijiEAYQ2H8_X7aE=.6c4011d3-1038-49ad-ba2f-6c4be612755b@github.com>

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Wrap more long lines

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22041/files
  - new: https://git.openjdk.org/jdk/pull/22041/files/bd823042..c67a2121

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22041&range=07-08

  Stats: 4 lines in 1 file changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22041/head:pull/22041

PR: https://git.openjdk.org/jdk/pull/22041

From shade at openjdk.org  Thu Nov 14 17:29:32 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 14 Nov 2024 17:29:32 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <WkErNXO5MrQfZF-9CItQHXVcjSJPX5dY1J9AJ1lUjKo=.0b58ad33-1bda-4364-8094-c6100099d4cf@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
 <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>
 <nNqG5StavW_fzll_TJz8JwR8myElGIoxGDyg8giuLQY=.56af70f1-0301-4169-b70f-b83dfec8f8f6@github.com>
 <WkErNXO5MrQfZF-9CItQHXVcjSJPX5dY1J9AJ1lUjKo=.0b58ad33-1bda-4364-8094-c6100099d4cf@github.com>
Message-ID: <g1Di9Mv0Mn5mCDObDyN6bFoUD2CsreIIpsj47khZBiw=.98ca9a1e-2f1e-424e-aedd-29e1834caf5c@github.com>

On Thu, 14 Nov 2024 14:50:21 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> That is probably correct. I was however thinking that it would only be pooled asymmetrically as some type of hystereses. So you pool when you remove a node (switch the head) and keep it far an arbitrary amount of removals. So it would only really waste memory for cleaners that have this behaviour that they keep adding and removing cleanable around a NODE_CAPACITY boundary.

I have been playing with [8343704-node-cache.txt](https://github.com/user-attachments/files/17753986/8343704-node-cache.txt) -- is that what you had in mind?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2477012092

From lancea at openjdk.org  Thu Nov 14 17:44:50 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 17:44:50 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v5]
In-Reply-To: <WDw6WO-9RwCsJiqg-318U_v2Dd4omv0-7mHXxWp_cNw=.dadeb973-9649-419d-a322-e9c5ec092dbe@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <WDw6WO-9RwCsJiqg-318U_v2Dd4omv0-7mHXxWp_cNw=.dadeb973-9649-419d-a322-e9c5ec092dbe@github.com>
Message-ID: <TeT9OHflJUVSo6Ah_358k4w9kU3Vy9A7cygTwLDPGdQ=.802aa986-30b8-421c-b5fc-91c32cbefb62@github.com>

On Thu, 14 Nov 2024 04:14:03 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
>> 
>> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
>> 
>> To summarize those discussions, we had concluded that:
>> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
>> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
>> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
>> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
>> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
>> 
>> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
>> 
>> I'll file a CSR shortly.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
> 
>  - merge latest from master branch
>  - update tests to match the new specification
>  - Stuart's review - update the close() and end() expectations
>  - Stuart's review - improve class level javadoc
>  - merge latest from master branch
>  - merge latest from master branch
>  - Chen's suggestion - improve code comment
>  - convert the tests to junit
>  - fix whitespace
>  - 8225763: Inflater and Deflater should implement AutoCloseable

HI Jai,

Thanks for tackling this and sticking with it.  I have few comments below which could be considered for both Deflater/Inflater

Also, extra credit for:

-  converting the CloseinflaterDeflaterTest to use junit from testNG
- converting TotalInOut to use junit from the older test structure

src/java.base/share/classes/java/util/zip/Deflater.java line 66:

> 64:  * usage with try-with-resources, this class implements {@link AutoCloseable}. The
> 65:  * {@link #close()} method of this class calls {@code end()} to clean up its
> 66:  * resources. Subclasses are responsible for the cleanup of resources

As part of the clarification, do we need to state the verbiage above regarding try-with-resources specifically?

I did a quick scan of some of the other classes implementing AutoClosable and did not see many cases of that in the documentation most likely due to that behavior is clear in the documentation for AutoClosable

src/java.base/share/classes/java/util/zip/Deflater.java line 878:

> 876:      * If this method is invoked multiple times, the subsequent calls are treated as a no-op.
> 877:      * Several other methods defined by this class will throw an {@link IllegalStateException}
> 878:      * if invoked on a closed {@code Deflater}.

All of the methods which call ensureOpen should either document that an IllegalStateException may be thrown or you could add it to the header of the class.

-------------

PR Review: https://git.openjdk.org/jdk/pull/19675#pullrequestreview-2436771806
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1842632446
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1842638400

From mullan at openjdk.org  Thu Nov 14 17:45:56 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 17:45:56 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v9]
In-Reply-To: <2L6AgFqUJgAKu8fmdDR2yiPaf3D3ijiEAYQ2H8_X7aE=.6c4011d3-1038-49ad-ba2f-6c4be612755b@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <2L6AgFqUJgAKu8fmdDR2yiPaf3D3ijiEAYQ2H8_X7aE=.6c4011d3-1038-49ad-ba2f-6c4be612755b@github.com>
Message-ID: <vHgXdZ8Qf0jEfy3l0RhjE6dJgj5uD50v9qWE9Ir1xHw=.ec2ed43d-23d8-493e-a4b6-eb03332ea77b@github.com>

On Thu, 14 Nov 2024 17:19:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap more long lines

Updates look good.

-------------

Marked as reviewed by mullan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22041#pullrequestreview-2436799939

From lancea at openjdk.org  Thu Nov 14 17:53:35 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 17:53:35 GMT
Subject: RFR: 8343982: Remove usage of security manager from ClassLoader
 and related classes [v2]
In-Reply-To: <Yzup9r6TYApQey2FJtWTUVJvOKNdsnX5FhUrSQmSvJE=.c5ea09f3-6daa-49fc-a2e8-4cbe4677ac08@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
 <Yzup9r6TYApQey2FJtWTUVJvOKNdsnX5FhUrSQmSvJE=.c5ea09f3-6daa-49fc-a2e8-4cbe4677ac08@github.com>
Message-ID: <Alj2KvNlnEfx5d40dcbokPLSZSzmqVX-XTkx9ZsIRiw=.43933abb-b7c8-4361-8f6c-992456268d0d@github.com>

On Thu, 14 Nov 2024 11:25:08 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
>> 
>> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains three additional commits since the last revision:
> 
>  - Change 2-arg findResource to use findResourceOnClassPath when finding resources on class path
>  - Merge branch 'master' into JDK-8343982
>  - Initial commit

looks good to me Alan

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22097#pullrequestreview-2436813682

From jvernee at openjdk.org  Thu Nov 14 17:55:00 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 14 Nov 2024 17:55:00 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <KV1layGMPS6nAXkTJyxLSh9KP8RbRHmlMGyFL43dm1c=.c905d8fa-2740-41e5-a1bd-e60a5295bff9@github.com>

On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

src/java.base/share/classes/jdk/internal/foreign/Utils.java line 316:

> 314:                 new BaseAndScale((int) Unsafe.ARRAY_LONG_BASE_OFFSET, Unsafe.ARRAY_LONG_INDEX_SCALE);
> 315:         public static final BaseAndScale DOUBLE =
> 316:                 new BaseAndScale((int) Unsafe.ARRAY_DOUBLE_BASE_OFFSET, Unsafe.ARRAY_DOUBLE_INDEX_SCALE);

I'd rather the `base` field be change to `long` instead of introducing cast here. Otherwise users of this class will have the same issue.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22095#discussion_r1842658935

From liach at openjdk.org  Thu Nov 14 17:59:33 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 17:59:33 GMT
Subject: Integrated: 8343064: ClassFormatError: Illegal class name from
 InnerClassLambdaMetafactory
In-Reply-To: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
References: <ZriAtIlPZyB2XLnkgUnr7piiZ0f8clj-ks7XWC3col0=.3e865d6a-f5bc-4732-8e2d-62f6ed96510c@github.com>
Message-ID: <1dWi5bXgKYHFB4FK1OYQ34tbnJNruE51P--iQF2mKxk=.83115526-d785-4dd2-9660-75222bfe3029@github.com>

On Tue, 5 Nov 2024 18:29:52 GMT, Chen Liang <liach at openjdk.org> wrote:

> After the ClassFile API migration, when serializable lambdas are requested for hidden class callers, illegal class name is generated for the serialization methods, which previously had legal yet unusable class names, as hidden classes cannot be described by a `CONSTANT_Class_info`.
> 
> This patch restores a similar older behavior of using legal yet unusable class names.  Previously, the invalid `.` in hidden class names was replaced by a `/` as if a package separator; this patch changes it to a `_` like that in the generated lambda's class name.
> 
> The bug report shows some unintended and erroneous usages of `LambdaMetafactory`.  To clarify and to persuade against misuse, I added a paragraph of API notes to `LambdaMetafactory`, describing the impact of this API being designed to support Java language features.  In particular, I used the scenario where people assumed LMf generates weak hidden classes, which happened in this issue report and in #12493, that misuse can lead to resource leaks.

This pull request has now been integrated.

Changeset: 681a57f9
Author:    Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/681a57f96099a4e434fef0f37fa9cd248357791f
Stats:     116 lines in 3 files changed: 113 ins; 0 del; 3 mod

8343064: ClassFormatError: Illegal class name from InnerClassLambdaMetafactory

Reviewed-by: jvernee

-------------

PR: https://git.openjdk.org/jdk/pull/21912

From acobbs at openjdk.org  Thu Nov 14 18:10:45 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Thu, 14 Nov 2024 18:10:45 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v3]
In-Reply-To: <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
Message-ID: <OFQOcQ2Mwtzd4U7xNZS3dBixOxqWIXcAxolL8SsW4rY=.e5b6220d-8191-4a2b-a618-d62634ba948b@github.com>

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
>> 
>> if no such entry exists, returns the entry for the least key greater than the specified key;
>> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
>> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.
>
> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8343125 : Empty tree case explicitly specified.

Looks good to me too.

-------------

Marked as reviewed by acobbs (Committer).

PR Review: https://git.openjdk.org/jdk/pull/21729#pullrequestreview-2436852730

From duke at openjdk.org  Thu Nov 14 18:19:21 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Thu, 14 Nov 2024 18:19:21 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <WGlVhdcTdMOp6M5Y1IajQ72wu6nD7uI-8Pz8-GiGims=.75b1623f-2c16-4656-a784-90cb0bad8f69@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

Test failure again seems unrelated. Including the specific error here though, for completeness:


2024-11-14T17:47:36.4324360Z ACTION: main -- Error. Program `/Users/runner/work/jdk/jdk/bundles/jdk/jdk-24.jdk/Contents/Home/bin/java' timed out (timeout set to 480000ms, elapsed time including timeout handling was 708638ms).
2024-11-14T17:47:36.4327170Z REASON: User specified action: run main/othervm GetStackTraceALotWhenBlocking 500000 
2024-11-14T17:47:36.4328300Z TIME:   708.661 seconds
2024-11-14T17:47:36.4328770Z messages:
2024-11-14T17:47:36.4329310Z command: main GetStackTraceALotWhenBlocking 500000
2024-11-14T17:47:36.4330560Z reason: User specified action: run main/othervm GetStackTraceALotWhenBlocking 500000 
2024-11-14T17:47:36.4331740Z started: Thu Nov 14 17:35:47 UTC 2024
2024-11-14T17:47:36.4332550Z Mode: othervm [/othervm specified]
2024-11-14T17:47:36.4333480Z Additional options from @modules: --add-modules jdk.management
2024-11-14T17:47:36.4334350Z Timeout information:
2024-11-14T17:47:36.4334890Z --- Timeout information end.
2024-11-14T17:47:36.4335460Z finished: Thu Nov 14 17:47:36 UTC 2024
2024-11-14T17:47:36.4336100Z elapsed time (seconds): 708.661
2024-11-14T17:47:36.4336660Z configuration:
2024-11-14T17:47:36.4337320Z Boot Layer
2024-11-14T17:47:36.4338200Z   add modules: jdk.management
2024-11-14T17:47:36.4338680Z 
2024-11-14T17:47:36.4338990Z STDOUT:
2024-11-14T17:47:36.4358660Z 2024-11-14T17:38:27.326795Z => 10000 of 500000
2024-11-14T17:47:36.4360180Z 2024-11-14T17:38:41.640658Z => 20000 of 500000
2024-11-14T17:47:36.4361400Z 2024-11-14T17:38:49.756549Z => 30000 of 500000
2024-11-14T17:47:36.4362630Z 2024-11-14T17:38:57.493942Z => 40000 of 500000
2024-11-14T17:47:36.4363870Z 2024-11-14T17:39:08.010237Z => 50000 of 500000
2024-11-14T17:47:36.4365080Z 2024-11-14T17:39:16.328399Z => 60000 of 500000
2024-11-14T17:47:36.4366280Z 2024-11-14T17:39:24.093577Z => 70000 of 500000
2024-11-14T17:47:36.4367490Z 2024-11-14T17:39:32.249028Z => 80000 of 500000
2024-11-14T17:47:36.4369570Z 2024-11-14T17:39:40.332657Z => 90000 of 500000
2024-11-14T17:47:36.4370770Z 2024-11-14T17:39:48.896585Z => 100000 of 500000
2024-11-14T17:47:36.4371980Z 2024-11-14T17:39:56.202818Z => 110000 of 500000
2024-11-14T17:47:36.4373300Z 2024-11-14T17:40:03.124551Z => 120000 of 500000
2024-11-14T17:47:36.4374380Z 2024-11-14T17:40:09.787697Z => 130000 of 500000
2024-11-14T17:47:36.4375350Z 2024-11-14T17:40:18.527866Z => 140000 of 500000
2024-11-14T17:47:36.4376150Z 2024-11-14T17:40:25.597202Z => 150000 of 500000
2024-11-14T17:47:36.4376920Z 2024-11-14T17:40:33.003481Z => 160000 of 500000
2024-11-14T17:47:36.4377700Z 2024-11-14T17:40:41.028630Z => 170000 of 500000
2024-11-14T17:47:36.4378480Z 2024-11-14T17:40:47.934187Z => 180000 of 500000
2024-11-14T17:47:36.4379260Z 2024-11-14T17:40:55.464061Z => 190000 of 500000
2024-11-14T17:47:36.4380040Z 2024-11-14T17:41:02.558836Z => 200000 of 500000
2024-11-14T17:47:36.4380950Z 2024-11-14T17:41:09.825570Z => 210000 of 500000
2024-11-14T17:47:36.4382430Z 2024-11-14T17:41:17.577988Z => 220000 of 500000
2024-11-14T17:47:36.4383210Z 2024-11-14T17:41:26.589768Z => 230000 of 500000
2024-11-14T17:47:36.4383980Z 2024-11-14T17:41:33.137518Z => 240000 of 500000
2024-11-14T17:47:36.4384760Z 2024-11-14T17:41:42.334781Z => 250000 of 500000
2024-11-14T17:47:36.4385530Z 2024-11-14T17:41:51.968771Z => 260000 of 500000
2024-11-14T17:47:36.4386300Z 2024-11-14T17:41:58.428868Z => 270000 of 500000
2024-11-14T17:47:36.4387970Z 2024-11-14T17:42:09.241304Z => 280000 of 500000
2024-11-14T17:47:36.4389480Z 2024-11-14T17:42:15.361728Z => 290000 of 500000
2024-11-14T17:47:36.4390860Z 2024-11-14T17:42:21.300814Z => 300000 of 500000
2024-11-14T17:47:36.4392280Z 2024-11-14T17:42:28.007759Z => 310000 of 500000
2024-11-14T17:47:36.4393110Z 2024-11-14T17:42:34.121006Z => 320000 of 500000
2024-11-14T17:47:36.4393920Z 2024-11-14T17:42:41.597375Z => 330000 of 500000
2024-11-14T17:47:36.4394720Z 2024-11-14T17:42:47.815044Z => 340000 of 500000
2024-11-14T17:47:36.4395540Z 2024-11-14T17:42:53.644225Z => 350000 of 500000
2024-11-14T17:47:36.4396340Z 2024-11-14T17:42:59.640370Z => 360000 of 500000
2024-11-14T17:47:36.4397140Z 2024-11-14T17:43:05.704448Z => 370000 of 500000
2024-11-14T17:47:36.4397940Z 2024-11-14T17:43:11.992982Z => 380000 of 500000
2024-11-14T17:47:36.4398750Z 2024-11-14T17:43:18.333571Z => 390000 of 500000
2024-11-14T17:47:36.4399560Z 2024-11-14T17:43:24.272030Z => 400000 of 500000
2024-11-14T17:47:36.4400900Z 2024-11-14T17:43:30.751238Z => 410000 of 500000
2024-11-14T17:47:36.4402380Z 2024-11-14T17:43:37.258332Z => 420000 of 500000
2024-11-14T17:47:36.4403200Z 2024-11-14T17:43:43.632902Z => 430000 of 500000
2024-11-14T17:47:36.4403920Z Timeout signalled after 480 seconds
2024-11-14T17:47:36.4404660Z 2024-11-14T17:43:57.423379Z => 440000 of 500000
2024-11-14T17:47:36.4405470Z 2024-11-14T17:44:28.892592Z => 450000 of 500000
2024-11-14T17:47:36.4406120Z STDERR:
2024-11-14T17:47:36.4406480Z rerun:
2024-11-14T17:47:36.4407780Z cd /Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/scratch/0 && \
2024-11-14T17:47:36.4409270Z DOCS_JDK_IMAGE_DIR= \
2024-11-14T17:47:36.4409780Z HOME=/Users/runner \
2024-11-14T17:47:36.4410300Z LANG=en_US.UTF-8 \
2024-11-14T17:47:36.4410750Z LC_ALL=C \
2024-11-14T17:47:36.4411230Z LC_CTYPE=en_US.UTF-8 \
2024-11-14T17:47:36.4411750Z PATH=/bin:/usr/bin:/usr/sbin \
2024-11-14T17:47:36.4412500Z TEST_IMAGE_DIR=/Users/runner/work/jdk/jdk/bundles/tests \
2024-11-14T17:47:36.4419930Z CLASSPATH=/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/1/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking_id0.d:/Users/runner/work/jdk/jdk/test/jdk/java/lang/Thread/virtual/stress:/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/1/test/lib:/Users/runner/work/jdk/jdk/test/lib:/Users/runner/work/jdk/jdk/jtreg/installed/lib/javatest.jar:/Users/runner/work/jdk/jdk/jtreg/installed/lib/jtreg.jar \
2024-11-14T17:47:36.4428520Z     /Users/runner/work/jdk/jdk/bundles/jdk/jdk-24.jdk/Contents/Home/bin/java \
2024-11-14T17:47:36.4433500Z         -Dtest.vm.opts='-Xmx768m -XX:MaxRAMPercentage=12.5 -Dtest.boot.jdk=/Users/runner/work/jdk/jdk/bootjdk/jdk -Djava.io.tmpdir=/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/tmp -ea -esa' \
2024-11-14T17:47:36.4440820Z         -Dtest.tool.vm.opts='-J-Xmx768m -J-XX:MaxRAMPercentage=12.5 -J-Dtest.boot.jdk=/Users/runner/work/jdk/jdk/bootjdk/jdk -J-Djava.io.tmpdir=/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/tmp -J-ea -J-esa' \
2024-11-14T17:47:36.4444840Z         -Dtest.compiler.opts= \
2024-11-14T17:47:36.4446110Z         -Dtest.java.opts=-XX:-CreateCoredumpOnCrash \
2024-11-14T17:47:36.4448100Z         -Dtest.jdk=/Users/runner/work/jdk/jdk/bundles/jdk/jdk-24.jdk/Contents/Home \
2024-11-14T17:47:36.4450120Z         -Dcompile.jdk=/Users/runner/work/jdk/jdk/bundles/jdk/jdk-24.jdk/Contents/Home \
2024-11-14T17:47:36.4451380Z         -Dtest.timeout.factor=4.0 \
2024-11-14T17:47:36.4452670Z         -Dtest.nativepath=/Users/runner/work/jdk/jdk/bundles/tests/jdk/jtreg/native \
2024-11-14T17:47:36.4453960Z         -Dtest.root=/Users/runner/work/jdk/jdk/test/jdk \
2024-11-14T17:47:36.4455370Z         -Dtest.name=java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java#id0 \
2024-11-14T17:47:36.4458490Z         -Dtest.file=/Users/runner/work/jdk/jdk/test/jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking.java \
2024-11-14T17:47:36.4460760Z         -Dtest.src=/Users/runner/work/jdk/jdk/test/jdk/java/lang/Thread/virtual/stress \
2024-11-14T17:47:36.4463030Z         -Dtest.src.path=/Users/runner/work/jdk/jdk/test/jdk/java/lang/Thread/virtual/stress:/Users/runner/work/jdk/jdk/test/lib \
2024-11-14T17:47:36.4466620Z         -Dtest.classes=/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/1/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking_id0.d \
2024-11-14T17:47:36.4472620Z         -Dtest.class.path=/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/1/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking_id0.d:/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/1/test/lib \
2024-11-14T17:47:36.4481720Z         -Dtest.class.path.prefix=/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/1/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking_id0.d:/Users/runner/work/jdk/jdk/test/jdk/java/lang/Thread/virtual/stress:/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/classes/1/test/lib \
2024-11-14T17:47:36.4486950Z         -Dtest.modules=jdk.management \
2024-11-14T17:47:36.4487740Z         --add-modules jdk.management \
2024-11-14T17:47:36.4488440Z         -Xmx768m \
2024-11-14T17:47:36.4489010Z         -XX:MaxRAMPercentage=12.5 \
2024-11-14T17:47:36.4490150Z         -Dtest.boot.jdk=/Users/runner/work/jdk/jdk/bootjdk/jdk \
2024-11-14T17:47:36.4492140Z         -Djava.io.tmpdir=/Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/tmp \
2024-11-14T17:47:36.4494970Z         -ea \
2024-11-14T17:47:36.4495720Z         -esa \
2024-11-14T17:47:36.4496690Z         -XX:-CreateCoredumpOnCrash \
2024-11-14T17:47:36.4498620Z         -Djava.library.path=/Users/runner/work/jdk/jdk/bundles/tests/jdk/jtreg/native \
2024-11-14T17:47:36.4504150Z         com.sun.javatest.regtest.agent.MainWrapper /Users/runner/work/jdk/jdk/build/run-test-prebuilt/test-support/jtreg_test_jdk_tier1_part1/java/lang/Thread/virtual/stress/GetStackTraceALotWhenBlocking_id0.d/main.0.jta 500000
2024-11-14T17:47:36.4507990Z 
2024-11-14T17:47:36.4511330Z TEST RESULT: Error. Program `/Users/runner/work/jdk/jdk/bundles/jdk/jdk-24.jdk/Contents/Home/bin/java' timed out (timeout set to 480000ms, elapsed time including timeout handling was 708638ms).
2024-11-14T17:47:36.4516420Z --------------------------------------------------

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2477111143

From jbhateja at openjdk.org  Thu Nov 14 18:24:59 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 14 Nov 2024 18:24:59 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v5]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions incorporated.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21244/files
  - new: https://git.openjdk.org/jdk/pull/21244/files/43320063..84f2e04f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=03-04

  Stats: 44 lines in 2 files changed: 12 ins; 14 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/21244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21244/head:pull/21244

PR: https://git.openjdk.org/jdk/pull/21244

From jbhateja at openjdk.org  Thu Nov 14 18:24:59 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 14 Nov 2024 18:24:59 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <chcOYl_NgVxCgglUI_Nt-nAw1HFLT6td8ab4K_aLfJU=.9bb5ca76-4a7c-421b-9dec-5206bb411b37@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
 <IwXC8gTLD1LKFMu6DpulYxgbt5Zp1WTaL6Cc19V2dJw=.80a1e2a3-178b-4f10-9431-ea41e1c3ddd8@github.com>
 <chcOYl_NgVxCgglUI_Nt-nAw1HFLT6td8ab4K_aLfJU=.9bb5ca76-4a7c-421b-9dec-5206bb411b37@github.com>
Message-ID: <Sc6yil7WCcaLjLTaeHY85VdnL41GX7yWqLr9Hlkqnbs=.60e9cae7-3ee6-4dee-a9f7-f4622bdf06bc@github.com>

On Tue, 12 Nov 2024 21:49:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I don't see a compelling reason to do so. IMO matcher functionality is more than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` + `has_int_inputs()` predicate. For `MulUIVL` you additionally do input rewiring (using `forward_masked_input`), but (1) `AndV src (Replicate 0xFFFFFFFF))` operands can be easily detected on matcher side (with an extra AD instruction); and (2) such optimization is limited because it is valid only for `0xFFFFFFFF` case while `has_uint_inputs() == true` for `C <= 0xFFFFFFFF`.
>>> 
>>> So, IMO `MulIVL` and `MulUIVL` nodes just add noise in Ideal graph without improving situation during matching.
>> 
>> Hi @iwanowww ,
>> Problem occurs only if AndV gets shared; in such a case, matcher will not be able to identify the constrained multiplication pattern and absorb the masking pattern. Specialized IR overrules such limitations and shields the pattern from downstream optimization passes, thereby removing any non-determinism. In addition, it facilitates forwarding inputs to the multiplier, the new IR is explicit in its semantics of considering only lower doublewords of quadword lanes for multiplication, hence we can safely save emitting redundant input masking instructions. We already have specialized IR nodes like MulAddVS2VINode and I see these new IR nodes similar to it.
>
> @jatin-bhateja in case when `AndV` is shared, it can't be eliminated unless all users absorb it. For such cases, matcher can perform adhoc node cloning, but in this particular case it looks like an overkill either way. IMO the pattern is too niche to focus on it (either to justify input forwarding or adhoc handling on matcher side). 
> 
> It's good you mentioned `MulAddVS2VI`. On one hand, VNNI operations are more complex (similar to FMA), so such complexity *may* be justified there. On the other hand, it doesn't look like VNNI support in C2 age well. It is tied to auto-vectorizer and, by now, Vector API doesn't benefit from it. So, instead of doubling down on `MulAddVS2VI` path, I'd prefer to leave it aside and reimplement it later in a more maintainable manner.

Thanks @iwanowww , your comments have been addressed.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2477119879

From jbhateja at openjdk.org  Thu Nov 14 18:25:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 14 Nov 2024 18:25:00 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v4]
In-Reply-To: <Re_yhAsBMuDkfa1MYOCpTvHupP999c-uArmNN4PXh2M=.c6cc9d4c-671f-4119-9c43-07f90888c366@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <6fxu6YabwpKc13hCZ7Aw46C02K68kozOCBZY3Rn8R8g=.c42f98dc-c253-4972-b2a5-ea8ff5e6061b@github.com>
 <Re_yhAsBMuDkfa1MYOCpTvHupP999c-uArmNN4PXh2M=.c6cc9d4c-671f-4119-9c43-07f90888c366@github.com>
Message-ID: <OA6MCcXv374xiY4tDvCozFM53EUPBnmiDskopMd25QE=.52d9b81c-a28f-4ab6-ab5c-675aa5ecea8f@github.com>

On Thu, 14 Nov 2024 02:52:26 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>> Jatin Bhateja has refreshed the contents of this pull request, and previous commits have been removed. Incremental views are not available. The pull request now contains seven commits:
>> 
>>  - Removing target specific hooks
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>>  - Review resoultions
>>  - Merge branch 'master' of http://github.com/openjdk/jdk into JDK-8341137
>>  - Handle new I2L pattern, IR tests, Rewiring pattern inputs to MulVL further optimizes JIT code
>>  - Review resolutions
>>  - 8341137: Optimize long vector multiplication using x86 VPMULUDQ instruction
>
> test/hotspot/jtreg/compiler/vectorapi/VectorMultiplyOpt.java line 105:
> 
>> 103:             LongVector vsrc2 = LongVector.fromArray(LSP, lsrc2, i);
>> 104:             vsrc1.lanewise(VectorOperators.AND, 0xFFFFFFFFL)
>> 105:                  .lanewise(VectorOperators.MUL, vsrc2.lanewise(VectorOperators.AND, 0xFFFFFFFFL))
> 
> It would be nice to randomize the constants (masks and shifts) to improve test coverage.

Pure randomization will ditch the pattern detection since we expect a constant, I have now varied the constant mask in different test points.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1842704791

From iris at openjdk.org  Thu Nov 14 18:43:38 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 14 Nov 2024 18:43:38 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <hD8dWtCFGyH64MyqGEoAP1aMt9E32eY7_ArUkRi0cT4=.c18c2075-5daf-4cda-9a81-2f968a343734@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

Thanks for updating all the licenses to GPL.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2436927254

From bpb at openjdk.org  Thu Nov 14 19:16:34 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 14 Nov 2024 19:16:34 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v9]
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <gBxCkZdy0V-EzOafhUmS0SojDfEi3mkXdXyW6eran4Q=.1edac68c-b481-49de-a86b-50c1400dc870@github.com>

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Merge
 - 8343039: Change "resizble" comment in BOS
 - 8343039: Remove failing getDeclaredField call from test java/lang/ProcessBuilder/Basic.java
 - 8343039: Remove java.base/jdk.internal.misc from @modules in test java/lang/ProcessBuilder/Basic.java
 - 8343039: Remove InternalLock reference from java/lang/ProcessBuilder/Basic.java
 - 8343039: Address reviewer comments
 - 8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof
 - 8343039: Remove use of InternalLock from Stream{De,En}coder and throwable; remove InternalLock class; address comments on BIS and BOS
 - 8343039: Remove jdk.internal.misc.InternalLock and usages from java.io

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22048/files
  - new: https://git.openjdk.org/jdk/pull/22048/files/15bf969a..1ed0043d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22048&range=07-08

  Stats: 86500 lines in 2307 files changed: 11355 ins; 68476 del; 6669 mod
  Patch: https://git.openjdk.org/jdk/pull/22048.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22048/head:pull/22048

PR: https://git.openjdk.org/jdk/pull/22048

From mullan at openjdk.org  Thu Nov 14 19:25:47 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 19:25:47 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v3]
In-Reply-To: <J8U8nHjdYG2RZafj32txzwpS0gm4iSx7kWFd7IbsOfQ=.0faf9322-ef63-4d1c-b0a9-afc31c1045f3@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <J8U8nHjdYG2RZafj32txzwpS0gm4iSx7kWFd7IbsOfQ=.0faf9322-ef63-4d1c-b0a9-afc31c1045f3@github.com>
Message-ID: <Rh3Zab3deNDgngmR-7_ZRR7FHN-5ZfovAnOYa1Tml0c=.fa6c605b-a017-4858-98de-1cf4ccbe7b2b@github.com>

On Thu, 14 Nov 2024 17:01:48 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
>> 
>> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
>> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
>> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
>> 
>> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
>> 
>> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert catching of NoSuchFileException in expectedDefaultOwner and expectedDefaultGroup
>  - Remove @SuppressWarnings("removal")

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22101#pullrequestreview-2437010891

From mullan at openjdk.org  Thu Nov 14 19:25:49 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 19:25:49 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
 <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>
Message-ID: <3qJgc0FCBG3f5VahZoeVLwjAi6hMEPIkyrx-8UQI4b0=.0199cedb-d8c7-4839-a10f-9765325d845a@github.com>

On Thu, 14 Nov 2024 16:56:00 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> test/jdk/jdk/nio/zipfs/TestPosix.java line 236:
>> 
>>> 234:             }
>>> 235:             return zfpv.readAttributes().group().getName();
>>> 236:         } catch (UnsupportedOperationException | NoSuchFileException e) {
>> 
>> In the prior code, I think `NoSuchFileException` would have been the cause of the `SecurityException`, so the code would have returned `null`. Just wondering why you changed it here.
>
> Interesting catch..
> 
> My understanding is that the purpose of `expectedDefaultOwner` and `expectedDefaultGroup` is to mimic the behavior of `ZipFileSystem:initOwner` and `ZipFileSystem::initGroup`.
> 
> The ZipFileSystem methods both check for `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, while the TestPosix expect methods do not. This is why I added them, to make them consistent with the implementation code.
> 
> This inconsistency is a however a preexisting issue. Attempting to fixing them here might just clutter this review. So I have reverted the catch for `NoSuchFileException`.

Ok, but your change did not check `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, it just checked if the exception was `NoSuchFileException`.

In any case, I agree, best to preserve the existing code as much as possible.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842774624

From liach at openjdk.org  Thu Nov 14 19:25:50 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 19:25:50 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <OEhAASkD2EF-xWiIjbpHxvL1kJpcYEiM3EejkFEPWTc=.e351d5ac-c583-432c-9a21-fe55164c5256@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

This new hook does not affect the early startup of a simple HelloWorld application.  Also tier 1-3 tests pass.

Re github test error: It seems something is wrong with github action for mac so it fails spontaneously about 50% of the time.  You are fine.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19702#pullrequestreview-2437010929
PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2477234407

From vlivanov at openjdk.org  Thu Nov 14 19:35:55 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 14 Nov 2024 19:35:55 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v5]
In-Reply-To: <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
Message-ID: <do6YfxjH9HzQvmmhX6qrAfXmkja_wofmLT1em2L2a3g=.0f6f17b0-7b3d-4f98-89cd-c847fc6bc3a5@github.com>

On Thu, 14 Nov 2024 18:24:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

Looks good. I'll submit it for testing.

src/hotspot/cpu/x86/x86.ad line 6176:

> 6174: %}
> 6175: 
> 6176: 

Redundant new line.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2437027064
PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1842785430

From eirbjo at openjdk.org  Thu Nov 14 19:40:12 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 19:40:12 GMT
Subject: RFR: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
 [v2]
In-Reply-To: <3qJgc0FCBG3f5VahZoeVLwjAi6hMEPIkyrx-8UQI4b0=.0199cedb-d8c7-4839-a10f-9765325d845a@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
 <MpXq4cvNg_A61VF7kivocme9a_2LDqtZChKVRHDRhZA=.8a9da539-9da5-4e77-8c09-bc3cceb75279@github.com>
 <zaUhlUcxg4k_Qjt1rIIJS1ZzwNCvSvsFJw3NSwG1CQE=.35b5047a-8ba4-4a28-9854-f79fd3813e9d@github.com>
 <qMAE92om7fA7QHY5nJ5ID7y-armQZtNLc2jUVnjLHaA=.fdcac53d-b498-421e-bc12-bc6083b25afc@github.com>
 <3qJgc0FCBG3f5VahZoeVLwjAi6hMEPIkyrx-8UQI4b0=.0199cedb-d8c7-4839-a10f-9765325d845a@github.com>
Message-ID: <GKXm1GuyfXwrh759_RyW7qWylxOfxtoTULnR9hZW3CI=.dd123356-31c0-4bc5-9ddb-50d0f7e3b60e@github.com>

On Thu, 14 Nov 2024 19:21:32 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Ok, but your change did not check `UnsupportedOperationException.getCause() instanceof NoSuchFileException`, it just checked if the exception was `NoSuchFileException`.

For the record, there was a typo in my comment, I meant to say `PrivilegedActionException. getCause() instanceof ..`.

...but yes, this doesn't matter now that we agree to not fix this code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22101#discussion_r1842793434

From aturbanov at openjdk.org  Thu Nov 14 19:41:47 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 14 Nov 2024 19:41:47 GMT
Subject: RFR: 8344246: Unnecessary Hashtable usage in EventSupport.notifiers
Message-ID: <DyA3eTtyK0cAhwf_o-GTkHWMai75huS45AP1TTdVo5w=.6ec6de4f-1ad2-498f-a64e-f0dec465a306@github.com>

The field `com.sun.jndi.ldap.EventSupport#notifiers` is always accessed under `lock`. It means extra synchronization from `Hashtable` is not needed.
Subtle difference in Hashtable vs Hashmap behavior is that Hashtable doesn't allow `null` keys and `null` values. I've checked all usages of it - only non-null keys and values are put into it. So, replacement is safe.

One thing which was suspicous for me is `null` check of value in the `com.sun.jndi.ldap.EventSupport#removeNamingListener` method:
https://github.com/openjdk/jdk/blob/b54bd824b59b6b5dff9278ddebab4e9e2dfaf57b/src/java.naming/share/classes/com/sun/jndi/ldap/EventSupport.java#L230-L235
The condition `notifier != null` is always `true`.

-------------

Commit messages:
 - [PATCH] Unnecessary Hashtable usage in EventSupport.notifiers

Changes: https://git.openjdk.org/jdk/pull/21894/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21894&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344246
  Stats: 5 lines in 1 file changed: 0 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21894.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21894/head:pull/21894

PR: https://git.openjdk.org/jdk/pull/21894

From mullan at openjdk.org  Thu Nov 14 19:42:52 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 19:42:52 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
Message-ID: <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>

On Thu, 14 Nov 2024 13:21:33 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
>> 
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
>> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
>> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
>> 
>> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
>> 
>> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64

Looks good, just 2 small comments.

src/java.base/share/classes/java/util/jar/JarFile.java line 182:

> 180:         }
> 181:         RUNTIME_VERSION = Runtime.Version.parse(Integer.toString(runtimeVersion));
> 182:         String enableMultiRelease = System.getProperty("jdk.util.jar.enableMultiRelease", "true");

The line is a little long, can you break it in 2 lines?

src/java.base/share/classes/java/util/zip/ZipOutputStream.java line 59:

> 57:      * some in jdk7.
> 58:      */
> 59:     private static final boolean inhibitZip64 = Boolean.getBoolean("jdk.util.zip.inhibitZip64");

The line is a little long, can you break it in 2 lines?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22099#pullrequestreview-2437022553
PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842786359
PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842782569

From vlivanov at openjdk.org  Thu Nov 14 19:45:29 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 14 Nov 2024 19:45:29 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v5]
In-Reply-To: <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
Message-ID: <5cavGY87A5jPQUOnM6aDR1QyceunoZXGqyeu24AxVEU=.df5700cf-19e3-4a8d-84e7-784d3ee0c61d@github.com>

On Thu, 14 Nov 2024 18:24:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

test/hotspot/jtreg/compiler/vectorapi/VectorMultiplyOpt.java line 125:

> 123:             LongVector vsrc1 = LongVector.fromArray(LSP, lsrc1, i);
> 124:             LongVector vsrc2 = LongVector.fromArray(LSP, lsrc2, i);
> 125:             vsrc1.lanewise(VectorOperators.AND, 0xFFFFFFL)

Alternatively, you could populate the constants in randomized manner and put them into static final fields during class initialization. Then just load them from there in test code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21244#discussion_r1842799093

From eirbjo at openjdk.org  Thu Nov 14 19:48:21 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 19:48:21 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
 <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>
Message-ID: <WJ1_sS9Vkgqp0G4T6eQ2MIl45-3eHKoJDMSeXNnQG_k=.027ba784-1c40-4e38-8b60-8c005a140d37@github.com>

On Thu, 14 Nov 2024 19:30:58 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64
>
> src/java.base/share/classes/java/util/jar/JarFile.java line 182:
> 
>> 180:         }
>> 181:         RUNTIME_VERSION = Runtime.Version.parse(Integer.toString(runtimeVersion));
>> 182:         String enableMultiRelease = System.getProperty("jdk.util.jar.enableMultiRelease", "true");
> 
> The line is a little long, can you break it in 2 lines?

See review comments from @RogerRiggs:

https://github.com/openjdk/jdk/pull/22099#pullrequestreview-2435969401
https://github.com/openjdk/jdk/pull/22099#discussion_r1842150753

where the folding of these lines into one was suggested.

I'm fine either way, but I agree the lines are somewhat long. It makes the longest line in `ZipOutputStream` and the fifth longest line in `JarFile`.

Can you coordinate with @RogerRiggs and let me know what is the preferred style here? Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842802846

From alanb at openjdk.org  Thu Nov 14 19:51:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 14 Nov 2024 19:51:22 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v9]
In-Reply-To: <gBxCkZdy0V-EzOafhUmS0SojDfEi3mkXdXyW6eran4Q=.1edac68c-b481-49de-a86b-50c1400dc870@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <gBxCkZdy0V-EzOafhUmS0SojDfEi3mkXdXyW6eran4Q=.1edac68c-b481-49de-a86b-50c1400dc870@github.com>
Message-ID: <7BRMjO1L75odKnpGj5I7-x2uaoZnnPCeOflFApD6FXg=.3d04ef44-b9df-413a-a41b-3045a28fbff0@github.com>

On Thu, 14 Nov 2024 19:16:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge
>  - 8343039: Change "resizble" comment in BOS
>  - 8343039: Remove failing getDeclaredField call from test java/lang/ProcessBuilder/Basic.java
>  - 8343039: Remove java.base/jdk.internal.misc from @modules in test java/lang/ProcessBuilder/Basic.java
>  - 8343039: Remove InternalLock reference from java/lang/ProcessBuilder/Basic.java
>  - 8343039: Address reviewer comments
>  - 8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof
>  - 8343039: Remove use of InternalLock from Stream{De,En}coder and throwable; remove InternalLock class; address comments on BIS and BOS
>  - 8343039: Remove jdk.internal.misc.InternalLock and usages from java.io

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22048#pullrequestreview-2437061274

From liach at openjdk.org  Thu Nov 14 19:52:22 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 19:52:22 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v3]
In-Reply-To: <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
Message-ID: <Lx52GI6-K3giQrcO2ijadq-i6bqw7ZOCXoXH5DSFozI=.647a82bb-db4e-431b-b697-da9e96873031@github.com>

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
>> 
>> if no such entry exists, returns the entry for the least key greater than the specified key;
>> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
>> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.
>
> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8343125 : Empty tree case explicitly specified.

@stuart-marks Why do we need a CSR for comments on a non-API (package private) method?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2477279440

From smarks at openjdk.org  Thu Nov 14 19:52:22 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Thu, 14 Nov 2024 19:52:22 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v3]
In-Reply-To: <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
Message-ID: <jER0ROvJGuu866Z2ODrx-PVXi1wF1hHY13wGJ6MkWhM=.f6946960-d477-4379-925a-7701d668fdb4@github.com>

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
>> 
>> if no such entry exists, returns the entry for the least key greater than the specified key;
>> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
>> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.
>
> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8343125 : Empty tree case explicitly specified.

Sorry, I thought this was changing the specifications. I didn't realize it was an internal method.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2477280219

From lancea at openjdk.org  Thu Nov 14 19:54:30 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 19:54:30 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <WJ1_sS9Vkgqp0G4T6eQ2MIl45-3eHKoJDMSeXNnQG_k=.027ba784-1c40-4e38-8b60-8c005a140d37@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
 <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>
 <WJ1_sS9Vkgqp0G4T6eQ2MIl45-3eHKoJDMSeXNnQG_k=.027ba784-1c40-4e38-8b60-8c005a140d37@github.com>
Message-ID: <kswQ-s3iBxzxwU62FqlHpflI7yjtFfLfHqm41YQhs3Q=.ffc805ec-9ccf-43d7-aef2-f991a56c6c41@github.com>

On Thu, 14 Nov 2024 19:45:27 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/jar/JarFile.java line 182:
>> 
>>> 180:         }
>>> 181:         RUNTIME_VERSION = Runtime.Version.parse(Integer.toString(runtimeVersion));
>>> 182:         String enableMultiRelease = System.getProperty("jdk.util.jar.enableMultiRelease", "true");
>> 
>> The line is a little long, can you break it in 2 lines?
>
> See review comments from @RogerRiggs:
> 
> https://github.com/openjdk/jdk/pull/22099#pullrequestreview-2435969401
> https://github.com/openjdk/jdk/pull/22099#discussion_r1842150753
> 
> where the folding of these lines into one was suggested.
> 
> I'm fine either way, but I agree the lines are somewhat long. It makes the longest line in `ZipOutputStream` and the fifth longest line in `JarFile`.
> 
> Can you coordinate with @RogerRiggs and let me know what is the preferred style here? Thanks!

As long as the line in your ide is  around 80 characters or less you are good to go.  If it is say 100 bytes so you have to scroll, that is when I would fold the line.

I think you are OK here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842809954

From eirbjo at openjdk.org  Thu Nov 14 20:05:18 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 20:05:18 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <kswQ-s3iBxzxwU62FqlHpflI7yjtFfLfHqm41YQhs3Q=.ffc805ec-9ccf-43d7-aef2-f991a56c6c41@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
 <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>
 <WJ1_sS9Vkgqp0G4T6eQ2MIl45-3eHKoJDMSeXNnQG_k=.027ba784-1c40-4e38-8b60-8c005a140d37@github.com>
 <kswQ-s3iBxzxwU62FqlHpflI7yjtFfLfHqm41YQhs3Q=.ffc805ec-9ccf-43d7-aef2-f991a56c6c41@github.com>
Message-ID: <2AATsf_rqRhnD-a27LxTPt4rdBfCd52L32pnXWSBHBQ=.39afa9a5-53e7-4283-adc3-ec496cb9d99e@github.com>

On Thu, 14 Nov 2024 19:51:33 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> See review comments from @RogerRiggs:
>> 
>> https://github.com/openjdk/jdk/pull/22099#pullrequestreview-2435969401
>> https://github.com/openjdk/jdk/pull/22099#discussion_r1842150753
>> 
>> where the folding of these lines into one was suggested.
>> 
>> I'm fine either way, but I agree the lines are somewhat long. It makes the longest line in `ZipOutputStream` and the fifth longest line in `JarFile`.
>> 
>> Can you coordinate with @RogerRiggs and let me know what is the preferred style here? Thanks!
>
> As long as the line in your ide is  around 80 characters or less you are good to go.  If it is say 100 bytes so you have to scroll, that is when I would fold the line.
> 
> I think you are OK here

Yes, they are 96 and 98 chars long, which means I sympathise with both views :)

Unless hearing back from @seanjmullan I'll go with Roger's suggestion of one line here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842817353

From mullan at openjdk.org  Thu Nov 14 20:05:18 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 20:05:18 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <2AATsf_rqRhnD-a27LxTPt4rdBfCd52L32pnXWSBHBQ=.39afa9a5-53e7-4283-adc3-ec496cb9d99e@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
 <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>
 <WJ1_sS9Vkgqp0G4T6eQ2MIl45-3eHKoJDMSeXNnQG_k=.027ba784-1c40-4e38-8b60-8c005a140d37@github.com>
 <kswQ-s3iBxzxwU62FqlHpflI7yjtFfLfHqm41YQhs3Q=.ffc805ec-9ccf-43d7-aef2-f991a56c6c41@github.com>
 <2AATsf_rqRhnD-a27LxTPt4rdBfCd52L32pnXWSBHBQ=.39afa9a5-53e7-4283-adc3-ec496cb9d99e@github.com>
Message-ID: <TU6BhMwjNgotbloe8AvHcC0JRUo2CRUvqoRyayDujfk=.c1c4504c-960a-40c6-bc9c-5057a87fcaee@github.com>

On Thu, 14 Nov 2024 19:58:21 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> As long as the line in your ide is  around 80 characters or less you are good to go.  If it is say 100 bytes so you have to scroll, that is when I would fold the line.
>> 
>> I think you are OK here
>
> Yes, they are 96 and 98 chars long, which means I sympathise with both views :)
> 
> Unless hearing back from @seanjmullan I'll go with Roger's suggestion of one line here.

I think both are in the 90-100 range. Line length is a bit subjective, but I know that at least in the Security Group, we try to keep code to around 80 chars so it is easy to review in a side-by-side diff. It also is visually easier to read I think. In these cases, when breaking, I think it makes sense to break after the `=`. The other option is to make the variable names smaller.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842819047

From lancea at openjdk.org  Thu Nov 14 20:05:19 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 20:05:19 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <TU6BhMwjNgotbloe8AvHcC0JRUo2CRUvqoRyayDujfk=.c1c4504c-960a-40c6-bc9c-5057a87fcaee@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
 <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>
 <WJ1_sS9Vkgqp0G4T6eQ2MIl45-3eHKoJDMSeXNnQG_k=.027ba784-1c40-4e38-8b60-8c005a140d37@github.com>
 <kswQ-s3iBxzxwU62FqlHpflI7yjtFfLfHqm41YQhs3Q=.ffc805ec-9ccf-43d7-aef2-f991a56c6c41@github.com>
 <2AATsf_rqRhnD-a27LxTPt4rdBfCd52L32pnXWSBHBQ=.39afa9a5-53e7-4283-adc3-ec496cb9d99e@github.com>
 <TU6BhMwjNgotbloe8AvHcC0JRUo2CRUvqoRyayDujfk=.c1c4504c-960a-40c6-bc9c-5057a87fcaee@github.com>
Message-ID: <qHXIaUxAyH2bzknh4Xi9pdBMth4uCGdwX0WtTg3gtrg=.99c204dc-318e-4d55-a88b-af77fbacef17@github.com>

On Thu, 14 Nov 2024 19:59:55 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Yes, they are 96 and 98 chars long, which means I sympathise with both views :)
>> 
>> Unless hearing back from @seanjmullan I'll go with Roger's suggestion of one line here.
>
> I think both are in the 90-100 range. Line length is a bit subjective, but I know that at least in the Security Group, we try to keep code to around 80 chars so it is easy to review in a side-by-side diff. It also is visually easier to read I think. In these cases, when breaking, I think it makes sense to break after the `=`. The other option is to make the variable names smaller.

So if the line is 90+ bytes, then please wrap it

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842822138

From lancea at openjdk.org  Thu Nov 14 20:28:31 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 14 Nov 2024 20:28:31 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v3]
In-Reply-To: <490OxKkfmn1xCW-p8hKSSfcf6MHEdpBM6-mjdPRUgz4=.d786b033-2d20-4c69-962f-c37349108bae@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <490OxKkfmn1xCW-p8hKSSfcf6MHEdpBM6-mjdPRUgz4=.d786b033-2d20-4c69-962f-c37349108bae@github.com>
Message-ID: <u_M9e6TuM15HM_AmN16Bl3mU_4Ers3p7AD9XOvx8W7k=.2b342590-955e-483e-8e11-58ffcb5dbb49@github.com>

On Thu, 14 Nov 2024 20:25:35 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
>> 
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
>> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
>> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
>> 
>> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
>> 
>> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64"
>   
>   This reverts commit 6a72b060501981842822680cfa700d1d287f8c04.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22099#pullrequestreview-2437128522

From eirbjo at openjdk.org  Thu Nov 14 20:28:31 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 20:28:31 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v2]
In-Reply-To: <qHXIaUxAyH2bzknh4Xi9pdBMth4uCGdwX0WtTg3gtrg=.99c204dc-318e-4d55-a88b-af77fbacef17@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <bFgm3jhYCarTatZqFdG4vgOl4Z-MoEO-YRde-sr1YtY=.be00460a-14dd-40c9-ae53-fd684ed5c3d4@github.com>
 <9KhmWoAhlfDJqPcbdaDcwhpMAWraxthIH2Tiz7hwFzs=.9cacb0c1-d769-46ec-b125-4531c8553ff0@github.com>
 <WJ1_sS9Vkgqp0G4T6eQ2MIl45-3eHKoJDMSeXNnQG_k=.027ba784-1c40-4e38-8b60-8c005a140d37@github.com>
 <kswQ-s3iBxzxwU62FqlHpflI7yjtFfLfHqm41YQhs3Q=.ffc805ec-9ccf-43d7-aef2-f991a56c6c41@github.com>
 <2AATsf_rqRhnD-a27LxTPt4rdBfCd52L32pnXWSBHBQ=.39afa9a5-53e7-4283-adc3-ec496cb9d99e@github.com>
 <TU6BhMwjNgotbloe8AvHcC0JRUo2CRUvqoRyayDujfk=.c1c4504c-960a-40c6-bc9c-5057a87fcaee@github.com>
 <qHXIaUxAyH2bzknh4Xi9pdBMth4uCGdwX0WtTg3gtrg=.99c204dc-318e-4d55-a88b-af77fbacef17@github.com>
Message-ID: <Rr6YO_GDDDYEf-v4dkia29DFiDVzzh0mveF_9J1JKAw=.43362536-4918-4230-a444-c174f3bb87ef@github.com>

On Thu, 14 Nov 2024 20:02:50 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> I think both are in the 90-100 range. Line length is a bit subjective, but I know that at least in the Security Group, we try to keep code to around 80 chars so it is easy to review in a side-by-side diff. It also is visually easier to read I think. In these cases, when breaking, I think it makes sense to break after the `=`. The other option is to make the variable names smaller.
>
> So if the line is 90+ bytes, then please wrap it

Ok, seems consensus  is converging on wrapping these lines. 

See a93a7ed which reverts the folding.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22099#discussion_r1842846855

From eirbjo at openjdk.org  Thu Nov 14 20:28:31 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 20:28:31 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v3]
In-Reply-To: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
Message-ID: <490OxKkfmn1xCW-p8hKSSfcf6MHEdpBM6-mjdPRUgz4=.d786b033-2d20-4c69-962f-c37349108bae@github.com>

> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
> 
> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
> 
> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
> 
> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Revert "Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64"
  
  This reverts commit 6a72b060501981842822680cfa700d1d287f8c04.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22099/files
  - new: https://git.openjdk.org/jdk/pull/22099/files/6a72b060..a93a7ed8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22099&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22099&range=01-02

  Stats: 4 lines in 2 files changed: 2 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22099.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22099/head:pull/22099

PR: https://git.openjdk.org/jdk/pull/22099

From eirbjo at openjdk.org  Thu Nov 14 20:32:32 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 14 Nov 2024 20:32:32 GMT
Subject: RFR: 8344231: SecurityManager cleanup in java.lang.module and
 jdk.internal.module
Message-ID: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>

Please review this PR which removes code depending on SecurityManager from the `java.lang.module` and `jdk.internal.module` packages:

* `ModuleFinder::ofSystem` is updated to not check the `"accessSystemModules"` RuntimePermission
* The `ModuleReferences.ExplodedModuleReader` constructor is updated to remove the check that the caller has access to the directory.
* `Modules::addProvides` is updated to not use `AccessController::doPrivileged` when getting the module class loader
* `SystemModuleFinder::ofSystem` is updated to not returned a wrapped result calling `AccessController::doPrivileged`
* `SystemModuleFinders.SystemImage` is updated to remove a class level comment referring to the SM
* `SystemModuleFinders.SystemModuleReader::checkPermissionToConnect` is removed. The URI constructor parameter in `SystemModuleReader` becomes unused and is removed.


Testing: I have run `test/jdk/java/lang/module`, `test/jdk/java/lang/ModuleTests`,  and `test/jdk/java/lang/ModuleLayer` successfully. GHA results pending.

-------------

Commit messages:
 - Remove SecurityManager dependent code in java.lang.module, jdk.internal.module

Changes: https://git.openjdk.org/jdk/pull/22113/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22113&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344231
  Stats: 66 lines in 4 files changed: 0 ins; 59 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22113/head:pull/22113

PR: https://git.openjdk.org/jdk/pull/22113

From rriggs at openjdk.org  Thu Nov 14 20:33:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 20:33:31 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v9]
In-Reply-To: <2L6AgFqUJgAKu8fmdDR2yiPaf3D3ijiEAYQ2H8_X7aE=.6c4011d3-1038-49ad-ba2f-6c4be612755b@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <2L6AgFqUJgAKu8fmdDR2yiPaf3D3ijiEAYQ2H8_X7aE=.6c4011d3-1038-49ad-ba2f-6c4be612755b@github.com>
Message-ID: <tXMKSnGKzhsNtS2ClLYKV4tv_r-CYfqDnNldzYu8U7g=.a8af2549-8b2d-410e-baa6-ff8f2e30acd8@github.com>

On Thu, 14 Nov 2024 17:19:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap more long lines

Updates passed CI tier1, tier2, tier3

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22041#issuecomment-2477351842

From liach at openjdk.org  Thu Nov 14 20:38:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 14 Nov 2024 20:38:45 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <_CPEGrm4gbzEuIVwTRde89XK1U7swqb-qCFf8l_RWyc=.6078e00c-4f3f-4925-8052-ba4d6a07919c@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
 <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
 <HaROiuwLaPbPqU0yCkjrF_sErOyFu9SmyJ2Kz7mq1rw=.5dcd201b-6fe4-4c2b-a4c1-d9598bbdf641@github.com>
 <45vdxLi7glsU82ec1dPxT-FEfrJVxAWliwOQ_-sGKko=.8795c8d8-c690-4df1-a98e-47fe44e32429@github.com>
 <_CPEGrm4gbzEuIVwTRde89XK1U7swqb-qCFf8l_RWyc=.6078e00c-4f3f-4925-8052-ba4d6a07919c@github.com>
Message-ID: <rM5LNCv1OTwqxB5SjyR9wn_j3lX40OALz4JGT962Upc=.67ff5905-6dfb-4b53-868f-e7ecc6d9e7be@github.com>

On Thu, 14 Nov 2024 12:28:21 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> I agree with marking these close methods as final as long as the previous corpus search did not find any user-defined close method in subclasses.
>
> Hello Chen, corpus analysis shows that there are no subclasses of Inflater/Deflater which have a `close()` method.

Great news!  Feel free to make their close final.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1842858156

From rriggs at openjdk.org  Thu Nov 14 20:51:31 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 20:51:31 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
Message-ID: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>

Refactored to remove use of doPrivileged() and use of SecurityManager.
The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.

A careful review is requested.

-------------

Commit messages:
 - Drop mention of permissions
 - 8344197: SM cleanup in java.util.concurrent

Changes: https://git.openjdk.org/jdk/pull/22119/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22119&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344197
  Stats: 365 lines in 14 files changed: 7 ins; 317 del; 41 mod
  Patch: https://git.openjdk.org/jdk/pull/22119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22119/head:pull/22119

PR: https://git.openjdk.org/jdk/pull/22119

From bchristi at openjdk.org  Thu Nov 14 21:06:26 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 14 Nov 2024 21:06:26 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <j1ATGzp3JUUnpEzTq-gpIcznZS2TMz_qNGC2Dm9uEs4=.ce7b8b68-ff84-4b6d-93f5-25be822a93cd@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
 <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
 <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>
 <k0s5nWTBudBW0HYAlqPnWy-zXKIeFu4aaKXWwF7GOZE=.3737e4f3-81bd-4604-bf37-861df29043c7@github.com>
 <_8tJj0lTY7DTBd_M4vZxFAdGL5ekCc5DmrSq3fq3078=.35798b85-c920-4cfd-a52b-ff9e8e9ec2b5@github.com>
 <j1ATGzp3JUUnpEzTq-gpIcznZS2TMz_qNGC2Dm9uEs4=.ce7b8b68-ff84-4b6d-93f5-25be822a93cd@github.com>
Message-ID: <4GrNrzjB8oe1gZ8PvYUN49Gpeblh05T1qRHGMbmM9xE=.7fab6c8e-d4a6-4e97-a6f8-417c58a860d2@github.com>

On Thu, 14 Nov 2024 13:20:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> I see that existing `Cleaner` tests are quite rich already. Array-based implementation does rise question about testing the resizes, that's obvious. But I have discovered that copying arrays is not really that good in this scenario which balloons cleaner lists and shrinks them rapidly in our reproducers. So I have reimplemented the whole thing as the linked list of arrays, which makes capacity management code much less problematic. The new asserts around that code should IMO test enough with existing tests.
>
> Nevermind, I added a directed regression test for it now.

> I see that existing `Cleaner` tests are quite rich already. 
> ...
> The new asserts around that code should IMO test enough with existing tests.

Should any of the existing `Cleaner` tests have `@run`s added with `-esa` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1842885362

From rriggs at openjdk.org  Thu Nov 14 21:29:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 21:29:13 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v3]
In-Reply-To: <490OxKkfmn1xCW-p8hKSSfcf6MHEdpBM6-mjdPRUgz4=.d786b033-2d20-4c69-962f-c37349108bae@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <490OxKkfmn1xCW-p8hKSSfcf6MHEdpBM6-mjdPRUgz4=.d786b033-2d20-4c69-962f-c37349108bae@github.com>
Message-ID: <DBQgI7qp-WbVxzpi12LPTvG6PUy-vZhTSmXLjxobqYk=.38885930-f63d-4b71-a2f8-781930969b92@github.com>

On Thu, 14 Nov 2024 20:28:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
>> 
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
>> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
>> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
>> 
>> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
>> 
>> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64"
>   
>   This reverts commit 6a72b060501981842822680cfa700d1d287f8c04.

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22099#pullrequestreview-2437232356

From rriggs at openjdk.org  Thu Nov 14 21:40:20 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 21:40:20 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <uLXQ2ZRLfhwJWxCUqmKul0CClnu5cmyLPpXuMqRkByI=.0afb41f9-b622-4f9c-a3b6-f6ac320a874d@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

still good
@AlanBateman may want to review too.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19702#pullrequestreview-2437248193

From mullan at openjdk.org  Thu Nov 14 21:55:23 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 14 Nov 2024 21:55:23 GMT
Subject: RFR: 8344179: SecurityManager cleanup in the ZIP and JAR areas
 [v3]
In-Reply-To: <490OxKkfmn1xCW-p8hKSSfcf6MHEdpBM6-mjdPRUgz4=.d786b033-2d20-4c69-962f-c37349108bae@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
 <490OxKkfmn1xCW-p8hKSSfcf6MHEdpBM6-mjdPRUgz4=.d786b033-2d20-4c69-962f-c37349108bae@github.com>
Message-ID: <QYqLwk9LQ7GwtHBawybW4xmXzcvWYtB7eiFj8Z6TaBI=.afd5821a-e269-40bc-9f0e-747667d7f821@github.com>

On Thu, 14 Nov 2024 20:28:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
>> 
>> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
>> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
>> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
>> 
>> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
>> 
>> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Revert "Fold lines for System::getProperty when reading enableMultiRelease and inhibitZip64"
>   
>   This reverts commit 6a72b060501981842822680cfa700d1d287f8c04.

Marked as reviewed by mullan (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22099#pullrequestreview-2437271383

From rriggs at openjdk.org  Thu Nov 14 22:17:47 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 14 Nov 2024 22:17:47 GMT
Subject: RFR: 8344252: SM cleanup in java.util classes
Message-ID: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>

Remove use of doPrivileged and SecurityManager in java.util.

-------------

Commit messages:
 - 8344252: SM cleanup in java.util classes

Changes: https://git.openjdk.org/jdk/pull/22122/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22122&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344252
  Stats: 367 lines in 13 files changed: 36 ins; 204 del; 127 mod
  Patch: https://git.openjdk.org/jdk/pull/22122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22122/head:pull/22122

PR: https://git.openjdk.org/jdk/pull/22122

From davidalayachew at gmail.com  Thu Nov 14 22:45:54 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 14 Nov 2024 17:45:54 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
 <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>

Oh ok. So it truly is a toss-up depending on each implementation when and
where this occurs.

Ok, then as my final request, I think even informing the user that this CAN
occur is worth doing. If nothing else, the user scouring the documentation
for documentation of this behaviour will know that it is simply something
that can occur. They don't need to know all the details. Simply give it a
official term, describe the behaviour, tell that it is implementation
specific on when this happens, but that it is only possible during
parallelism. Even just knowing the verbiage to describe the problem will
enable them to better communicate with each other on what they want vs what
they get. That helps searchability, if nothing else.

On Thu, Nov 14, 2024, 8:45?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> I see what you're saying, the problem is that it depends on the Stream
> implementation (given that Stream is an interface).
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Thursday, 14 November 2024 12:36
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Then let me correct myself again, while simplifying -- I just want that
> detail, that certain combinations might lead to pre-fetching everything, to
> be documented on the stream api. Package level, or on the Stream interface
> itself, seems like a good spot.
>
> On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> The issue here is that the operation cannot advertise this, as it depends
> on the combination of operations.
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Wednesday, 13 November 2024 14:07
> *To:* Rob Spoor <openjdk at icemanx.nl>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> That is a good point Rob.
>
> Then let me correct myself -- I think the terminal operations don't do a
> great job of advertising whether or not they pre-fetch everything when
> parallelism is activated. Collector fetches as needed. FindAny pre-fetches
> everything. I understand that later releases might change their behaviour,
> but I still want to document the current behaviour in the official javadocs
> so that we can limit undocumented tripping hazards.
>
>
> On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl> wrote:
>
> distinct() doesn't require everything to be pulled. It can push elements
> to the downstream as they come along for the first time. When
> downstream.push returns false the gatherer is done.
>
> As part of some experimentation I've implemented all intermediary
> operations using gatherers. Most of them are pretty straightforward and
> will stop integrating once the downstream starts rejecting elements
> (although some use Gatherer.ofSequential to keep it easy). I only found
> two exceptions that don't return the result of downstream.push:
>
> * mapMulti. The downstream.push is passed as the mapper which is a
> Consumer - the return value is ignored. With some more effort it's
> probably possible to capture any false return value and return that from
> the integrator, but I haven't tried that yet.
>
> * sorted. Obviously every element needs to be inspected.
>
>
> On 13/11/2024 00:37, David Alayachew wrote:
> > Oh sure, I expect something like distinct() to pull everything. In order
> to
> > know if something is distinct, you have to do some variant of "check
> > against everyone else". Whether that is holding all instances in memory
> or
> > their hashes, it's clear from a glance that you will need to look at
> > everything, and therefore, pre-fetching makes intuitive sense to me.
> >
> > I 100% did not expect terminal operations like findAny() or reduce() to
> > pull the whole data set. That was a complete whiplash for me. The method
> > findAny() advertises itself as a short-circuiting operation, so to find
> out
> > that it actually pulls the whole data set anyways was shocking.
> >
> > And that was my biggest pain point -- looking at the documentation, it is
> > not clear to me at all that methods like findAny() would pull in all data
> > upon becoming parallel().
> >
> > Do you think it would make sense to add documentation about this to the
> > javadocs for Stream/java.util.stream? Or maybe it is already there and I
> > misunderstood it (even after reading through it thoroughly over 5 times).
> >
> >
> > On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
> >
> >>> We are told how Streams can process unbounded data sets, but when it
> >> tries to do a findAny() with parallel(), it runs into an OOME because it
> >> fetched all the data ahead of time. In fact, almost of the terminal
> >> operations will hit an OOME in the exact same way if they are parallel
> and
> >> have a big enough data set. It's definitely not the end of the world,
> but
> >> it seems that I have to fit everything into a Collector and/or a
> Gatherer
> >> if I want to avoid pre-fetching everything.
> >>
> >> Yeah, I think it is important to distinguish "can process unbounded data
> >> sets" from "always able to process unbounded data sets".
> >>
> >> Some operations inherently need the end of the stream, so even something
> >> somple like: stream.distinct() or stream.sorted() can end up pulling in
> all
> >> data (which of course won't terminate).
> >>
> >> Fortunately, I think Gatherers can unlock much more situations where
> >> unbounded streams can be processed.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 15:08
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Oh woah. I certainly did not. Or rather, I had dismissed the idea as
> soon
> >> as I thought of it.
> >>
> >>
> >> I hand-waved away the idea because I thought that the method would turn
> >> the stream pipeline parallel, thus, recreating the same problem I
> currently
> >> have of parallelism causing all of the elements to be fetched ahead of
> >> time, causing an OOME.
> >>
> >>
> >> It did NOT occur to me that the pipeline would stay sequential, and just
> >> kick these off sequentially, but have them executing in parallel. I
> can't
> >> see why I came to that incorrect conclusion. I have read the javadocs of
> >> this method several times. Though, to be fair, I came to the same,
> >> incorrect conclusion about Collectors.groupingByConcurrent(), and it
> wasn't
> >> until someone pointed out what the documentation was actually saying
> that I
> >> realized it's true properties.
> >>
> >> Thanks. That definitely solves at least part of my problem. Obviously, I
> >> would prefer to write to S3 in parallel too, but at the very least, the
> >> calculation part is being done in parallel. And worst case scenario, I
> can
> >> be really bad and just do the write to S3 in the mapConcurrent, and then
> >> just return the metadata of each write, and just bundle that up with
> >> collect.
> >>
> >>
> >> And that's ignoring the fact that I can just use the workaround too.
> >>
> >>
> >> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
> >> from a performance perspective, but is rather unintuitive to me from a
> >> usability perspective. We are told how Streams can process unbounded
> data
> >> sets, but when it tries to do a findAny() with parallel(), it runs into
> an
> >> OOME because it fetched all the data ahead of time. In fact, almost of
> the
> >> terminal operations will hit an OOME in the exact same way if they are
> >> parallel and have a big enough data set. It's definitely not the end of
> the
> >> world, but it seems that I have to fit everything into a Collector
> and/or a
> >> Gatherer if I want to avoid pre-fetching everything.
> >>
> >> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Have you considered Gatherers.mapConcurrent(?)?
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 01:53
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >> Good to know, ty vm.
> >>
> >> At the very least, I have this workaround. This will meet my needs for
> now.
> >>
> >> I guess my final question would be -- is this type of problem better
> >> suited to something besides parallel streams? Maybe an ExecutorService?
> >>
> >> Really, all I am doing is taking a jumbo file, splitting it into
> batches,
> >> and then doing some work on those batches. My IO speeds are pretty fast,
> >> and the compute work is non-trivial, so there is performance being left
> on
> >> the table if I give up parallelism. And I am in a position where
> completion
> >> time is very important to us.
> >>
> >> I just naturally assumed parallel streams were the right choice because
> >> the compute work is simple. A pure function that I can break out, and
> then
> >> call in a map. Once I do that, I just call forEach to write the batches
> >> back out to S3. Maybe I should look into a different part of the std lib
> >> instead because I am using the wrong tool for the job? My nose says
> >> ExecutorService, but I figure I should ask before I dive too deep in.
> >>
> >>
> >> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> You're most welcome!
> >>
> >> In a potential future where all intermediate operations are
> >> Gatherer-based, and all terminal operations are Collector-based, it
> would
> >> just work as expected. But with that said, I'm not sure it is
> practically
> >> achievable because some operations might not have the same
> >> performance-characteristics as before.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 18:32
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Thanks for the workaround. It's running beautifully.
> >>
> >> Is there a future where this island concept is extended to the rest of
> >> streams? Tbh, I don't fully understand it.
> >>
> >> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Hi David,
> >>
> >> This is the effect of how parallel streams are implemented, where
> >> different stages, which are not representible as a join-less Spliterator
> >> are executed as a series of "islands" where the next isn't started until
> >> the former has completed.
> >>
> >> If you think about it, parallelization of a Stream works best when the
> >> entire data set can be split amongst a set of worker threads, and that
> sort
> >> of implies that you want eager pre-fetch of data, so if your dataset
> does
> >> not fit in memory, that is likely to lead to less desirable outcomes.
> >>
> >> What I was able to do for Gatherers is to implement "gather(?) +
> >> collect(?)"-fusion so any number of consecutive gather(?)-operations
> >> immediately followed by a collect(?) is run in the same "island".
> >>
> >> So with that said, you could try something like the following:
> >>
> >> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T>
> *each*) {
> >>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e),
> (*l*,
> >> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> >> }
> >>
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .collect(forEach(eachList -> println(eachList.getFirst())));
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> David
> >> Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 14:52
> >> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> >> elements
> >>
> >> And just to avoid the obvious question, I can hold about 30 batches in
> >> memory before the Out of Memory error occurs. So this is not an issue
> of my
> >> batch size being too high.
> >>
> >> But just to confirm, I set the batch size to 1, and it still ran into an
> >> out of memory error. So I feel fairly confident saying that the
> Gatherer is
> >> trying to grab all available data before sending any of it downstream.
> >>
> >> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com
> >
> >> wrote:
> >>
> >> Hello Core Libs Dev Team,
> >>
> >> I was trying out Gatherers for a project at work, and ran into a rather
> >> sad scenario.
> >>
> >> I need to process a large file in batches. Each batch is small enough
> that
> >> I can hold it in memory, but I cannot hold the entire file (and thus,
> all
> >> of the batches) in memory at once.
> >>
> >> Looking at the Gatherers API, I saw windowFixed and thought that it
> would
> >> be a great match for my use case.
> >>
> >> However, when trying it out, I was disappointed to see that it ran out
> of
> >> memory very quickly. Here is my attempt at using it.
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .forEach(eachList -> println(eachList.getFirst()))
> >> ;
> >>
> >> As you can see, I am just splitting the file into batches, and printing
> >> out the first of each batch. This is purely for example's sake, of
> course.
> >> I had planned on building even more functionality on top of this, but I
> >> couldn't even get past this example.
> >>
> >> But anyways, not even a single one of them printed out. Which leads me
> to
> >> believe that it's pulling all of them in the Gatherer.
> >>
> >> I can get it to run successfully if I go sequentially, but not parallel.
> >> Parallel gives me that out of memory error.
> >>
> >> Is there any way for me to be able to have the Gatherer NOT pull in
> >> everything while still remaining parallel and unordered?
> >>
> >> Thank you for your time and help.
> >> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241114/547ce057/attachment-0001.htm>

From naoto at openjdk.org  Thu Nov 14 22:48:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 14 Nov 2024 22:48:16 GMT
Subject: RFR: 8344252: SM cleanup in java.util classes
In-Reply-To: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
References: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
Message-ID: <0g8MtkAcfB0kf4ojqySrmBX2pKqc3-yU_xbXGDjBYVE=.4c3caa78-d52d-45b9-b47d-9f050c50b32d@github.com>

On Thu, 14 Nov 2024 22:09:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove use of doPrivileged and SecurityManager in java.util.

src/java.base/share/classes/java/util/Properties.java line 952:

> 950: 
> 951:     private static void writeDateComment(BufferedWriter bw) throws IOException {
> 952:         // value of java.properties.date system property isn't sensitive

Left over comment?

src/java.base/share/classes/java/util/ResourceBundle.java line 1889:

> 1887:                 return s;
> 1888:             }
> 1889:         } catch (ClassNotFoundException e) {}

Suggestion:

        } catch (ClassNotFoundException _) {}

src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java line 82:

> 80:  *
> 81:  * @see <a href="../ResourceBundle.html#resource-bundle-modules">
> 82:  * Resource Bundles and Named Modules</a>

Could be replaced with 

ResourceBundle##resource-bundle-modules
    Resource Bundles and Named Modules

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22122#discussion_r1842966914
PR Review Comment: https://git.openjdk.org/jdk/pull/22122#discussion_r1842977529
PR Review Comment: https://git.openjdk.org/jdk/pull/22122#discussion_r1842974477

From dlong at openjdk.org  Thu Nov 14 23:23:18 2024
From: dlong at openjdk.org (Dean Long)
Date: Thu, 14 Nov 2024 23:23:18 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <gs8Jaubur5FzfHn5bi0wvbLh-XQNnzp3gyrXuZp9_hs=.3dbb94ee-0793-4d4b-8a7f-2ad8da268936@github.com>

On Thu, 14 Nov 2024 05:32:34 GMT, Shaojin Wen <swen at openjdk.org> wrote:

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

Doesn't this break any apps that use these offsets?  Aren't these fields part of the public API of Unsafe, so changing them requires a CSR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2477603477

From prr at openjdk.org  Thu Nov 14 23:57:22 2024
From: prr at openjdk.org (Phil Race)
Date: Thu, 14 Nov 2024 23:57:22 GMT
Subject: RFR: 8344065: Remove SecurityManager uses from the java.datatransfer
 module
Message-ID: <xj99BLFzOM_0Mjk9TwW-tswJko1pjjfI0kfFb6wx6fw=.cbbb91c8-1c81-4d8a-afae-392ac02ba1f7@github.com>

remove uses of SM APIs from the java.datatransfer module. Also cleans up the now un-needed export from java.base

-------------

Commit messages:
 - 8344065

Changes: https://git.openjdk.org/jdk/pull/22127/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22127&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344065
  Stats: 32 lines in 3 files changed: 0 ins; 18 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/22127.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22127/head:pull/22127

PR: https://git.openjdk.org/jdk/pull/22127

From ihse at openjdk.org  Fri Nov 15 00:10:24 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 00:10:24 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
 <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>
Message-ID: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com>

On Thu, 14 Nov 2024 15:23:35 GMT, Jonathan Gibbons <jjg at openjdk.org> wrote:

> The policy has long been to use Classpath Exception in the src and make directories, but not in the test directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down.

I did not know there was such a policy. My understanding is that the classpath exception only makes sense for java files that are distributed as part of the JDK. That `test` was excluded from classpath should therefore be a logical consequence that it is not distributed. And `src` is not generally using CPE; for instance, Hotspot does not have CPE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2477665315

From smarks at openjdk.org  Fri Nov 15 00:17:36 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Fri, 15 Nov 2024 00:17:36 GMT
Subject: RFR: 8344252: SM cleanup in java.util classes
In-Reply-To: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
References: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
Message-ID: <EQGyF-i8_8BZA_h4MtP-U18WoXYs5lSxMilKNaTNUjo=.9fe572ce-df0e-470d-b947-d32e8a364602@github.com>

On Thu, 14 Nov 2024 22:09:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove use of doPrivileged and SecurityManager in java.util.

Marked as reviewed by smarks (Reviewer).

I mainly wanted to look at Arrays, and I looked briefly at the other stuff too. All looks good.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22122#pullrequestreview-2437432619
PR Comment: https://git.openjdk.org/jdk/pull/22122#issuecomment-2477672974

From psandoz at openjdk.org  Fri Nov 15 00:30:26 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 15 Nov 2024 00:30:26 GMT
Subject: RFR: 8344259: Annotate Float16 with jdk.internal.ValueBased
Message-ID: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>

Annotate `Float16` with `jdk.internal.ValueBased`. This requires we export the package `jdk.internal` in module `java.base` to module` jdk.incubator.vector`.

Doing so enables the compiler and runtime to report warnings about improper attempts to synchronize on instances of `Float16`, as described in [JEP 390](https://openjdk.org/jeps/390).

-------------

Commit messages:
 - 8344259: Annotate Float16 with jdk.internal.ValueBased

Changes: https://git.openjdk.org/jdk/pull/22128/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22128&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344259
  Stats: 5 lines in 2 files changed: 2 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22128.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22128/head:pull/22128

PR: https://git.openjdk.org/jdk/pull/22128

From serb at openjdk.org  Fri Nov 15 00:39:49 2024
From: serb at openjdk.org (Sergey Bylokhov)
Date: Fri, 15 Nov 2024 00:39:49 GMT
Subject: RFR: 8344065: Remove SecurityManager uses from the
 java.datatransfer module
In-Reply-To: <xj99BLFzOM_0Mjk9TwW-tswJko1pjjfI0kfFb6wx6fw=.cbbb91c8-1c81-4d8a-afae-392ac02ba1f7@github.com>
References: <xj99BLFzOM_0Mjk9TwW-tswJko1pjjfI0kfFb6wx6fw=.cbbb91c8-1c81-4d8a-afae-392ac02ba1f7@github.com>
Message-ID: <HW4jNXI6t66NeHXh9RylUeB9B3NqsivHX8rgd7GVj_g=.674a512c-74bb-43a0-93d2-837a23b2885f@github.com>

On Thu, 14 Nov 2024 23:51:24 GMT, Phil Race <prr at openjdk.org> wrote:

> remove uses of SM APIs from the java.datatransfer module. Also cleans up the now un-needed export from java.base

Marked as reviewed by serb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22127#pullrequestreview-2437452002

From liach at openjdk.org  Fri Nov 15 00:47:27 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 00:47:27 GMT
Subject: RFR: 8344259: Annotate Float16 with jdk.internal.ValueBased
In-Reply-To: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>
References: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>
Message-ID: <FxZzDeBuNOaVM59aBJv9ajxyX1jZGxj8AVHVLgJzf9g=.b79ad967-73df-4fdb-b120-0fcaeef8312f@github.com>

On Fri, 15 Nov 2024 00:25:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Annotate `Float16` with `jdk.internal.ValueBased`. This requires we export the package `jdk.internal` in module `java.base` to module` jdk.incubator.vector`.
> 
> Doing so enables the compiler and runtime to report warnings about improper attempts to synchronize on instances of `Float16`, as described in [JEP 390](https://openjdk.org/jeps/390).

Makes sense.  Also good simplification of factory call with existing static imports.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22128#pullrequestreview-2437458456

From darcy at openjdk.org  Fri Nov 15 01:04:49 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 15 Nov 2024 01:04:49 GMT
Subject: RFR: 8344259: Annotate Float16 with jdk.internal.ValueBased
In-Reply-To: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>
References: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>
Message-ID: <knHUvDicx9EXar6bRDSBL93WXEmoVYvm_5nAzq87nfo=.56a7024c-d39e-4ed1-ab96-308330b9932e@github.com>

On Fri, 15 Nov 2024 00:25:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Annotate `Float16` with `jdk.internal.ValueBased`. This requires we export the package `jdk.internal` in module `java.base` to module` jdk.incubator.vector`.
> 
> Doing so enables the compiler and runtime to report warnings about improper attempts to synchronize on instances of `Float16`, as described in [JEP 390](https://openjdk.org/jeps/390).

Looks fine; please manually verify the expected javac warnings are given for misuse of Float16 in non-value ways.

-------------

Marked as reviewed by darcy (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22128#pullrequestreview-2437474278

From swen at openjdk.org  Fri Nov 15 01:04:58 2024
From: swen at openjdk.org (Shaojin Wen)
Date: Fri, 15 Nov 2024 01:04:58 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long [v2]
In-Reply-To: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
Message-ID: <lVgbXe_xisP3D9sUnuV0S8l5qxOtjSyMn-vXm8dVllQ=.6535703b-00ba-4f66-b31a-ca960ead09e1@github.com>

> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
> 
> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.

Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:

  long BaseAndScale base, from @JornVernee

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22095/files
  - new: https://git.openjdk.org/jdk/pull/22095/files/c0c283ef..f33e9d3d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22095&range=00-01

  Stats: 9 lines in 2 files changed: 0 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22095.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22095/head:pull/22095

PR: https://git.openjdk.org/jdk/pull/22095

From duke at openjdk.org  Fri Nov 15 01:08:25 2024
From: duke at openjdk.org (ExE Boss)
Date: Fri, 15 Nov 2024 01:08:25 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <gs8Jaubur5FzfHn5bi0wvbLh-XQNnzp3gyrXuZp9_hs=.3dbb94ee-0793-4d4b-8a7f-2ad8da268936@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <gs8Jaubur5FzfHn5bi0wvbLh-XQNnzp3gyrXuZp9_hs=.3dbb94ee-0793-4d4b-8a7f-2ad8da268936@github.com>
Message-ID: <W8_iwDOrq_gtb_bWOpLZT-BEFzT5s6OGvHinzh07y0Y=.fdf1ecd4-8f17-47c2-8083-a1c8be25ed13@github.com>

On Thu, 14 Nov 2024 23:20:23 GMT, Dean Long <dlong at openjdk.org> wrote:

>> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
>> 
>> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.
>
> Doesn't this break any apps that use these offsets?  Aren't these fields part of the public API of Unsafe, so changing them requires a CSR?

@dean-long
> Doesn't this break any apps that use these offsets? Aren't these fields part of the public API of Unsafe, so changing them requires a CSR?

This?is the?encapsulated JDK?internal `Unsafe` in?`java.base`, not?the?legacy `sun.misc.Unsafe`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2477742637

From liach at openjdk.org  Fri Nov 15 01:22:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 01:22:53 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v9]
In-Reply-To: <gBxCkZdy0V-EzOafhUmS0SojDfEi3mkXdXyW6eran4Q=.1edac68c-b481-49de-a86b-50c1400dc870@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <gBxCkZdy0V-EzOafhUmS0SojDfEi3mkXdXyW6eran4Q=.1edac68c-b481-49de-a86b-50c1400dc870@github.com>
Message-ID: <URAwb1efRTpCM6U_T7yJY9G9ZlwT7Pf5_Lt0VJbKnZo=.b0bfef52-3223-4b9b-9926-1eb6504f903b@github.com>

On Thu, 14 Nov 2024 19:16:34 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Uses of `InternalLock` are removed and `synchronized` is reinstated.
>
> Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Merge
>  - 8343039: Change "resizble" comment in BOS
>  - 8343039: Remove failing getDeclaredField call from test java/lang/ProcessBuilder/Basic.java
>  - 8343039: Remove java.base/jdk.internal.misc from @modules in test java/lang/ProcessBuilder/Basic.java
>  - 8343039: Remove InternalLock reference from java/lang/ProcessBuilder/Basic.java
>  - 8343039: Address reviewer comments
>  - 8343039: Remove JavaIOPrint{Stream,Writer}Access and the use thereof
>  - 8343039: Remove use of InternalLock from Stream{De,En}coder and throwable; remove InternalLock class; address comments on BIS and BOS
>  - 8343039: Remove jdk.internal.misc.InternalLock and usages from java.io

Looks good.  Aside from the output stream smaller buffer from virtual threads, everything is pretty much a restoration to JDK18's state (aside from trivial whitespace changes)

src/java.base/share/classes/java/io/BufferedReader.java line 329:

> 327:             if (term != null) term[0] = false;
> 328: 
> 329:             bufferLoop:

How do we usually handle the indentation of labels?  I personally prefer this type of indentation, but in the jdk18 code the label has one less level of indentation, so it aligns with the enclosing `}`.  Don't know if we are looking for parity with 18 code.

test/jdk/java/lang/ProcessBuilder/Basic.java line 2677:

> 2675:                 else unexpected(t);}}
> 2676: 
> 2677:     static boolean isLocked(BufferedInputStream bis) throws Exception {

The original version in JDK 18 uses arbitrary Object and a configurable number of millis.  That said, this can stay as is as it's functionally the same as the original 18 test.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22048#pullrequestreview-2437027840
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1842785851
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1843070312

From dholmes at openjdk.org  Fri Nov 15 01:25:30 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Nov 2024 01:25:30 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <C-MBQ_G52h3Y1bIQRfxQJOSVS3pmOv6CRy1fxzR0K4M=.67e32bdd-26cd-4450-ba03-766af4e2e98e@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

LGTM!

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2437489438

From almatvee at openjdk.org  Fri Nov 15 01:27:41 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Nov 2024 01:27:41 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>

On Sat, 9 Nov 2024 00:51:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

Looks good overall with some comments. I will do second review pass tomorrow.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Comm.java line 2:

> 1: /*
> 2:  * Copyright (c) 2019, 2024, Oracle and/or its affiliates. All rights reserved.

If it is new code, then remove 2019.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java line 441:

> 439:         }
> 440: 
> 441:         // Verify the value of `Exec` key in is escaped if required

This comment is confusing. Did you mean "Verify that the value of `Exec` key is escaped"?

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/MethodCall.java line 157:

> 155:                 final var argValue = args[idx];
> 156:                 newArgs[idx] = Optional.ofNullable(argValue).map(Object::getClass).map(argType -> {
> 157:                     if(argType.isArray() && !paramType.isAssignableFrom(argType) ) {

`if(argType` -> `if (argType` and `(argType) )` -> `(argType))`.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestMethodSupplier.java line 142:

> 140:                 throw ex;
> 141:             }
> 142:         }

Maybe move this code into `switch` statement under `default`? Also, should we use `TypeStatus.UNKNOWN` instead of `null`?

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestMethodSupplier.java line 433:

> 431:                     withTestAnnotations = true;
> 432:                 }
> 433:                 verifyAnnotationsCorrect(method);

This code blocks looks confusing. Why we need `method.setAccessible(true)` for all methods? Also, `if` statement looks confusing with empty `if (withTestAnnotations).`

-------------

PR Review: https://git.openjdk.org/jdk/pull/21996#pullrequestreview-2437415465
PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843023671
PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843028551
PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843041707
PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843068391
PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843073100

From dholmes at openjdk.org  Fri Nov 15 01:29:49 2024
From: dholmes at openjdk.org (David Holmes)
Date: Fri, 15 Nov 2024 01:29:49 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

> > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad).
> 
> _sigh_
> 
> > A candidate for an ignore list as fixing it is out of scope of this PR?
> 
> Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix.

I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2477764902

From almatvee at openjdk.org  Fri Nov 15 01:30:24 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Nov 2024 01:30:24 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <ySyJz2SMZvvT2ybO2ZphJoJVMDGC8m1EyV6zTiEQFjg=.00b8531e-ec26-4489-974f-13e14300434b@github.com>

On Sat, 9 Nov 2024 00:51:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

This is large change and some of them are not related and can (or should) be done separately. For example Parameter annotations and use jpackage l10n keys. Did you consider splitting this issue into multiple one? I am ok as is, but something to consider.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21996#issuecomment-2477767013

From bpb at openjdk.org  Fri Nov 15 01:35:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 01:35:44 GMT
Subject: RFR: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io [v9]
In-Reply-To: <URAwb1efRTpCM6U_T7yJY9G9ZlwT7Pf5_Lt0VJbKnZo=.b0bfef52-3223-4b9b-9926-1eb6504f903b@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
 <gBxCkZdy0V-EzOafhUmS0SojDfEi3mkXdXyW6eran4Q=.1edac68c-b481-49de-a86b-50c1400dc870@github.com>
 <URAwb1efRTpCM6U_T7yJY9G9ZlwT7Pf5_Lt0VJbKnZo=.b0bfef52-3223-4b9b-9926-1eb6504f903b@github.com>
Message-ID: <TWR4-nUWVd3uENF18TQxAHx9ORzWBmrl-mBalXzrh18=.6900972d-dd4e-4f93-9a4d-619d9b1bc2b7@github.com>

On Fri, 15 Nov 2024 01:20:43 GMT, Chen Liang <liach at openjdk.org> wrote:

> Looks good

Thanks, @liach , for the second review.

> src/java.base/share/classes/java/io/BufferedReader.java line 329:
> 
>> 327:             if (term != null) term[0] = false;
>> 328: 
>> 329:             bufferLoop:
> 
> How do we usually handle the indentation of labels?  I personally prefer this type of indentation, but in the jdk18 code the label has one less level of indentation, so it aligns with the enclosing `}`.  Don't know if we are looking for parity with 18 code.

I don't know what the indentation convention for labels is. Neither the draft style guide (https://cr.openjdk.org/~alundblad/styleguide/index-v6.html) nor the ancient code conventions from 1997 mention this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22048#issuecomment-2477770118
PR Review Comment: https://git.openjdk.org/jdk/pull/22048#discussion_r1843078969

From pkoppula at openjdk.org  Fri Nov 15 02:55:06 2024
From: pkoppula at openjdk.org (Prasadrao Koppula)
Date: Fri, 15 Nov 2024 02:55:06 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v11]
In-Reply-To: <XTQ-TYPeAhQwhk7O73SJY1WycSkshAZgVhrhImCFSaI=.7b10a7ca-42c2-49c7-bd6a-4374e80e90e8@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <e9XneE4CQS0xlG3zIFZbOCt6j-gz0kRRUTLh45Pjxbs=.6f4cf332-68e1-4546-a859-435a72669094@github.com>
 <XTQ-TYPeAhQwhk7O73SJY1WycSkshAZgVhrhImCFSaI=.7b10a7ca-42c2-49c7-bd6a-4374e80e90e8@github.com>
Message-ID: <iR6SzSmgl4ox7aBiszaKb8mZOci6Ylb7FRbY6UAJfO4=.9f731e14-cfab-49f7-8daf-01bcafe86a68@github.com>

On Thu, 7 Nov 2024 17:52:53 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Prasadrao Koppula has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
>> 
>>  - Merge master
>>  - initialized storeName with empty string
>>  - Replaced Paths.get with Path.of
>>  - Removed unnecessary code
>>  - Removed unnecessary code
>>  - Handled nested wrappers around FileInputStream
>>  - Handled BIS case as well
>>  - JDK-8329251
>>  - JDK-8329251
>>  - JDK-8329251
>>  - ... and 1 more: https://git.openjdk.org/jdk/compare/f2316f68...c90b4f30
>
> src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 286:
> 
>> 284:                     .getPath(ks);
>> 285:             if (keystorePath != null) {
>> 286:                 SSLLogger.fine(provider.getName() + ": using \"" + Path.of(
> 
> Suggest rewording as "Initializing with keystore: keystore.p12 in PKCS12 format from SUN provider"
> 
> Do you really need to log the provider name?

Printing the provider name helps identify if it?s a third-party provider, default provider, or another type.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1843124527

From duke at openjdk.org  Fri Nov 15 03:02:09 2024
From: duke at openjdk.org (duke)
Date: Fri, 15 Nov 2024 03:02:09 GMT
Subject: Withdrawn: 8340493: Fix some Asserts failure messages
In-Reply-To: <_nQ0hPZLDkS0LOIg4Z4itXpyGCSasSSuid4Gz3fm3Kc=.6d0ba0ad-0aa3-4ccf-80a1-e13017fd33fa@github.com>
References: <_nQ0hPZLDkS0LOIg4Z4itXpyGCSasSSuid4Gz3fm3Kc=.6d0ba0ad-0aa3-4ccf-80a1-e13017fd33fa@github.com>
Message-ID: <k10hqQ06NHo-MYeVr-_seVAV8B-gnLfxpQ4Nz5J3PtU=.5a6473a1-677f-48a0-8240-47f94eea540b@github.com>

On Fri, 20 Sep 2024 00:33:39 GMT, Weijun Wang <weijun at openjdk.org> wrote:

> `Asserts.assertNotEquals` shows "expected 12345 to not equal 12345" which sounds redundant, just say "expected not equals but was 12345".
> 
> `Asserts.assertEqualsByteArray` uses the words "expected... to equal...". Modify it to follow the `assertEquals` style ""expected... but was...".

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21101

From prr at openjdk.org  Fri Nov 15 04:55:38 2024
From: prr at openjdk.org (Phil Race)
Date: Fri, 15 Nov 2024 04:55:38 GMT
Subject: Integrated: 8344065: Remove SecurityManager uses from the
 java.datatransfer module
In-Reply-To: <xj99BLFzOM_0Mjk9TwW-tswJko1pjjfI0kfFb6wx6fw=.cbbb91c8-1c81-4d8a-afae-392ac02ba1f7@github.com>
References: <xj99BLFzOM_0Mjk9TwW-tswJko1pjjfI0kfFb6wx6fw=.cbbb91c8-1c81-4d8a-afae-392ac02ba1f7@github.com>
Message-ID: <--v_NEtaF0vHFescmOphE712GwTH6KdHtX71T0BoGIc=.89ddaf37-80a0-41a4-892a-37dfe8498dac@github.com>

On Thu, 14 Nov 2024 23:51:24 GMT, Phil Race <prr at openjdk.org> wrote:

> remove uses of SM APIs from the java.datatransfer module. Also cleans up the now un-needed export from java.base

This pull request has now been integrated.

Changeset: 99070658
Author:    Phil Race <prr at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/99070658fd09ee3d1835f814c939d62e249c5704
Stats:     32 lines in 3 files changed: 0 ins; 18 del; 14 mod

8344065: Remove SecurityManager uses from the java.datatransfer module

Reviewed-by: serb

-------------

PR: https://git.openjdk.org/jdk/pull/22127

From iklam at openjdk.org  Fri Nov 15 05:48:27 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 15 Nov 2024 05:48:27 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v12]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <qgUbC_wHCSZSk2gaoYfACTjhMmTTJ3-Z71cf_idXfrA=.3c153927-bf07-4ad2-b296-178511a4fda8@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 179 commits:

 - Merge branch 'master' into jep-483-candidate
 - Merge branch 'master' into jep-483-candidate
 - fixed merge with UseCompactObjectHeaders
 -  Merge branch 'master' into jep-483-candidate
 - fixed merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline
 - @DanHeidinga comment -- exit VM when runtimeSetup() fails
 - fixed merge
 - Merge branch 'master' into jep-483-candidate
 - 8343493: Perform module checks during MetaspaceShared::map_archives()
 - ... and 169 more: https://git.openjdk.org/jdk/compare/db56266a...77b253cf

-------------

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=11
  Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From alanb at openjdk.org  Fri Nov 15 06:36:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 06:36:45 GMT
Subject: RFR: 8344231: SecurityManager cleanup in java.lang.module and
 jdk.internal.module
In-Reply-To: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
References: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
Message-ID: <PHgSzxxT0gOg0rDGUBMcjxhBf7LRuBSmu_LFkqYSKso=.77bf1a9e-16f2-4833-8b62-aff574e64517@github.com>

On Thu, 14 Nov 2024 17:32:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes code depending on SecurityManager from the `java.lang.module` and `jdk.internal.module` packages:
> 
> * `ModuleFinder::ofSystem` is updated to not check the `"accessSystemModules"` RuntimePermission
> * The `ModuleReferences.ExplodedModuleReader` constructor is updated to remove the check that the caller has access to the directory.
> * `Modules::addProvides` is updated to not use `AccessController::doPrivileged` when getting the module class loader
> * `SystemModuleFinder::ofSystem` is updated to not returned a wrapped result calling `AccessController::doPrivileged`
> * `SystemModuleFinders.SystemImage` is updated to remove a class level comment referring to the SM
> * `SystemModuleFinders.SystemModuleReader::checkPermissionToConnect` is removed. The URI constructor parameter in `SystemModuleReader` becomes unused and is removed.
> 
> 
> Testing: I have run `test/jdk/java/lang/module`, `test/jdk/java/lang/ModuleTests`,  and `test/jdk/java/lang/ModuleLayer` successfully. GHA results pending.

Looks good, thanks for taking this one.

src/java.base/share/classes/jdk/internal/module/Modules.java line 158:

> 156:         ClassLoader loader = m.getClassLoader();
> 157: 
> 158:         ClassLoader platformClassLoader = ClassLoaders.platformClassLoader();

You can remove the blank line at L157 now, it was only there to make the doPriv use clearer.

src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 364:

> 362: 
> 363:     /**
> 364:      * Holder class for the ImageReader

In passing, you would mind adding a full stop after ImageReader. Only noticed it with the removal of the apinote.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22113#pullrequestreview-2437774168
PR Review Comment: https://git.openjdk.org/jdk/pull/22113#discussion_r1843252012
PR Review Comment: https://git.openjdk.org/jdk/pull/22113#discussion_r1843252637

From henryjen at openjdk.org  Fri Nov 15 06:37:26 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 15 Nov 2024 06:37:26 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v10]
In-Reply-To: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
Message-ID: <ySIKcDuuDKixdh16Jz6ExXvc3knHn8fNB_EKfnhxqLE=.04a0dd76-8431-4f59-9da8-9edcb18e017c@github.com>

> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
> 
> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
> 
> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
> 
> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
> 
> So we make this build in advance, and use a static array for values referred more than once.
> 
> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.

Henry Jen has updated the pull request incrementally with one additional commit since the last revision:

  Rename based on feedback to emphasis building a snippet for loading a reference

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21022/files
  - new: https://git.openjdk.org/jdk/pull/21022/files/91076995..69d84664

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=08-09

  Stats: 1146 lines in 5 files changed: 493 ins; 546 del; 107 mod
  Patch: https://git.openjdk.org/jdk/pull/21022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21022/head:pull/21022

PR: https://git.openjdk.org/jdk/pull/21022

From alanb at openjdk.org  Fri Nov 15 06:39:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 06:39:26 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <4GrNrzjB8oe1gZ8PvYUN49Gpeblh05T1qRHGMbmM9xE=.7fab6c8e-d4a6-4e97-a6f8-417c58a860d2@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
 <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
 <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>
 <k0s5nWTBudBW0HYAlqPnWy-zXKIeFu4aaKXWwF7GOZE=.3737e4f3-81bd-4604-bf37-861df29043c7@github.com>
 <_8tJj0lTY7DTBd_M4vZxFAdGL5ekCc5DmrSq3fq3078=.35798b85-c920-4cfd-a52b-ff9e8e9ec2b5@github.com>
 <j1ATGzp3JUUnpEzTq-gpIcznZS2TMz_qNGC2Dm9uEs4=.ce7b8b68-ff84-4b6d-93f5-25be822a93cd@github.com>
 <4GrNrzjB8oe1gZ8PvYUN49Gpeblh05T1qRHGMbmM9xE=.7fab6c8e-d4a6-4e97-a6f8-417c58a860d2@github.com>
Message-ID: <Vw9qN3CSjLifBExbIkz9H_JiboCSL8zLfVQZH_Lc4Z0=.bcfdae3f-d508-487f-a720-0ca64eafe35a@github.com>

On Thu, 14 Nov 2024 21:03:35 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Nevermind, I added a directed regression test for it now.
>
>> I see that existing `Cleaner` tests are quite rich already. 
>> ...
>> The new asserts around that code should IMO test enough with existing tests.
> 
> Should any of the existing `Cleaner` tests have `@run`s added with `-esa` ?

RunTests.gmk adds -ea -esa so the testing is done with asserts enabled when using "make run-test".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1843254523

From eirbjo at openjdk.org  Fri Nov 15 07:01:39 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 07:01:39 GMT
Subject: RFR: 8344231: SecurityManager cleanup in java.lang.module and
 jdk.internal.module [v2]
In-Reply-To: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
References: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
Message-ID: <Oq3qciVM_k32MBRNKc3YLDctr9XOwd9Rn3zsuFfrzjo=.87fafedc-c2a6-43ba-ba8b-3ea35b520f61@github.com>

> Please review this PR which removes code depending on SecurityManager from the `java.lang.module` and `jdk.internal.module` packages:
> 
> * `ModuleFinder::ofSystem` is updated to not check the `"accessSystemModules"` RuntimePermission
> * The `ModuleReferences.ExplodedModuleReader` constructor is updated to remove the check that the caller has access to the directory.
> * `Modules::addProvides` is updated to not use `AccessController::doPrivileged` when getting the module class loader
> * `SystemModuleFinder::ofSystem` is updated to not returned a wrapped result calling `AccessController::doPrivileged`
> * `SystemModuleFinders.SystemImage` is updated to remove a class level comment referring to the SM
> * `SystemModuleFinders.SystemModuleReader::checkPermissionToConnect` is removed. The URI constructor parameter in `SystemModuleReader` becomes unused and is removed.
> 
> 
> Testing: I have run `test/jdk/java/lang/module`, `test/jdk/java/lang/ModuleTests`,  and `test/jdk/java/lang/ModuleLayer` successfully. GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Remove empty line in addProvides
 - Add full stop after class description for SystemImage

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22113/files
  - new: https://git.openjdk.org/jdk/pull/22113/files/2fcec8fc..7d53f122

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22113&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22113&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22113.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22113/head:pull/22113

PR: https://git.openjdk.org/jdk/pull/22113

From eirbjo at openjdk.org  Fri Nov 15 07:01:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 07:01:40 GMT
Subject: RFR: 8344231: SecurityManager cleanup in java.lang.module and
 jdk.internal.module [v2]
In-Reply-To: <PHgSzxxT0gOg0rDGUBMcjxhBf7LRuBSmu_LFkqYSKso=.77bf1a9e-16f2-4833-8b62-aff574e64517@github.com>
References: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
 <PHgSzxxT0gOg0rDGUBMcjxhBf7LRuBSmu_LFkqYSKso=.77bf1a9e-16f2-4833-8b62-aff574e64517@github.com>
Message-ID: <CsKsbwNrSTYGj6bp-9JGhI2GuvAJ9MlSBt3bsyH-1T4=.b98093f8-e6bc-4940-901c-4c359ebb27f1@github.com>

On Fri, 15 Nov 2024 06:33:30 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Remove empty line in addProvides
>>  - Add full stop after class description for SystemImage
>
> src/java.base/share/classes/jdk/internal/module/Modules.java line 158:
> 
>> 156:         ClassLoader loader = m.getClassLoader();
>> 157: 
>> 158:         ClassLoader platformClassLoader = ClassLoaders.platformClassLoader();
> 
> You can remove the blank line at L157 now, it was only there to make the doPriv use clearer.

Removed blank line

> src/java.base/share/classes/jdk/internal/module/SystemModuleFinders.java line 364:
> 
>> 362: 
>> 363:     /**
>> 364:      * Holder class for the ImageReader
> 
> In passing, you would mind adding a full stop after ImageReader. Only noticed it with the removal of the apinote.

Added a full stop at the end of the SystemImage class description.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22113#discussion_r1843272795
PR Review Comment: https://git.openjdk.org/jdk/pull/22113#discussion_r1843273170

From henryjen at openjdk.org  Fri Nov 15 07:06:03 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 15 Nov 2024 07:06:03 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v10]
In-Reply-To: <ySIKcDuuDKixdh16Jz6ExXvc3knHn8fNB_EKfnhxqLE=.04a0dd76-8431-4f59-9da8-9edcb18e017c@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
 <ySIKcDuuDKixdh16Jz6ExXvc3knHn8fNB_EKfnhxqLE=.04a0dd76-8431-4f59-9da8-9edcb18e017c@github.com>
Message-ID: <cHx7hDcCvXC2gYiPblzZkQtSrXZWLUTqvoJ2Ys-_G4k=.7bd8155f-9b3f-4181-9597-3bca0af7e870@github.com>

On Fri, 15 Nov 2024 06:37:26 GMT, Henry Jen <henryjen at openjdk.org> wrote:

>> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
>> 
>> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
>> 
>> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
>> 
>> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
>> 
>> So we make this build in advance, and use a static array for values referred more than once.
>> 
>> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.
>
> Henry Jen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Rename based on feedback to emphasis building a snippet for loading a reference

Introduce general Snippet interface to `emit` bytecodes.
ElementLoader -> CollectionElementBuilder, which build a Snippet to load the element at index.
With that, snippets are built early for all elements, makes the setup easier to follow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21022#issuecomment-2478095845

From jrose at openjdk.org  Fri Nov 15 07:19:52 2024
From: jrose at openjdk.org (John R Rose)
Date: Fri, 15 Nov 2024 07:19:52 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v12]
In-Reply-To: <qgUbC_wHCSZSk2gaoYfACTjhMmTTJ3-Z71cf_idXfrA=.3c153927-bf07-4ad2-b296-178511a4fda8@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <qgUbC_wHCSZSk2gaoYfACTjhMmTTJ3-Z71cf_idXfrA=.3c153927-bf07-4ad2-b296-178511a4fda8@github.com>
Message-ID: <LTUgciZdYxFR0oYRxOmSyNZDNqmn4mEfuOIGYW0LiTc=.e6b28ff6-6640-44e0-83bf-0001b528bddd@github.com>

On Fri, 15 Nov 2024 05:48:27 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 179 commits:
> 
>  - Merge branch 'master' into jep-483-candidate
>  - Merge branch 'master' into jep-483-candidate
>  - fixed merge with UseCompactObjectHeaders
>  -  Merge branch 'master' into jep-483-candidate
>  - fixed merge
>  - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline
>  - @DanHeidinga comment -- exit VM when runtimeSetup() fails
>  - fixed merge
>  - Merge branch 'master' into jep-483-candidate
>  - 8343493: Perform module checks during MetaspaceShared::map_archives()
>  - ... and 169 more: https://git.openjdk.org/jdk/compare/db56266a...77b253cf

Re-reviewed.  I compared the current diffs with the diffs from my last review.
All new changes look good.
Lilliput conflict resolution looks good.  I assume we test that path.
Nice work.

One typo in `make/RunTests.gmk`:
> The AOT cache file to be usd to wun the test with

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2437843167

From alanb at openjdk.org  Fri Nov 15 07:20:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 07:20:17 GMT
Subject: Integrated: 8343982: Remove usage of security manager from ClassLoader
 and related classes
In-Reply-To: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
References: <htlCWYTJn7Yvrygyi67YdlUBs2hTBOQOBZiZhQi3oas=.3ee1cf33-dc5e-418a-ac57-3ed83be714e9@github.com>
Message-ID: <DMAYxKttI38w-3LuqQaZOrg79EloGl-AEOrktQrWIP8=.63efdc51-5176-48c4-abce-e4b29024a59a@github.com>

On Thu, 14 Nov 2024 09:00:31 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Remove the code for the now defunct SecurityManager execution mode from ClassLoader and the built-in class loader implementations. The override of getPermissions is removed from the application class loader, and from the class loaders used to support module layers.
> 
> URLCassLoader (and its implementation URLClassPath) will be handled separately as there are spec changes required, and code in URLClassPath that requires special attention.

This pull request has now been integrated.

Changeset: 0ae5748f
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0ae5748f74fda79cff8c62eafbef144cde7abf14
Stats:     439 lines in 7 files changed: 6 ins; 361 del; 72 mod

8343982: Remove usage of security manager from ClassLoader and related classes

Reviewed-by: jpai, yzheng, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/22097

From alanb at openjdk.org  Fri Nov 15 07:23:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 07:23:26 GMT
Subject: RFR: 8344231: SecurityManager cleanup in java.lang.module and
 jdk.internal.module [v2]
In-Reply-To: <Oq3qciVM_k32MBRNKc3YLDctr9XOwd9Rn3zsuFfrzjo=.87fafedc-c2a6-43ba-ba8b-3ea35b520f61@github.com>
References: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
 <Oq3qciVM_k32MBRNKc3YLDctr9XOwd9Rn3zsuFfrzjo=.87fafedc-c2a6-43ba-ba8b-3ea35b520f61@github.com>
Message-ID: <j2VgPr3dX6sUFaNDxupyacDh2bD9H8Ziv6UOkdrAssE=.b9cd94a9-bc74-48d6-b002-b73997570b50@github.com>

On Fri, 15 Nov 2024 07:01:39 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which removes code depending on SecurityManager from the `java.lang.module` and `jdk.internal.module` packages:
>> 
>> * `ModuleFinder::ofSystem` is updated to not check the `"accessSystemModules"` RuntimePermission
>> * The `ModuleReferences.ExplodedModuleReader` constructor is updated to remove the check that the caller has access to the directory.
>> * `Modules::addProvides` is updated to not use `AccessController::doPrivileged` when getting the module class loader
>> * `SystemModuleFinder::ofSystem` is updated to not returned a wrapped result calling `AccessController::doPrivileged`
>> * `SystemModuleFinders.SystemImage` is updated to remove a class level comment referring to the SM
>> * `SystemModuleFinders.SystemModuleReader::checkPermissionToConnect` is removed. The URI constructor parameter in `SystemModuleReader` becomes unused and is removed.
>> 
>> 
>> Testing: I have run `test/jdk/java/lang/module`, `test/jdk/java/lang/ModuleTests`,  and `test/jdk/java/lang/ModuleLayer` successfully. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Remove empty line in addProvides
>  - Add full stop after class description for SystemImage

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22113#pullrequestreview-2437846462

From aboldtch at openjdk.org  Fri Nov 15 07:34:42 2024
From: aboldtch at openjdk.org (Axel Boldt-Christmas)
Date: Fri, 15 Nov 2024 07:34:42 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <g1Di9Mv0Mn5mCDObDyN6bFoUD2CsreIIpsj47khZBiw=.98ca9a1e-2f1e-424e-aedd-29e1834caf5c@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
 <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>
 <nNqG5StavW_fzll_TJz8JwR8myElGIoxGDyg8giuLQY=.56af70f1-0301-4169-b70f-b83dfec8f8f6@github.com>
 <WkErNXO5MrQfZF-9CItQHXVcjSJPX5dY1J9AJ1lUjKo=.0b58ad33-1bda-4364-8094-c6100099d4cf@github.com>
 <g1Di9Mv0Mn5mCDObDyN6bFoUD2CsreIIpsj47khZBiw=.98ca9a1e-2f1e-424e-aedd-29e1834caf5c@github.com>
Message-ID: <FVaBsXlV-TiAugqm2gEu5tTm89BnK-A4mvJtFWFPXWA=.ca6eec57-5051-4cc5-b640-c410293b59a7@github.com>

On Thu, 14 Nov 2024 17:26:31 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > That is probably correct. I was however thinking that it would only be pooled asymmetrically as some type of hystereses. So you pool when you remove a node (switch the head) and keep it far an arbitrary amount of removals. So it would only really waste memory for cleaners that have this behaviour that they keep adding and removing cleanable around a NODE_CAPACITY boundary.
> 
> I have been playing with [8343704-node-cache.txt](https://github.com/user-attachments/files/17753986/8343704-node-cache.txt) -- is that what you had in mind?

Yes. It amortises the allocation over at least NODE_CAPACITY inserts, instead of 1 in the worst case. 

I have very little experience how this plays out in practice, nor how the cleanable are used. This was purely an observation based on seen a symmetrical grow/shrink behaviour of some resource.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2478136490

From alanb at openjdk.org  Fri Nov 15 07:43:39 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 07:43:39 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
Message-ID: <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>

On Thu, 14 Nov 2024 20:45:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactored to remove use of doPrivileged() and use of SecurityManager.
> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
> 
> A careful review is requested.

I did a pass over this. Most of it is okay but there are a couple of issues.

There are significant changes to ForkJoinPool under review and due to integrate any day now. I'll defer to @DougLea and @viktorklang-ora but it might be better to drop the changes to FJP from this PR and follow-up after the FJP upgrade is integrated.

src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 2104:

> 2102:             lockField.set(this, new Object());
> 2103:         } catch (IllegalAccessException | NoSuchFieldException e) {
> 2104:                 throw new RuntimeException(e);

Did you mean to change this from Error to RuntimeException? It shouldn't happen of course, but probably best not to change this.

src/java.base/share/classes/java/util/concurrent/Executors.java line 556:

> 554:      * A callable that runs under established access control settings.
> 555:      */
> 556:     private static final class PrivilegedCallable<T> implements Callable<T> {

I can't help thinking some larger cleanup or renaming will be needed here as PrivilegedXXX is misleading now.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1108:

> 1106:         implements ForkJoinWorkerThreadFactory {
> 1107:         public final ForkJoinWorkerThread newThread(ForkJoinPool pool) {
> 1108:             return new ForkJoinWorkerThread(null, pool, true, false);

This doesn't look right. For the common pool it should return InnocuousForkJoinWorkerThread(pool).

src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 244:

> 242:         @Override // paranoically
> 243:         public void setContextClassLoader(ClassLoader cl) {
> 244:             // No-op, do not change the context class loader

I don't think this we should change this in this PR. Instead, I think we need to decide what to specify.

src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 700:

> 698: 
> 699:     private void interruptAll() {
> 700:             implInterruptAll();

Rename implInterruptAll to InterruptAll and remove implInterruptAll.

src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 399:

> 397:                 if ((ccl != null) && (ccl != cl) &&
> 398:                     ((cl == null) || !isAncestor(cl, ccl))) {
> 399:                     sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass);

The ensureMemberAccess needs to stay but the checkPackageAccess can be removed.

@seanjmullan I think you'll want to study this one closely.

src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java line 385:

> 383:         try {
> 384:             MethodHandles.Lookup l2 =
> 385:                  MethodHandles.privateLookupIn(Thread.class, MethodHandles.lookup());

I assume this can be changed to ` MethodHandles.Lookup l2 = MethodHandles.privateLookupIn(Thread.class, l1);`

-------------

PR Review: https://git.openjdk.org/jdk/pull/22119#pullrequestreview-2437850784
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843295775
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843297283
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843307754
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843299121
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843300163
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843303996
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843304937

From eirbjo at openjdk.org  Fri Nov 15 07:51:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 07:51:50 GMT
Subject: Integrated: 8344179: SecurityManager cleanup in the ZIP and JAR areas
In-Reply-To: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
References: <FbFYczAoFq3QjVa16u9sDRsL6fPlIMYQgf8sDbcp2iM=.a8d33f9f-69af-411b-a294-2774e90fa298@github.com>
Message-ID: <whLBbKE-PIUf2mBE2NWhu-8bnp05d1vVD2YOr_yDGC4=.e83abf94-2783-4856-bfce-707db6ee8dc9@github.com>

On Thu, 14 Nov 2024 10:18:18 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up security manager related code in `java.util.zip` and `java.util.jar`:
> 
> * `JarFile` and `ZipFile` are updated to use `System::getProperty` instead of `GetPropertyAction::privilegedGetProperty`
> *  `ZipFile` is updated to not call SM::checkRead, SM::checkDelete when opening files
> * `ZipOutputStream` is updated to use `Boolean::getBoolean` instead of `GetBooleanAction::privilegedGetProperty`
> 
> The field `ZipFile.startsWithLoc` is deliberately left alone, that should be handled separately. I found no SM-dependent code in the ZIP or JAR tests. 
> 
> Testing: This is a cleanup PR, no tests are changed or updated. ZIP and JAR tests run green locally. GHA results pending.

This pull request has now been integrated.

Changeset: 857f68c6
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/857f68c60f9c82c38f3b3a83692477dfe50a6ea4
Stats:     17 lines in 3 files changed: 0 ins; 12 del; 5 mod

8344179: SecurityManager cleanup in the ZIP and JAR areas

Reviewed-by: lancea, rriggs, mullan, jpai

-------------

PR: https://git.openjdk.org/jdk/pull/22099

From eirbjo at openjdk.org  Fri Nov 15 07:51:52 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 07:51:52 GMT
Subject: Integrated: 8344183: (zipfs) SecurityManager cleanup in the ZipFS area
In-Reply-To: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
References: <3bxWpl92Zkw_DCE_jDTLCcAtBftNE9lsHTq9vxHXgEg=.7069bd42-3f15-4664-8370-889ef812bbc1@github.com>
Message-ID: <wAKdtQAVVDLCCDbeFLiHvkc9q_Ek7F-bqdFVyVULQfQ=.ebc10952-ebc0-4e16-8ac9-cba37c7e6bf0@github.com>

On Thu, 14 Nov 2024 11:21:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up SecurityManager-related code following JEP-486 integraion.
> 
> * `ZipFileSystem` is updated to not perform `AccessController::doPrivileged`
> * `ZipFileSystemProvider` is updated to not perform `AccessController::doPrivileged`
> *  The test `TestPosix` is updated to perform `AccessController.doPrivileged`
> 
> This change should be relatively straight-forward to review. Reviewers may want to look extra close at the exception-unwrapping code in `ZipFileSystem::initOwner` and `ZipFileSystem::initGroup`.
> 
> Testing: Tests in `test/jdk/jdk/nio/zipfs` run green locally.

This pull request has now been integrated.

Changeset: bfee766f
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/bfee766f035fb1b122cd3f3703b9e2a2d85abfe6
Stats:     85 lines in 3 files changed: 3 ins; 57 del; 25 mod

8344183: (zipfs) SecurityManager cleanup in the ZipFS area

Reviewed-by: mullan, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/22101

From mbaesken at openjdk.org  Fri Nov 15 09:24:03 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Nov 2024 09:24:03 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302
Message-ID: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>

On AIX we run into errors below, for example in test tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug binaries, opt worked :

jlink options: --output java-base-with-opts-jlink-tmp --add-modules jdk.jlink,java.base --generate-linkable-runtime --keep-packaged-modules=java-base-with-opts-jlink-tmp/jmods
Error: Java heap space
java.lang.OutOfMemoryError: Java heap space
at java.base/java.io.InputStream.readNBytes(InputStream.java:447)
at java.base/java.io.InputStream.readAllBytes(InputStream.java:348)
at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127)
at jdk.jlink/jdk.tools.jlink.internal.runtimelink.ResourcePoolReader.getResourceBytes(ResourcePoolReader.java:54)
at jdk.jlink/jdk.tools.jlink.internal.runtimelink.JimageDiffGenerator.generateDiff(JimageDiffGenerator.java:89)
at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.addResourceDiffFiles(ImageFileCreator.java:357)
at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:264)
at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:202)
at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:131)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:1041)
at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:501)
at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:294)
at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:713)
at AbstractLinkableRuntimeTest.createRuntimeLinkImage(AbstractLinkableRuntimeTest.java:273)
at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:126)
at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:121)
at AddOptionsTest.runTest(AddOptionsTest.java:64)
at AbstractLinkableRuntimeTest.run(AbstractLinkableRuntimeTest.java:62)
at AddOptionsTest.main(AddOptionsTest.java:49)
at java.base/java.lang.invoke.LambdaForm$DMH/0x0a0001009070c3e0.invokeStatic(LambdaForm$DMH)
at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090710c10.invoke(LambdaForm$MH)
at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090711408.invokeExact_MT(LambdaForm$MH)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invokeImpl(DirectMethodHandleAccessor.java:155)
at java.base/jdk.internal.reflect.DirectMethodHandleAccessor.invoke(DirectMethodHandleAccessor.java:104)
at java.base/java.lang.reflect.Method.invoke(Method.java:567)
at com.sun.javatest.regtest.agent.MainWrapper$MainTask.run(MainWrapper.java:138)
at java.base/java.lang.Thread.runWith(Thread.java:1589)
at java.base/java.lang.Thread.run(Thread.java:1576)

java.lang.AssertionError: Unexpected failure: 4
at tests.Result.assertSuccess(Result.java:80)

The tests need more memory and one also needs a higher timeout value to succeed .

-------------

Commit messages:
 - JDK-8344036

Changes: https://git.openjdk.org/jdk/pull/22140/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22140&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344036
  Stats: 15 lines in 14 files changed: 1 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/22140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22140/head:pull/22140

PR: https://git.openjdk.org/jdk/pull/22140

From liach at openjdk.org  Fri Nov 15 09:39:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 09:39:44 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry [v3]
In-Reply-To: <3IKnLe_6l7xNYRdVphmiCfVEdvpKbL_u5iubSndVW9Y=.a05e4bb6-ee8b-4834-8cb7-519b845c5b04@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
 <3IKnLe_6l7xNYRdVphmiCfVEdvpKbL_u5iubSndVW9Y=.a05e4bb6-ee8b-4834-8cb7-519b845c5b04@github.com>
Message-ID: <VHGmHx8GJH1L_gTuoPTypCCv0Rq6ubSvYv-znLmFj6o=.8398b73e-5a88-49d8-8efb-0fa54e07d720@github.com>

On Thu, 14 Nov 2024 17:12:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
>> 
>> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more fixes

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22107#pullrequestreview-2438123534

From eirbjo at openjdk.org  Fri Nov 15 09:46:59 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 09:46:59 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util
Message-ID: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>

Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:

* `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
* `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
* `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
* `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation

Verification: GHA results pending.

-------------

Commit messages:
 - Clean up ClassFileDumper, RandomSupport and StaticProperty following JEP486 integration

Changes: https://git.openjdk.org/jdk/pull/22141/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22141&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344289
  Stats: 116 lines in 3 files changed: 6 ins; 89 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/22141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22141/head:pull/22141

PR: https://git.openjdk.org/jdk/pull/22141

From duke at openjdk.org  Fri Nov 15 09:47:57 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Fri, 15 Nov 2024 09:47:57 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform
Message-ID: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>

To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.

I have referred to the following for how to use chcp:
?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers

After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.

Thanks

-------------

Commit messages:
 - Merge branch 'openjdk:master' into fix_Win8301247Test_bug
 - Fix comment
 - Merge branch 'openjdk:master' into fix_Win8301247Test_bug
 - Insert newline
 - Fix WindowsHelper.java
 - Fix Win8301247Test bug
 - Fix Win8301247Test bug

Changes: https://git.openjdk.org/jdk/pull/22142/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344275
  Stats: 37 lines in 2 files changed: 23 ins; 1 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/22142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22142/head:pull/22142

PR: https://git.openjdk.org/jdk/pull/22142

From shade at openjdk.org  Fri Nov 15 10:05:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Nov 2024 10:05:29 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v8]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <sP0fEG0kWc5ftWFvPhFM2KtcrwWizw_zFv67gp2uN0o=.5bb8eab9-db17-4b5e-8ec0-f9540c8b290d@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Add the node cache

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/c511c9bb..ae3c6c00

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=06-07

  Stats: 32 lines in 1 file changed: 24 ins; 3 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Fri Nov 15 10:05:29 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Nov 2024 10:05:29 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v7]
In-Reply-To: <FVaBsXlV-TiAugqm2gEu5tTm89BnK-A4mvJtFWFPXWA=.ca6eec57-5051-4cc5-b640-c410293b59a7@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pUlIt1tEho2RABy2-FWjvwSqvB7l1twArCjhmkzfhvc=.d298f17b-672f-4f91-ae86-3cafc931a92d@github.com>
 <FlR8w8NKf1OYhWRggHdmhOfEKRulcZD7ZYFdxZH2d88=.f135c0a9-ed9d-4075-befa-02736464ea5b@github.com>
 <nNqG5StavW_fzll_TJz8JwR8myElGIoxGDyg8giuLQY=.56af70f1-0301-4169-b70f-b83dfec8f8f6@github.com>
 <WkErNXO5MrQfZF-9CItQHXVcjSJPX5dY1J9AJ1lUjKo=.0b58ad33-1bda-4364-8094-c6100099d4cf@github.com>
 <g1Di9Mv0Mn5mCDObDyN6bFoUD2CsreIIpsj47khZBiw=.98ca9a1e-2f1e-424e-aedd-29e1834caf5c@github.com>
 <FVaBsXlV-TiAugqm2gEu5tTm89BnK-A4mvJtFWFPXWA=.ca6eec57-5051-4cc5-b640-c410293b59a7@github.com>
Message-ID: <mkO0SxSZzaommXlNNerLG2eYJpN1og6vlc45g811AH8=.0bd99b66-be31-41d1-9b6e-687c321dc486@github.com>

On Fri, 15 Nov 2024 07:32:37 GMT, Axel Boldt-Christmas <aboldtch at openjdk.org> wrote:

> > I have been playing with [8343704-node-cache.txt](https://github.com/user-attachments/files/17753986/8343704-node-cache.txt) -- is that what you had in mind?
> 
> Yes. It amortises the allocation over at least NODE_CAPACITY inserts, instead of 1 in the worst case.

Pushed that into PR. There is some measurable impact for dealing with this node cache during heavy churn, but it is still well within the improvements margin we get wholesale.

I am willing to accept this single-slot cache for three reasons: a) crossing the artificial border with just a single cleaner registering and unregistering looks like something we want to mitigate to avoid surprises; b) Cleaners are recommended by Javadoc to be shared, so wasting another node should not be as painful; c) the implementation and maintenance cost is not high.

But I would draw the line at this heuristics, and do nothing smarter :)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2478457365

From sgehwolf at openjdk.org  Fri Nov 15 10:16:44 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Nov 2024 10:16:44 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302
In-Reply-To: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
Message-ID: <3kPKbOzazavfIbgBj_kFY6LNl8J3_4_RcN2-mBKg_tk=.9330dfb4-6a37-4cc4-a5be-05f4cadb859c@github.com>

On Fri, 15 Nov 2024 09:18:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX we run into errors below, for example in test tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug binaries, opt worked :
> 
> jlink options: --output java-base-with-opts-jlink-tmp --add-modules jdk.jlink,java.base --generate-linkable-runtime --keep-packaged-modules=java-base-with-opts-jlink-tmp/jmods
> Error: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.io.InputStream.readNBytes(InputStream.java:447)
> at java.base/java.io.InputStream.readAllBytes(InputStream.java:348)
> at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127)
> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.ResourcePoolReader.getResourceBytes(ResourcePoolReader.java:54)
> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.JimageDiffGenerator.generateDiff(JimageDiffGenerator.java:89)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.addResourceDiffFiles(ImageFileCreator.java:357)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:264)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:202)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:131)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:1041)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:501)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:294)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:713)
> at AbstractLinkableRuntimeTest.createRuntimeLinkImage(AbstractLinkableRuntimeTest.java:273)
> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:126)
> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:121)
> at AddOptionsTest.runTest(AddOptionsTest.java:64)
> at AbstractLinkableRuntimeTest.run(AbstractLinkableRuntimeTest.java:62)
> at AddOptionsTest.main(AddOptionsTest.java:49)
> at java.base/java.lang.invoke.LambdaForm$DMH/0x0a0001009070c3e0.invokeStatic(LambdaForm$DMH)
> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090710c10.invoke(LambdaForm$MH)
> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090711408.invokeExact_MT(LambdaForm$MH)
> at ja...

It seems a bit excessive to bump to twice the size while we won't need it for any platform other than AIX. Would `-Xmx1500m` work as well? Aside, those tests now potentially run on machines with 2gb of max memory with a 2gb heap setting.

Where you able to reproduce outside of testing?


at jdk.jlink/jdk.tools.jlink.internal.runtimelink.ResourcePoolReader.getResourceBytes(ResourcePoolReader.java:54)
at jdk.jlink/jdk.tools.jlink.internal.runtimelink.JimageDiffGenerator.generateDiff(JimageDiffGenerator.java:89)


It would be interesting to know whether or not the resource that is being compared is the same when the error happens for each run. Have you tried investigating?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22140#issuecomment-2478478039

From duke at openjdk.org  Fri Nov 15 10:19:22 2024
From: duke at openjdk.org (Glavo)
Date: Fri, 15 Nov 2024 10:19:22 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
Message-ID: <Mat3YDll2sngEQtQ1eJtTu2WzVKTJ3nfxS6LXrKTBnk=.a868c0a1-dc35-4dff-9193-e16c28c5af52@github.com>

On Fri, 15 Nov 2024 07:25:10 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored to remove use of doPrivileged() and use of SecurityManager.
>> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
>> 
>> A careful review is requested.
>
> src/java.base/share/classes/java/util/concurrent/Executors.java line 556:
> 
>> 554:      * A callable that runs under established access control settings.
>> 555:      */
>> 556:     private static final class PrivilegedCallable<T> implements Callable<T> {
> 
> I can't help thinking some larger cleanup or renaming will be needed here as PrivilegedXXX is misleading now.

This class is currently meaningless, perhaps it should be carefully removed and the documentation for `priviledgedCallable` should be updated.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843541695

From shade at openjdk.org  Fri Nov 15 10:19:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Nov 2024 10:19:46 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v9]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <JE-8A6iE-MZ50BpA8VbCMBmm29cqnOR4vU-kcXm-8cM=.fd906924-946f-49b8-bd3e-816322932b4f@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Do not need -ea -esa in tests, our testing infra adds them already

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/ae3c6c00..a7584bcc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=08
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=07-08

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From duke at openjdk.org  Fri Nov 15 10:19:46 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Fri, 15 Nov 2024 10:19:46 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v8]
In-Reply-To: <sP0fEG0kWc5ftWFvPhFM2KtcrwWizw_zFv67gp2uN0o=.5bb8eab9-db17-4b5e-8ec0-f9540c8b290d@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <sP0fEG0kWc5ftWFvPhFM2KtcrwWizw_zFv67gp2uN0o=.5bb8eab9-db17-4b5e-8ec0-f9540c8b290d@github.com>
Message-ID: <huRaj7lMPAUFB5-EkaW6Xjg2KCNBfPyTq9ao-c39pLQ=.340c8505-5017-4460-9efa-33e85d8ae803@github.com>

On Fri, 15 Nov 2024 10:05:29 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Add the node cache

Not that it was the main problem here (since using array-linked lists deliver already the major improvement with less changes, kudos!) - but in case having a lock-free structure can be of any help, in JCTools we have 
and https://github.com/JCTools/JCTools/blob/master/jctools-core/src/main/java/org/jctools/queues/MpmcUnboundedXaddArrayQueue.java which is decently scalable offer side (less consumer-side) and can save reusing chuncks, becoming way simpler.
If can be of any interest I can create a gist with a simplified, non-Unsafe version.

Otherwise https://github.com/pramalhe/ConcurrencyFreaks/blob/master/Java/com/concurrencyfreaks/queues/array/FAAArrayQueue.java it's as simple as it looks, but probably need to make it linearizable - IDK.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2478475080

From shade at openjdk.org  Fri Nov 15 10:19:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Nov 2024 10:19:46 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v4]
In-Reply-To: <Vw9qN3CSjLifBExbIkz9H_JiboCSL8zLfVQZH_Lc4Z0=.bcfdae3f-d508-487f-a720-0ca64eafe35a@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <iPwwz5hqVAdjLP4_TS0W0Voy8xi84-RWlGC3g0Z0UKk=.445cfba4-9552-4ced-9218-22cc3b534d2e@github.com>
 <KOMu46T02aAy9jCPTGXd7n5-dI49hY2C3KJyKlhLg4Y=.3d143ad1-15ae-4d6e-888e-d2b1d43d9a3b@github.com>
 <9wkfIDsApZu0e8OJxHMwE6U9XjTWnc-FcRdndXXPLM4=.08ca0c85-3199-439b-bec4-fb5e6a1dff5c@github.com>
 <BzwB7V5Agdd_qjtJePU2Tzo97et4lf8hFjlyCyhH4ik=.47d0df0f-095b-419a-a578-d044721d6c10@github.com>
 <k0s5nWTBudBW0HYAlqPnWy-zXKIeFu4aaKXWwF7GOZE=.3737e4f3-81bd-4604-bf37-861df29043c7@github.com>
 <_8tJj0lTY7DTBd_M4vZxFAdGL5ekCc5DmrSq3fq3078=.35798b85-c920-4cfd-a52b-ff9e8e9ec2b5@github.com>
 <j1ATGzp3JUUnpEzTq-gpIcznZS2TMz_qNGC2Dm9uEs4=.ce7b8b68-ff84-4b6d-93f5-25be822a93cd@github.com>
 <4GrNrzjB8oe1gZ8PvYUN49Gpeblh05T1qRHGMbmM9xE=.7fab6c8e-d4a6-4e97-a6f8-417c58a860d2@github.com>
 <Vw9qN3CSjLifBExbIkz9H_JiboCSL8zLfVQZH_Lc4Z0=.bcfdae3f-d508-487f-a720-0ca64eafe35a@github.com>
Message-ID: <xYtSJDFxm0OmFxumz2lR4MXdrhjgoP4G8iropU6W0iA=.9260b87a-e39a-4d90-b97f-f842002ae26b@github.com>

On Fri, 15 Nov 2024 06:36:22 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> I see that existing `Cleaner` tests are quite rich already. 
>>> ...
>>> The new asserts around that code should IMO test enough with existing tests.
>> 
>> Should any of the existing `Cleaner` tests have `@run`s added with `-esa` ?
>
> RunTests.gmk adds -ea -esa so the testing is done with asserts enabled when using "make run-test".

So then adding `-ea -esa` is superfluous in the tests. I removed these from the test for extra cleanliness.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1843541711

From sgehwolf at openjdk.org  Fri Nov 15 10:55:11 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Nov 2024 10:55:11 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302
In-Reply-To: <3kPKbOzazavfIbgBj_kFY6LNl8J3_4_RcN2-mBKg_tk=.9330dfb4-6a37-4cc4-a5be-05f4cadb859c@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
 <3kPKbOzazavfIbgBj_kFY6LNl8J3_4_RcN2-mBKg_tk=.9330dfb4-6a37-4cc4-a5be-05f4cadb859c@github.com>
Message-ID: <wQzuIe4HhAu9Fj4TWhwQM57Z-1FJ65UqwBoyAuJxn80=.cb4d7d0e-0a0e-4293-98e7-3d7baa7584c3@github.com>

On Fri, 15 Nov 2024 10:13:16 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Where you able to reproduce outside of testing?

Something like this should give you an idea what the RSS size ends up being (not sure about the AIX equivalent to get that info, though; this is Linux)


$ rm -rf ./build/linkable-runtime/ && \time --format "Max RSS: %M KB" ./build/linux-x86_64-server-fastdebug/images/jdk/bin/jlink -J-Xmx1g --add-modules java.base,jdk.jlink --generate-linkable-runtime --keep-packaged-modules=./build/linkable-runtime/jmods --output ./build/linkable-runtime/
Max RSS: 569332 KB

$ rm -rf ./build/linkable-runtime/ && \time --format "Max RSS: %M KB" ./build/linux-x86_64-server-fastdebug/images/jdk/bin/jlink -J-Xmx1g --add-modules ALL-MODULE-PATH --generate-linkable-runtime --keep-packaged-modules=./build/linkable-runtime/jmods --output ./build/linkable-runtime/
WARNING: Using incubator modules: jdk.incubator.vector
Max RSS: 593816 KB

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22140#issuecomment-2478546921

From jpai at openjdk.org  Fri Nov 15 11:05:01 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Nov 2024 11:05:01 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v6]
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <rjcbCy4S41dCiq08jmUYBmOJQ5FE1thHCxpLaTMo9bU=.ec4253a6-252c-403d-b1a3-1c38eb59af10@github.com>

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

Jaikiran Pai has updated the pull request incrementally with two additional commits since the last revision:

 - Lance's review - specify methods that throw IllegalStateException if the Inflater/Deflater is closed
 - Roger's suggestion - Make Inflater.close() and Deflater.close() final, also update the new tests to match this change

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19675/files
  - new: https://git.openjdk.org/jdk/pull/19675/files/f1c57d0b..56e6e088

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=04-05

  Stats: 203 lines in 4 files changed: 16 ins; 172 del; 15 mod
  Patch: https://git.openjdk.org/jdk/pull/19675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675

PR: https://git.openjdk.org/jdk/pull/19675

From jpai at openjdk.org  Fri Nov 15 11:15:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Nov 2024 11:15:28 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v7]
In-Reply-To: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
Message-ID: <3R1OyryqFGZnEHiYAZP3bQkhcaZRNkyZ0DanYU0AmEY=.f9074fd7-e97b-4462-8d17-643ff79f2c70@github.com>

> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
> 
> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
> 
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
> 
> To summarize those discussions, we had concluded that:
> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
> 
> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
> 
> I'll file a CSR shortly.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  missed a few methods for specifying IllegalStateException

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/19675/files
  - new: https://git.openjdk.org/jdk/pull/19675/files/56e6e088..108b858a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=19675&range=05-06

  Stats: 14 lines in 2 files changed: 14 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/19675.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19675/head:pull/19675

PR: https://git.openjdk.org/jdk/pull/19675

From jpai at openjdk.org  Fri Nov 15 11:15:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Nov 2024 11:15:30 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v5]
In-Reply-To: <TeT9OHflJUVSo6Ah_358k4w9kU3Vy9A7cygTwLDPGdQ=.802aa986-30b8-421c-b5fc-91c32cbefb62@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <WDw6WO-9RwCsJiqg-318U_v2Dd4omv0-7mHXxWp_cNw=.dadeb973-9649-419d-a322-e9c5ec092dbe@github.com>
 <TeT9OHflJUVSo6Ah_358k4w9kU3Vy9A7cygTwLDPGdQ=.802aa986-30b8-421c-b5fc-91c32cbefb62@github.com>
Message-ID: <wyyCpXnxF0ob1ozksrxUTCR4WpMS_RQ7O-lw0rve2t4=.86134517-867b-4e96-b735-5c6cfa03e4b9@github.com>

On Thu, 14 Nov 2024 17:33:34 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - merge latest from master branch
>>  - update tests to match the new specification
>>  - Stuart's review - update the close() and end() expectations
>>  - Stuart's review - improve class level javadoc
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - Chen's suggestion - improve code comment
>>  - convert the tests to junit
>>  - fix whitespace
>>  - 8225763: Inflater and Deflater should implement AutoCloseable
>
> src/java.base/share/classes/java/util/zip/Deflater.java line 878:
> 
>> 876:      * If this method is invoked multiple times, the subsequent calls are treated as a no-op.
>> 877:      * Several other methods defined by this class will throw an {@link IllegalStateException}
>> 878:      * if invoked on a closed {@code Deflater}.
> 
> All of the methods which call ensureOpen should either document that an IllegalStateException may be thrown or you could add it to the header of the class.

Hello Lance, you are right - I forgot to do that when I changed it to throw IllegalStateException from the previous NullPointerException. I've now updated the PR to document this on individual methods in the Inflater/Deflater which throw this exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1843607156

From jpai at openjdk.org  Fri Nov 15 11:15:30 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Nov 2024 11:15:30 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <rM5LNCv1OTwqxB5SjyR9wn_j3lX40OALz4JGT962Upc=.67ff5905-6dfb-4b53-868f-e7ecc6d9e7be@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
 <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
 <HaROiuwLaPbPqU0yCkjrF_sErOyFu9SmyJ2Kz7mq1rw=.5dcd201b-6fe4-4c2b-a4c1-d9598bbdf641@github.com>
 <45vdxLi7glsU82ec1dPxT-FEfrJVxAWliwOQ_-sGKko=.8795c8d8-c690-4df1-a98e-47fe44e32429@github.com>
 <_CPEGrm4gbzEuIVwTRde89XK1U7swqb-qCFf8l_RWyc=.6078e00c-4f3f-4925-8052-ba4d6a07919c@github.com>
 <rM5LNCv1OTwqxB5SjyR9wn_j3lX40OALz4JGT962Upc=.67ff5905-6dfb-4b53-868f-e7ecc6d9e7be@github.com>
Message-ID: <6xx9zAE5fUCAqf3XduM8a16zI13vwiAGpXD-9dsRLk8=.5b2e3d5a-425a-40f5-b3bb-f8fc7b3b08dd@github.com>

On Thu, 14 Nov 2024 20:36:45 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Hello Chen, corpus analysis shows that there are no subclasses of Inflater/Deflater which have a `close()` method.
>
> Great news!  Feel free to make their close final.

I have updated the PR to follow Roger's suggestion of marking this new `close()` method on `Inflater` and `Deflater` classes as `final`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1843608012

From jpai at openjdk.org  Fri Nov 15 11:15:36 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Nov 2024 11:15:36 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v4]
In-Reply-To: <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <N-BlUGCjLTSEbL_zqx00ZuxhcJQriIV5-mnxss6Kbyk=.103fc3ae-aa41-4e98-b065-83bde0383303@github.com>
 <gBOtO1o4YNfiV_4DvY6rxjQ6icEdPzs7bPFHXzbbU6A=.223b1412-4180-4846-bef0-525eb18bcba5@github.com>
Message-ID: <u0uvv5C25_xmRVBLP6ZeRXYz8YiKkgzJC8YmowIN1FQ=.ba088a92-ce3f-4dc0-9ce0-b4c4e73dc7d0@github.com>

On Thu, 7 Nov 2024 14:34:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
>> 
>>  - update tests to match the new specification
>>  - Stuart's review - update the close() and end() expectations
>>  - Stuart's review - improve class level javadoc
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - Chen's suggestion - improve code comment
>>  - convert the tests to junit
>>  - fix whitespace
>>  - 8225763: Inflater and Deflater should implement AutoCloseable
>
> src/java.base/share/classes/java/util/zip/Inflater.java line 719:
> 
>> 717:      */
>> 718:     @Override
>> 719:     public void close() {
> 
> Ditto, should this be `final` to be clear about what should be overridden to perform cleanup.

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1843608174

From jpai at openjdk.org  Fri Nov 15 11:23:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Fri, 15 Nov 2024 11:23:28 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v5]
In-Reply-To: <TeT9OHflJUVSo6Ah_358k4w9kU3Vy9A7cygTwLDPGdQ=.802aa986-30b8-421c-b5fc-91c32cbefb62@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <WDw6WO-9RwCsJiqg-318U_v2Dd4omv0-7mHXxWp_cNw=.dadeb973-9649-419d-a322-e9c5ec092dbe@github.com>
 <TeT9OHflJUVSo6Ah_358k4w9kU3Vy9A7cygTwLDPGdQ=.802aa986-30b8-421c-b5fc-91c32cbefb62@github.com>
Message-ID: <qfiRQjaGw8NACPQOqSDoawjsdxOvALtPwKFU1sZP1sk=.016de9c1-3a80-4528-8f33-557b6d743f89@github.com>

On Thu, 14 Nov 2024 17:29:06 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 10 additional commits since the last revision:
>> 
>>  - merge latest from master branch
>>  - update tests to match the new specification
>>  - Stuart's review - update the close() and end() expectations
>>  - Stuart's review - improve class level javadoc
>>  - merge latest from master branch
>>  - merge latest from master branch
>>  - Chen's suggestion - improve code comment
>>  - convert the tests to junit
>>  - fix whitespace
>>  - 8225763: Inflater and Deflater should implement AutoCloseable
>
> src/java.base/share/classes/java/util/zip/Deflater.java line 66:
> 
>> 64:  * usage with try-with-resources, this class implements {@link AutoCloseable}. The
>> 65:  * {@link #close()} method of this class calls {@code end()} to clean up its
>> 66:  * resources. Subclasses are responsible for the cleanup of resources
> 
> As part of the clarification, do we need to state the verbiage above regarding try-with-resources specifically?
> 
> I did a quick scan of some of the other classes implementing AutoClosable and did not see many cases of that in the documentation most likely due to that behavior is clear in the documentation for AutoClosable

Stuart in one of his review comments in this PR had noted that:

> I think the class specification needs to be clearer about the positioning of end() and close(). The end() method has done the real work of "closing" since the classes were introduced. We're retrofitting them to to have a close() method that's essentially just a synonym for end(), and it's still perfectly legal for clients and subclasses to call end() instead of close(). I think we need to say that close() is present mainly to support AutoCloseable and try-with-resources.

The current wording of that class level javadoc is my attempt to implement that suggestion. Do you think we can word it differently and yet convey the purpose of close()?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1843618146

From prappo at openjdk.org  Fri Nov 15 11:35:40 2024
From: prappo at openjdk.org (Pavel Rappo)
Date: Fri, 15 Nov 2024 11:35:40 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v6]
In-Reply-To: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
Message-ID: <I_76U8sLnYjjksGSKTE55NmlDK5fmk9Pou6t_sUwegY=.bca73f06-7e51-4d83-a31e-65ca4908241c@github.com>

> Prepare for JDK 25.

Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:

 - Update --release 24 symbol information for JDK 24 build 24
   
   The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 23
   
   The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 22
   
   The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
 - Merge branch 'master' into 8342979
 - Update --release 24 symbol information for JDK 24 build 21
   
   The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
 - Add forgotten .jcheck/conf
 - Initial commit

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21763/files
  - new: https://git.openjdk.org/jdk/pull/21763/files/84dce9a3..354ed5a8

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21763&range=04-05

  Stats: 111558 lines in 2961 files changed: 29381 ins; 72609 del; 9568 mod
  Patch: https://git.openjdk.org/jdk/pull/21763.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21763/head:pull/21763

PR: https://git.openjdk.org/jdk/pull/21763

From mbaesken at openjdk.org  Fri Nov 15 11:40:45 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Fri, 15 Nov 2024 11:40:45 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302
In-Reply-To: <wQzuIe4HhAu9Fj4TWhwQM57Z-1FJ65UqwBoyAuJxn80=.cb4d7d0e-0a0e-4293-98e7-3d7baa7584c3@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
 <3kPKbOzazavfIbgBj_kFY6LNl8J3_4_RcN2-mBKg_tk=.9330dfb4-6a37-4cc4-a5be-05f4cadb859c@github.com>
 <wQzuIe4HhAu9Fj4TWhwQM57Z-1FJ65UqwBoyAuJxn80=.cb4d7d0e-0a0e-4293-98e7-3d7baa7584c3@github.com>
Message-ID: <BpzkfnSjoHQI3Ifs7cpelQqSCzZiQXx7Om2MvGbvP1s=.53849354-cb23-4075-8e4f-14b96a55a3f6@github.com>

On Fri, 15 Nov 2024 10:50:47 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Where you able to reproduce outside of testing?

No, it failed only in our central test environment, not for single runs of one of these tests with jtreg in my local AIX dev env .
But the central tests use fastdebug and I use locally mostly opt builds so this might be a reason too.
Exception is the test with the timeout error / timeout increase, I saw this too locally.

Regarding Xmx1500m I can try this , or I can also copy the whole test header block and use 1g  for all platforms and 2g or 1500m for AIX (would be a bit code duplication of course).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22140#issuecomment-2478625367

From asotona at openjdk.org  Fri Nov 15 11:42:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 11:42:58 GMT
Subject: RFR: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry [v3]
In-Reply-To: <3IKnLe_6l7xNYRdVphmiCfVEdvpKbL_u5iubSndVW9Y=.a05e4bb6-ee8b-4834-8cb7-519b845c5b04@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
 <3IKnLe_6l7xNYRdVphmiCfVEdvpKbL_u5iubSndVW9Y=.a05e4bb6-ee8b-4834-8cb7-519b845c5b04@github.com>
Message-ID: <0jID29ERwJ6bx8ajFeFftkSBHkciFYvHjU4S6D5PkQo=.8bb7a575-d3fd-4698-8c79-674aa65c75d2@github.com>

On Thu, 14 Nov 2024 17:12:55 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
>> 
>> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request incrementally with one additional commit since the last revision:
> 
>   more fixes

Thank you for the review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22107#issuecomment-2478630042

From asotona at openjdk.org  Fri Nov 15 11:42:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 11:42:58 GMT
Subject: Integrated: 8343881: java.lang.classfile.Attribute  attributeName()
 method should return Utf8Entry
In-Reply-To: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
References: <t4RhwTjhSDYWTJWXSoaZnlKK18CZMvcq8ZVKPEghbEQ=.f377e776-ffb7-4eb6-814f-b92185c6d3d4@github.com>
Message-ID: <SdpwqiuhiMN0ZBqwqD0lq0Uk2eZJze8I7lb52X8GR-k=.16594ac8-a0ac-4aa1-8c5c-be03f277b1f4@github.com>

On Thu, 14 Nov 2024 14:19:58 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API usually expose names in a form of `java.lang.classfile.constantpool.Utf8Entry`. Unfortunately `java.lang.classfile.Attribute::attributeName` method was omitted during the API review and it returns inflated `String` value of the name.
> 
> This patch changes return type of `java.lang.classfile.Attribute::attributeName` from `String` to `java.lang.classfile.constantpool.Utf8Entry`.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: ba393219
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ba39321902400e103cdce0b326d0005123b1d87e
Stats:     420 lines in 29 files changed: 375 ins; 5 del; 40 mod

8343881: java.lang.classfile.Attribute  attributeName() method should return Utf8Entry

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/22107

From asotona at openjdk.org  Fri Nov 15 11:53:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 11:53:00 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
   #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
   #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
   #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
   #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
   #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
   #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
   #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
   #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
   #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
   #	src/java.base/share/classes/java/lang/classfile/Instruction.java
   #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynamicEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPool.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantPoolBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantValueEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/DynamicConstantPoolEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/FieldRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/InterfaceMethodRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/LoadableConstantEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/MethodRefEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/ModuleEntry.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PackageEntry.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/NewMultiArrayInstruction.java
 - Updated copyright years
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/StackMapFrameInfo.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/FieldModel.java
   #	src/java.base/share/classes/java/lang/classfile/MethodModel.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableInfo.java
   #	src/java.base/share/classes/java/lang/classfile/attribute/RecordComponentInfo.java
   #	src/java.base/share/classes/java/lang/classfile/instruction/LocalVariable.java
 - Merge branch 'master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
   #	src/java.base/share/classes/java/lang/classfile/Opcode.java
   #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
 - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
   
   # Conflicts:
   #	src/java.base/share/classes/java/lang/classfile/Annotation.java
   #	src/java.base/share/classes/java/lang/classfile/AnnotationValue.java
   #	src/java.base/share/classes/java/lang/classfile/AttributeMapper.java
   #	src/java.base/share/classes/java/lang/classfile/TypeAnnotation.java
   #	src/java.base/share/classes/java/lang/classfile/constantpool/PoolEntry.java
   #	src/jdk.javadoc/share/classes/jdk/javadoc/internal/html/HtmlId.java
 - Merge branch 'master' into JDK-8334714-final
 - ... and 2 more: https://git.openjdk.org/jdk/compare/ba393219...807e8b2a

-------------

Changes: https://git.openjdk.org/jdk/pull/19826/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=19826&range=08
  Stats: 799 lines in 165 files changed: 0 ins; 487 del; 312 mod
  Patch: https://git.openjdk.org/jdk/pull/19826.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/19826/head:pull/19826

PR: https://git.openjdk.org/jdk/pull/19826

From lancea at openjdk.org  Fri Nov 15 12:21:52 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 15 Nov 2024 12:21:52 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v5]
In-Reply-To: <qfiRQjaGw8NACPQOqSDoawjsdxOvALtPwKFU1sZP1sk=.016de9c1-3a80-4528-8f33-557b6d743f89@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <WDw6WO-9RwCsJiqg-318U_v2Dd4omv0-7mHXxWp_cNw=.dadeb973-9649-419d-a322-e9c5ec092dbe@github.com>
 <TeT9OHflJUVSo6Ah_358k4w9kU3Vy9A7cygTwLDPGdQ=.802aa986-30b8-421c-b5fc-91c32cbefb62@github.com>
 <qfiRQjaGw8NACPQOqSDoawjsdxOvALtPwKFU1sZP1sk=.016de9c1-3a80-4528-8f33-557b6d743f89@github.com>
Message-ID: <AGhgzPj3GaxzVBQtnV0Iv1SJxYyF4Oa6PAaJ-3-lMv4=.5888701e-a691-4923-85cd-6330ad167eeb@github.com>

On Fri, 15 Nov 2024 11:19:43 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/zip/Deflater.java line 66:
>> 
>>> 64:  * usage with try-with-resources, this class implements {@link AutoCloseable}. The
>>> 65:  * {@link #close()} method of this class calls {@code end()} to clean up its
>>> 66:  * resources. Subclasses are responsible for the cleanup of resources
>> 
>> As part of the clarification, do we need to state the verbiage above regarding try-with-resources specifically?
>> 
>> I did a quick scan of some of the other classes implementing AutoClosable and did not see many cases of that in the documentation most likely due to that behavior is clear in the documentation for AutoClosable
>
> Stuart in one of his review comments in this PR had noted that:
> 
>> I think the class specification needs to be clearer about the positioning of end() and close(). The end() method has done the real work of "closing" since the classes were introduced. We're retrofitting them to to have a close() method that's essentially just a synonym for end(), and it's still perfectly legal for clients and subclasses to call end() instead of close(). I think we need to say that close() is present mainly to support AutoCloseable and try-with-resources.
> 
> The current wording of that class level javadoc is my attempt to implement that suggestion. Do you think we can word it differently and yet convey the purpose of close()?

Hi Jai,

I am not convinced we need to call this out specifically at the class level given  the classes implements AutoClosable and close indicates it calls end.  We will also  want to add a Release Note which can help further clarify this

Now that being said, what I would suggest instead is a simple code example in the class header which using try-with-resources would be more effective/helpful.

>> src/java.base/share/classes/java/util/zip/Deflater.java line 878:
>> 
>>> 876:      * If this method is invoked multiple times, the subsequent calls are treated as a no-op.
>>> 877:      * Several other methods defined by this class will throw an {@link IllegalStateException}
>>> 878:      * if invoked on a closed {@code Deflater}.
>> 
>> All of the methods which call ensureOpen should either document that an IllegalStateException may be thrown or you could add it to the header of the class.
>
> Hello Lance, you are right - I forgot to do that when I changed it to throw IllegalStateException from the previous NullPointerException. I've now updated the PR to document this on individual methods in the Inflater/Deflater which throw this exception.

Thank you.  It was an oversight that the original javadoc did not call out the NPE, but now is our chance to get it right with a more reasonable exception.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1843681091
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1843681937

From sgehwolf at openjdk.org  Fri Nov 15 12:34:56 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Fri, 15 Nov 2024 12:34:56 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302
In-Reply-To: <BpzkfnSjoHQI3Ifs7cpelQqSCzZiQXx7Om2MvGbvP1s=.53849354-cb23-4075-8e4f-14b96a55a3f6@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
 <3kPKbOzazavfIbgBj_kFY6LNl8J3_4_RcN2-mBKg_tk=.9330dfb4-6a37-4cc4-a5be-05f4cadb859c@github.com>
 <wQzuIe4HhAu9Fj4TWhwQM57Z-1FJ65UqwBoyAuJxn80=.cb4d7d0e-0a0e-4293-98e7-3d7baa7584c3@github.com>
 <BpzkfnSjoHQI3Ifs7cpelQqSCzZiQXx7Om2MvGbvP1s=.53849354-cb23-4075-8e4f-14b96a55a3f6@github.com>
Message-ID: <bfnDXfcM1j-xJbn5q8pO6lUBkl6El9yb5UACJ_7_UQ0=.5d785d7b-bb07-4b26-ab7a-4cf979279025@github.com>

On Fri, 15 Nov 2024 11:36:50 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> Regarding Xmx1500m I can try this , or I can also copy the whole test header block and use 1g for all platforms and 2g or 1500m for AIX (would be a bit code duplication of course).

If `-Xmx1500m` works for you that seems ok. `-1` on the bump only for AIX and requires. An alternative might be to use `test/jdk/tools/jlink/runtimeImage/TEST.properties` with this content:


exclusiveAccess.dirs=.


I could see why the JavaSE comparison test with packaged modules and run-time image linkage would need 2 GB, but not the others.

Both options seem preferred over the current version. It might be that a combination of `-Xmx1500m`, `exclusiveAccess.dirs=.` works. The less invasive the better.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22140#issuecomment-2478713857

From asemenyuk at openjdk.org  Fri Nov 15 13:13:47 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 13:13:47 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <thzsX-s86hfTNBny13Xv2zA2t-vms4imGVoKuf0eGrY=.63767acc-1f5d-4fc3-bec7-7bd6216cc486@github.com>

On Fri, 15 Nov 2024 09:43:15 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/WindowsHelper.java line 265:

> 263:         }
> 264: 
> 265:         String[] headers = Stream.of(output.get(1).split("\\s+", 2)).map(

Why look up the headers in the _second_ line of the output?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1843736128

From alanb at openjdk.org  Fri Nov 15 13:25:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 13:25:18 GMT
Subject: RFR: 8344300: Implement JEP 499: Structured Concurrency (Fourth
 Preview)
Message-ID: <qQ7XmfJaHZ3aFo7aH_1Hv57B_sZWWCMHO1OzsY_ry3k=.532ad467-f872-44bb-a16a-7f32bd4474d4@github.com>

No changes in this re-preview but need to bump the JEP number in the javadoc.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22148/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22148&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344300
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22148.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22148/head:pull/22148

PR: https://git.openjdk.org/jdk/pull/22148

From rgiulietti at openjdk.org  Fri Nov 15 13:25:59 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 15 Nov 2024 13:25:59 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v16]
In-Reply-To: <nY3sJr9lXOao2s22hkRnSUmDeLZtdz2JFBYyt5A3iyY=.6b20357a-4d2f-4765-b117-b08d921f6684@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <nY3sJr9lXOao2s22hkRnSUmDeLZtdz2JFBYyt5A3iyY=.6b20357a-4d2f-4765-b117-b08d921f6684@github.com>
Message-ID: <tOg4pwOWPnHvg_ulpzaY10AmbMpIfRIFEGrCLFxPBJg=.ed86fe3f-2ea1-4e37-ac26-cf1798cff2d4@github.com>

On Tue, 22 Oct 2024 14:07:30 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Code simplification

src/java.base/share/classes/java/math/BigDecimal.java line 2190:

> 2188:                     resultScale = strippedScale >> 1;
> 2189:                 } else {
> 2190:                     working = working.multiply(10L);

While this is correct, there's useless work that is being performed.

After the multiplication by 10, `working` cannot be an exact square, so this will fail later at L.2199.
I wonder if this can be simplified to avoid the `multiply()` and the following `sqrtAndRemainder()` when `strippedScale` is odd.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1843763055

From asemenyuk at openjdk.org  Fri Nov 15 13:28:43 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 13:28:43 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <njKLqhR3hSABDW2ZMVjlLNVQ3t04h7PdPH2jXc0nRCo=.64d6e018-fc9d-424e-ba24-712bf9f0e1d0@github.com>

On Fri, 15 Nov 2024 09:43:15 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 94:

> 92:     }
> 93: 
> 94:     public Executor setWinEnableUTF8(boolean value) {

This function aims to make a to-be-executed command produce output in English. To achieve this goal implementation will call `chcp 65001`. The implementation may change, but the name of the function should remain the same. That said I suggest giving it a name that reflects its purpose and not the implementation. Something like: `setWinRunWithEnglishLocale()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1843765897

From dl at openjdk.org  Fri Nov 15 13:32:47 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 15 Nov 2024 13:32:47 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
Message-ID: <e8_4YDp98Q7ckDO2ocBEB-UYXSIdNatufdlP7kcw5mg=.ed46a410-c870-42f2-a018-1ae4a34bc43a@github.com>

On Fri, 15 Nov 2024 07:36:37 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored to remove use of doPrivileged() and use of SecurityManager.
>> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
>> 
>> A careful review is requested.
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1108:
> 
>> 1106:         implements ForkJoinWorkerThreadFactory {
>> 1107:         public final ForkJoinWorkerThread newThread(ForkJoinPool pool) {
>> 1108:             return new ForkJoinWorkerThread(null, pool, true, false);
> 
> This doesn't look right. For the common pool it should return InnocuousForkJoinWorkerThread(pool).

I agree on both counts with Alan: The FJP changes are not quite right, and in any case should be postponed until after current FJP PR, and then further simplified, which would be easiest if I did this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843772670

From dl at openjdk.org  Fri Nov 15 13:44:44 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 15 Nov 2024 13:44:44 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <Mat3YDll2sngEQtQ1eJtTu2WzVKTJ3nfxS6LXrKTBnk=.a868c0a1-dc35-4dff-9193-e16c28c5af52@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <Mat3YDll2sngEQtQ1eJtTu2WzVKTJ3nfxS6LXrKTBnk=.a868c0a1-dc35-4dff-9193-e16c28c5af52@github.com>
Message-ID: <CS4Zg1UsL7GNwf_V_bdO74eXngsVxY5y395xEEjUcjY=.23090e8a-acbf-4a44-bfac-64b457a0dcd8@github.com>

On Fri, 15 Nov 2024 10:16:00 GMT, Glavo <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/Executors.java line 556:
>> 
>>> 554:      * A callable that runs under established access control settings.
>>> 555:      */
>>> 556:     private static final class PrivilegedCallable<T> implements Callable<T> {
>> 
>> I can't help thinking some larger cleanup or renaming will be needed here as PrivilegedXXX is misleading now.
>
> This class is currently meaningless, perhaps it should be carefully removed and the documentation for `priviledgedCallable` should be updated.

Deleting it would also mean removing or modifying a bunch of j.u./tck tests. Perhaps deprecation is enough.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1843788836

From duke at openjdk.org  Fri Nov 15 14:07:50 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 15 Nov 2024 14:07:50 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v16]
In-Reply-To: <tOg4pwOWPnHvg_ulpzaY10AmbMpIfRIFEGrCLFxPBJg=.ed86fe3f-2ea1-4e37-ac26-cf1798cff2d4@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <nY3sJr9lXOao2s22hkRnSUmDeLZtdz2JFBYyt5A3iyY=.6b20357a-4d2f-4765-b117-b08d921f6684@github.com>
 <tOg4pwOWPnHvg_ulpzaY10AmbMpIfRIFEGrCLFxPBJg=.ed86fe3f-2ea1-4e37-ac26-cf1798cff2d4@github.com>
Message-ID: <AWG1FgHZO02ucnsCe_TSFUuWPsoWqcELvPBHCCSZgvQ=.9085c8f4-7e71-4646-93c3-491e5be8e1f8@github.com>

On Fri, 15 Nov 2024 13:22:32 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Code simplification
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2190:
> 
>> 2188:                     resultScale = strippedScale >> 1;
>> 2189:                 } else {
>> 2190:                     working = working.multiply(10L);
> 
> While this is correct, there's useless work that is being performed.
> 
> After the multiplication by 10, `working` cannot be an exact square, so this will fail later at L.2199.
> I wonder if this can be simplified to avoid the `multiply()` and the following `sqrtAndRemainder()` when `strippedScale` is odd.

I'm changing the code to take into account this fact.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1843855833

From vklang at openjdk.org  Fri Nov 15 14:09:59 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Fri, 15 Nov 2024 14:09:59 GMT
Subject: RFR: 8344300: Implement JEP 499: Structured Concurrency (Fourth
 Preview)
In-Reply-To: <qQ7XmfJaHZ3aFo7aH_1Hv57B_sZWWCMHO1OzsY_ry3k=.532ad467-f872-44bb-a16a-7f32bd4474d4@github.com>
References: <qQ7XmfJaHZ3aFo7aH_1Hv57B_sZWWCMHO1OzsY_ry3k=.532ad467-f872-44bb-a16a-7f32bd4474d4@github.com>
Message-ID: <l8utnKVZlcKHNmNxRBN8o5R1_xQ1ksI5T2UOVrUBMSo=.c6d28ec6-acc1-4c9d-b479-39a17294aaab@github.com>

On Fri, 15 Nov 2024 12:42:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> No changes in this re-preview but need to bump the JEP number in the javadoc.

lgtm, Alan

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22148#pullrequestreview-2438698258

From liach at openjdk.org  Fri Nov 15 14:15:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 14:15:00 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <h6Bz3U_UMvkR7g_VmPsKjeoGLFotX4bOVZ2fvMtLbkE=.5706e9c7-d8ae-41fa-a5b1-f01a0bdd28d3@github.com>

On Fri, 15 Nov 2024 11:53:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynami...

It's finally the time to set sail!

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/19826#pullrequestreview-2438721981

From duke at openjdk.org  Fri Nov 15 14:21:21 2024
From: duke at openjdk.org (fabioromano1)
Date: Fri, 15 Nov 2024 14:21:21 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v17]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <KW-U-91MyntIMaUwjtxY0h21c3ZiDU0MvBZHGHplZe0=.65fcb40d-7f42-4278-acfa-a84377c81757@github.com>

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
> 
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
> 
> x = y * 10 ^ exp
> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
> 
> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
> 
> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimize sqrt branch for exact results

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/a4e85944..2ca5eac9

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=15-16

  Stats: 17 lines in 1 file changed: 3 ins; 10 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21301/head:pull/21301

PR: https://git.openjdk.org/jdk/pull/21301

From asemenyuk at openjdk.org  Fri Nov 15 14:22:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 14:22:59 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <njfua6SCISo_zOh2ygIMfEqU5oe77IpZOl8PqFsns74=.8e7959a5-176e-4002-9134-59b530038d60@github.com>

On Fri, 15 Nov 2024 09:43:15 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 344:

> 342:             command.add("cmd.exe");
> 343:             command.add("/c");
> 344:             command.add("chcp 65001 && " + printCommandLine(executablePath().toString(), args));

`printCommandLine()` function does a lousy job of escaping whitespaces in arguments. Its output is for logging purposes only. 

I experimented with the use of "chcp" in the "Executor" class and figured that it is not necessary to put the entire command line in a single argument. Please take a look at https://github.com/openjdk/jdk/commit/7975a8e97485b999691b986a78b1e0b47a9b30a1. It suppresses the output of "chcp" command, so client code may remain unchanged. Need to add the missing `setWinEnableUTF8()` and good to go.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22142#pullrequestreview-2438749546
PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1843902329

From asemenyuk at openjdk.org  Fri Nov 15 14:26:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 14:26:59 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <k8TFFj9L-4jrs5MdbLc2qmNqDqxWDlkvorKg8VIcXc4=.c2973a8d-0171-460c-b87e-b49957cde562@github.com>

On Fri, 15 Nov 2024 09:43:15 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

I'm not sure "65001" is the right choice if the request is to get the output in English. Would "437" or "850" be more appropriate arguments for the "chcp" command?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22142#issuecomment-2479008183

From asotona at openjdk.org  Fri Nov 15 14:37:52 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 14:37:52 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <UGrZ0I-Ehrm3LW1N7wtCZk6BD_pSZgSIyqC68uksZ4Q=.d55aada7-d6e9-425a-98bf-04a2088a1639@github.com>

On Fri, 15 Nov 2024 11:53:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynami...

Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19826#issuecomment-2479030204

From asemenyuk at openjdk.org  Fri Nov 15 14:40:45 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 14:40:45 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib
In-Reply-To: <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
 <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>
Message-ID: <eQ4utSVBYM8SuGf7OWsoUSoJzhMhgkGa_0waJOFzOgo=.cf59a1f1-60c5-43c9-afc9-93e99874c65e@github.com>

On Fri, 15 Nov 2024 00:02:29 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Make jpackage test lib more practical. List of changes:
>> 
>> Support multiple args and var args in `@Parameter` annotation:
>> 
>> @Test
>> @Parameter({"12", "foo"})
>> @Parameter({"-89", "bar", "more"})
>> @Parameter({"-89", "bar", "more", "moore"})
>> public void testVarArg(int a, String b, String ... other) {}
>> 
>> 
>> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
>> 
>> class FooTest {
>>     public FooTest(String... args) {}
>>     public FooTest(int o) {}
>>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
>> 
>>     @Parameters
>>     public static Collection<Object[]> input() {
>>         return List.of(new Object[][] {
>>             {},
>>             {"str"},
>>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>>         });
>>     }
>> 
>>     @Parameters
>>     public static Collection<Object[]> input2() {
>>         return List.of(new Object[][] {
>>             {78},
>>             {34, null, null},
>>         });
>>     }
>> }
>> 
>> 
>> Static test method will be executed only once and not as many times as the number of the test class instances.
>> 
>> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
>> 
>> 
>> class FooTest {
>>     @Test
>>     @ParameterSupplier("dateSupplier")
>>     @ParameterSupplier("AnotherClass.dateSupplier")
>>     public void testDates(LocalDate v) {}
>> 
>>     public static Collection<Object[]> dateSupplier() {
>>         return List.of(new Object[][] {
>>             { LocalDate.parse("2018-05-05") },
>>             { LocalDate.parse("2018-07-11") },
>>         });
>>     }
>> }
>> 
>> class AnotherClass {
>>     public static Collection<Object[]> dateSupplier() {
>>         return List.of(new Object[][] {
>>             { LocalDate.parse("2028-07-11") },
>>         });
>>     }
>> }
>> 
>> 
>> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
>> 
>> 
>> @Test(ifOS = OperatingSystem.LINUX)
>> public void testRunIfLinux() {}
>> 
>> @Test(ifNotOS = OperatingSystem.LINUX)
>> public void testRunIfNotLinux() {}
>> 
>> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
>> public void testRunIfNotLinuxOrMacOS() {}
>> 
>> @Test
>> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
>> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LI...
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/LinuxHelper.java line 441:
> 
>> 439:         }
>> 440: 
>> 441:         // Verify the value of `Exec` key in is escaped if required
> 
> This comment is confusing. Did you mean "Verify that the value of `Exec` key is escaped"?

It was extra "in". I meant "Verify the value of `Exec` key is escaped if required"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843925654

From asotona at openjdk.org  Fri Nov 15 14:41:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 14:41:01 GMT
Subject: Integrated: 8334714: Implement JEP 484: Class-File API
In-Reply-To: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
Message-ID: <r4ddLbwDLxL-HBYxfRKEh8QLiIkWF9NGvxOGeUbvW2k=.52ab53e6-3c93-4e31-aae0-456e35b691a2@github.com>

On Fri, 21 Jun 2024 11:56:37 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> Class-File API is leaving preview.
> This is a removal of all `@PreviewFeature` annotations from Class-File API.
> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
> 
> Please review.
> 
> Thanks,
> Adam

This pull request has now been integrated.

Changeset: 84ffb64c
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/84ffb64cd73f8af11cf3670c6f19d282c2ac6961
Stats:     799 lines in 165 files changed: 0 ins; 487 del; 312 mod

8334714: Implement JEP 484: Class-File API

Reviewed-by: liach, vromero

-------------

PR: https://git.openjdk.org/jdk/pull/19826

From ihse at openjdk.org  Fri Nov 15 14:46:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:46:33 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v3]
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix regexes in CheckManPageOptions

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22081/files
  - new: https://git.openjdk.org/jdk/pull/22081/files/a8d4ea50..dbef493e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=01-02

  Stats: 12 lines in 1 file changed: 3 ins; 0 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081

PR: https://git.openjdk.org/jdk/pull/22081

From ihse at openjdk.org  Fri Nov 15 14:46:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:46:34 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
Message-ID: <OnOhR_4neUIpLLJXyytczQFw_jwjywxQ-o7XAvWVjF4=.971a3357-fa72-4c7c-9025-f295e252dc9f@github.com>

On Thu, 14 Nov 2024 11:11:54 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Fix CheckManPageOptions test
>  - Remove classpath exception

The CheckManPageOptions test had regexps that were not up to date with the latest changes in the markdown file. I fixed those and now the test passes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479038178

From ihse at openjdk.org  Fri Nov 15 14:46:34 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:46:34 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v2]
In-Reply-To: <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <XPX7mNek8KcN7ri7h8gqRZFBeKjSmu_XiHuvE-cR0Ws=.7292fd84-de4b-4163-8cf3-93838a32f1c4@github.com>
 <3zUMDU3HQSNpvZPbBDrPN7p_6TIubczvegxSSU50S2o=.cf9f50f1-d605-46ea-9780-de3f9cf04a94@github.com>
Message-ID: <H49OafS1oIU1W-O1uMBrGYPeARoh_4nPqPp0cyzjt_k=.fd859280-4110-441d-9ddc-e7e08bb909c9@github.com>

On Fri, 15 Nov 2024 01:25:43 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Fix CheckManPageOptions test
>>  - Remove classpath exception
>
>> > Now `CheckManPageOptions` finds the `.md` file (good) and its checks fail (bad).
>> 
>> _sigh_
>> 
>> > A candidate for an ignore list as fixing it is out of scope of this PR?
>> 
>> Let me have a look at it first. It seems the test has the indention to handle markdown files, so maybe there is an easy fix.
> 
> I'm somewhat surprised that the full src tree is available to this test when it runs. I was expecting it to examine the .1 files in the JDK image.

@dholmes-ora 

>  I was expecting it to examine the .1 files in the JDK image.

It's been like that since the test was created in https://bugs.openjdk.org/browse/JDK-8274211, so there is no change in this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2479042569

From ihse at openjdk.org  Fri Nov 15 14:50:21 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 14:50:21 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  It's somewhat nicer to use \\s instead of space character in regex

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22081/files
  - new: https://git.openjdk.org/jdk/pull/22081/files/dbef493e..7cba61b5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22081&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22081.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22081/head:pull/22081

PR: https://git.openjdk.org/jdk/pull/22081

From asemenyuk at openjdk.org  Fri Nov 15 15:01:20 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 15:01:20 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v2]
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <DCCP4AZaMwGUYfgtRDYLOmE7LVnwDKxCplcKEU-BU6c=.420097be-b14c-4c83-8184-7ec5104dedab@github.com>

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Fix finding in the review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21996/files
  - new: https://git.openjdk.org/jdk/pull/21996/files/1c7e0592..66c1583a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=00-01

  Stats: 6 lines in 4 files changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21996/head:pull/21996

PR: https://git.openjdk.org/jdk/pull/21996

From asemenyuk at openjdk.org  Fri Nov 15 15:01:20 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 15:01:20 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <P-o9ITOEkE6OZLsUP7Waj8sAzKyOQsyT0kzIAgVw1O4=.f2af45b2-ca60-437c-ada0-9787cc0c38a9@github.com>

On Sat, 9 Nov 2024 00:51:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

I agree this PR can be split into pieces as you suggest. Will work on that

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21996#issuecomment-2479076245

From asemenyuk at openjdk.org  Fri Nov 15 15:01:21 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 15:01:21 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v2]
In-Reply-To: <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
 <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>
Message-ID: <CxPOY5_P4aB0Q3XudbaOqo3t--4t9XKs4T-bTJULWIg=.93c7f356-56ff-4f62-81e5-006d372302b5@github.com>

On Fri, 15 Nov 2024 01:12:00 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

> Maybe move this code into switch statement under default?

Can't use "null" in the switch.

> should we use TypeStatus.UNKNOWN instead of null?

To deal with `TypeStatus.UNKNOWN` and `null`? Besides of that what is the semantics of `TypeStatus.UNKNOWN`? 

- `TypeStatus.NOT_TEST_CLASS` is for types that are NOT test classes.
- `TypeStatus.VALID_TEST_CLASS` is for types that are valid test classes.
- `TypeStatus.TEST_CLASS` is for all other types, i.e. invalid test classes.

How does `TypeStatus.UNKNOWN` fit?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843949327

From cstein at openjdk.org  Fri Nov 15 15:04:51 2024
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 15 Nov 2024 15:04:51 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v3]
In-Reply-To: <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>
Message-ID: <Hc2bnxpU3L_6aq6ywU83kGh6MnUKh7XftL5OuwKErGg=.4c54e3d8-2169-4d25-bfa9-9d2b957e6981@github.com>

On Fri, 15 Nov 2024 14:46:33 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix regexes in CheckManPageOptions

test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277:

> 275: 
> 276:         // In the defining areas, option names are represented as follows:
> 277:         //      `OPTION` or `OPTION`

`OPTION` or `OPTION` ... where's the difference?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843959156

From liach at openjdk.org  Fri Nov 15 15:06:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 15:06:00 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util
In-Reply-To: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
Message-ID: <xQD9GiWFHOESDHK2FaiSPylfvlXBWLTqTHtPWXZL3OM=.82a9ed52-c157-4ab4-a6bf-edb17c62465a@github.com>

On Fri, 15 Nov 2024 09:35:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
> 
> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
> 
> Verification: GHA results pending.

A few remarks; look fine otherwise.  Pinging @rgiulietti to review the random generator changes.

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 129:

> 127:     }
> 128: 
> 129:     @SuppressWarnings("removal")

Please remove this redundant suppression.

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 148:

> 146:      * Validate if the given dir is a writeable directory if exists.
> 147:      */
> 148:     @SuppressWarnings("removal")

Same redundant suppression.

-------------

Changes requested by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22141#pullrequestreview-2438841002
PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1843959825
PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1843960575

From liach at openjdk.org  Fri Nov 15 15:08:59 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 15:08:59 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
Message-ID: <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>

On Fri, 15 Nov 2024 11:53:00 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Class-File API is leaving preview.
>> This is a removal of all `@PreviewFeature` annotations from Class-File API.
>> It also bumps all `@since` tags and removes `jdk.internal.javac.PreviewFeature.Feature.CLASSFILE_API`.
>> 
>> Please review.
>> 
>> Thanks,
>> Adam
>
> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
> 
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>    
>    # Conflicts:
>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>    #	src/java.base/share/classes/java/lang/classfile/constantpool/ConstantDynami...

src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 78:

> 76:         STRUCTURED_CONCURRENCY,
> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
> 78:         CLASSFILE_API,

Just remembered that we have to keep this until JDK 24 is the minimum boot JDK; with this removed bootcycle build should fail.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1843965756

From asemenyuk at openjdk.org  Fri Nov 15 15:10:12 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 15:10:12 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v3]
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <kjXHgN-OkFWuI92n-aqYEA-L5zkYrBKGp6LuSDfJIlU=.fc5ffec2-3cc5-420e-bd1b-a468933d2d82@github.com>

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant "method.setAccessible(true);" calls

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21996/files
  - new: https://git.openjdk.org/jdk/pull/21996/files/66c1583a..ba89798a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/21996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21996/head:pull/21996

PR: https://git.openjdk.org/jdk/pull/21996

From asemenyuk at openjdk.org  Fri Nov 15 15:10:12 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 15:10:12 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v3]
In-Reply-To: <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
 <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>
Message-ID: <hCBlybuJY3FAdUnF_9Zkx4vFBycUEc3VcTcFNaGfqYc=.7357dde1-4188-4fc3-af67-b2086edd9e25@github.com>

On Fri, 15 Nov 2024 01:20:34 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant "method.setAccessible(true);" calls
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestMethodSupplier.java line 433:
> 
>> 431:                     withTestAnnotations = true;
>> 432:                 }
>> 433:                 verifyAnnotationsCorrect(method);
> 
> This code blocks looks confusing. Why we need `method.setAccessible(true)` for all methods? Also, `if` statement looks confusing with empty `if (withTestAnnotations).`

Good point about `method.setAccessible(true)`!
Looks like it is needed when `Method::invoke()` is used, but not when querying annotations. Removed redundant `method.setAccessible(true)` calls.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1843967405

From ihse at openjdk.org  Fri Nov 15 15:11:46 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 15:11:46 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v3]
In-Reply-To: <Hc2bnxpU3L_6aq6ywU83kGh6MnUKh7XftL5OuwKErGg=.4c54e3d8-2169-4d25-bfa9-9d2b957e6981@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <B2bFkUUIkxApuvoU42qg-A_wv_J1b5lxSNPzbILjWPs=.2f6d2d4f-4268-4cc8-8981-6e8e8736a757@github.com>
 <Hc2bnxpU3L_6aq6ywU83kGh6MnUKh7XftL5OuwKErGg=.4c54e3d8-2169-4d25-bfa9-9d2b957e6981@github.com>
Message-ID: <_OybV6gt9rVOlg2n8GG48jDzgFsqLQ6GLi4R5TvZWTI=.b1f68ebb-dcd5-4fe1-b001-21628221d218@github.com>

On Fri, 15 Nov 2024 15:00:39 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix regexes in CheckManPageOptions
>
> test/langtools/jdk/javadoc/tool/CheckManPageOptions.java line 277:
> 
>> 275: 
>> 276:         // In the defining areas, option names are represented as follows:
>> 277:         //      `OPTION` or `OPTION`
> 
> `OPTION` or `OPTION` ... where's the difference?

Some options have multiple variants displayed on a single row, like:

 `--classpath` or `-cp`



This was handled in the troff format but not updated for markdown.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22081#discussion_r1843969778

From asotona at openjdk.org  Fri Nov 15 15:36:54 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 15:36:54 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
 <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>
Message-ID: <bMakln9SE0MJ_dosAb_xOyo6dpja3iL0GOk6GsBEaYY=.901bfa89-38e2-42df-8891-7d3db507f996@github.com>

On Fri, 15 Nov 2024 15:05:41 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Adam Sotona has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:
>> 
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/classfile/CustomAttribute.java
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java
>>  - Merge remote-tracking branch 'openjdk/master' into JDK-8334714-final
>>    
>>    # Conflicts:
>>    #	src/java.base/share/classes/java/lang/classfile/AccessFlags.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassFileTransform.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassHierarchyResolver.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassModel.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassReader.java
>>    #	src/java.base/share/classes/java/lang/classfile/ClassSignature.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/CodeModel.java
>>    #	src/java.base/share/classes/java/lang/classfile/CompoundElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/FieldBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/FieldElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/Instruction.java
>>    #	src/java.base/share/classes/java/lang/classfile/MethodBuilder.java
>>    #	src/java.base/share/classes/java/lang/classfile/MethodElement.java
>>    #	src/java.base/share/classes/java/lang/classfile/TypeKind.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTableAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/LocalVariableTypeTableAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeInvisibleAnnotationsAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/attribute/RuntimeVisibleAnnotationsAttribute.java
>>    #	src/java.base/share/classes/java/lang/classfile/constantpool/AnnotationConstantValueEntry.java
>>    #...
>
> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 78:
> 
>> 76:         STRUCTURED_CONCURRENCY,
>> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
>> 78:         CLASSFILE_API,
> 
> Just remembered that we have to keep this until JDK 24 is the minimum boot JDK; with this removed bootcycle build should fail.

Oops.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1844042001

From ihse at openjdk.org  Fri Nov 15 15:37:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Fri, 15 Nov 2024 15:37:01 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v11]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <hhZRuyYgDNzvRrtk3ZWCpy9ke4VzBp5aAq_yAYVgsYA=.0f0c322c-baf6-43df-bfe6-db98344b99c1@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 12 commits:

 - Merge branch 'master' into static-jdk-image
 - Merge branch 'master' into static-jdk-image
 - Merge branch 'master' into static-jdk-image
 - Fix bug in filtering out -Wl,--exclude-libs,ALL
 - Don't hardcode server variant
 - Setup LDFLAGS_STATIC_JDK
 - Update GetJREPath comment and remove unnecessary JLI_IsStaticallyLinked check
 - Add lookup asserts
 - Remove superfluous SRC.
 - Merge branch 'master' into static-jdk-image
 - ... and 2 more: https://git.openjdk.org/jdk/compare/40a055eb...0e5ff083

-------------

Changes: https://git.openjdk.org/jdk/pull/20837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=10
  Stats: 446 lines in 26 files changed: 367 ins; 5 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From eirbjo at openjdk.org  Fri Nov 15 15:43:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 15:43:08 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
Message-ID: <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>

> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
> 
> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
> 
> Verification: GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove redundant suppression

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22141/files
  - new: https://git.openjdk.org/jdk/pull/22141/files/09c7c2e3..64a9ec15

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22141&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22141&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22141.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22141/head:pull/22141

PR: https://git.openjdk.org/jdk/pull/22141

From eirbjo at openjdk.org  Fri Nov 15 15:43:08 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 15:43:08 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <xQD9GiWFHOESDHK2FaiSPylfvlXBWLTqTHtPWXZL3OM=.82a9ed52-c157-4ab4-a6bf-edb17c62465a@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <xQD9GiWFHOESDHK2FaiSPylfvlXBWLTqTHtPWXZL3OM=.82a9ed52-c157-4ab4-a6bf-edb17c62465a@github.com>
Message-ID: <3kHEHtehW0Nm9uNyetuigNcpT4-JZIJXRIO2yJx00JU=.3af0389d-ee0f-44cd-94c0-e61204f5431e@github.com>

On Fri, 15 Nov 2024 15:01:13 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant suppression
>
> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 129:
> 
>> 127:     }
>> 128: 
>> 129:     @SuppressWarnings("removal")
> 
> Please remove this redundant suppression.

Thanks, both fixed. IntelliJ IDEA keeps hiding these annotations, making them hard to spot.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844066002

From asotona at openjdk.org  Fri Nov 15 15:47:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 15:47:01 GMT
Subject: RFR: 8334714: Implement JEP 484: Class-File API [v9]
In-Reply-To: <bMakln9SE0MJ_dosAb_xOyo6dpja3iL0GOk6GsBEaYY=.901bfa89-38e2-42df-8891-7d3db507f996@github.com>
References: <WjrFv-PN6YYwlFr9EKeRE__Pi_xXPWvdrFAr4P81Xjw=.14b9228b-8fb5-4bf9-9731-88f156500318@github.com>
 <PUmvQlIaN1bcD5lL7tN_0uyVZ-sbqacLGeOXrtfcliQ=.a87a5cfd-ba34-4464-b49b-c6bc975756b6@github.com>
 <NpDL-5218rUy1saVlyl3M_VUpQ4_1Kr8DbRuFahM4WY=.382a1621-3b32-4dca-8097-297cbb29bd7e@github.com>
 <bMakln9SE0MJ_dosAb_xOyo6dpja3iL0GOk6GsBEaYY=.901bfa89-38e2-42df-8891-7d3db507f996@github.com>
Message-ID: <JfMUPY10zx_WMCo_PLFK-D-j0_NckrT5BYnbyzyJMkI=.7f083027-742f-4cfa-916e-83997520dd16@github.com>

On Fri, 15 Nov 2024 15:33:35 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/javac/PreviewFeature.java line 78:
>> 
>>> 76:         STRUCTURED_CONCURRENCY,
>>> 77:         @JEP(number=466, title="ClassFile API", status="Second Preview")
>>> 78:         CLASSFILE_API,
>> 
>> Just remembered that we have to keep this until JDK 24 is the minimum boot JDK; with this removed bootcycle build should fail.
>
> Oops.

https://github.com/openjdk/jdk/pull/22150

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19826#discussion_r1844076730

From asotona at openjdk.org  Fri Nov 15 15:47:03 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 15:47:03 GMT
Subject: RFR: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
Message-ID: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>

jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.

Please review.

Thank you,
Adam

-------------

Commit messages:
 - 8344314: Revert removal of jdk.internal.java.PreviewFeature.CLASSFILE_API

Changes: https://git.openjdk.org/jdk/pull/22150/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22150&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344314
  Stats: 1 line in 1 file changed: 1 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22150.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22150/head:pull/22150

PR: https://git.openjdk.org/jdk/pull/22150

From rriggs at openjdk.org  Fri Nov 15 15:50:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 15:50:56 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
Message-ID: <vjh90OP0en34HdZug3mchir81g_dJ6KLLK3loCafgUQ=.cb302f30-52a6-450e-8f5b-8dcb0f3e8db7@github.com>

On Fri, 15 Nov 2024 07:23:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Refactored to remove use of doPrivileged() and use of SecurityManager.
>> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
>> 
>> A careful review is requested.
>
> src/java.base/share/classes/java/util/concurrent/CopyOnWriteArrayList.java line 2104:
> 
>> 2102:             lockField.set(this, new Object());
>> 2103:         } catch (IllegalAccessException | NoSuchFieldException e) {
>> 2104:                 throw new RuntimeException(e);
> 
> Did you mean to change this from Error to RuntimeException? It shouldn't happen of course, but probably best not to change this.

Revert

> src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 244:
> 
>> 242:         @Override // paranoically
>> 243:         public void setContextClassLoader(ClassLoader cl) {
>> 244:             // No-op, do not change the context class loader
> 
> I don't think this we should change this in this PR. Instead, I think we need to decide what to specify.

reverted

> src/java.base/share/classes/java/util/concurrent/StructuredTaskScope.java line 700:
> 
>> 698: 
>> 699:     private void interruptAll() {
>> 700:             implInterruptAll();
> 
> Rename implInterruptAll to InterruptAll and remove implInterruptAll.

will do

> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 399:
> 
>> 397:                 if ((ccl != null) && (ccl != cl) &&
>> 398:                     ((cl == null) || !isAncestor(cl, ccl))) {
>> 399:                     sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass);
> 
> The ensureMemberAccess needs to stay but the checkPackageAccess can be removed.
> 
> @seanjmullan I think you'll want to study this one closely.

ok, removing package access check

> src/java.base/share/classes/java/util/concurrent/atomic/Striped64.java line 385:
> 
>> 383:         try {
>> 384:             MethodHandles.Lookup l2 =
>> 385:                  MethodHandles.privateLookupIn(Thread.class, MethodHandles.lookup());
> 
> I assume this can be changed to ` MethodHandles.Lookup l2 = MethodHandles.privateLookupIn(Thread.class, l1);`

ok

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844084122
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844084647
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844084807
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844085416
PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844085740

From rriggs at openjdk.org  Fri Nov 15 15:50:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 15:50:57 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <CS4Zg1UsL7GNwf_V_bdO74eXngsVxY5y395xEEjUcjY=.23090e8a-acbf-4a44-bfac-64b457a0dcd8@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <Mat3YDll2sngEQtQ1eJtTu2WzVKTJ3nfxS6LXrKTBnk=.a868c0a1-dc35-4dff-9193-e16c28c5af52@github.com>
 <CS4Zg1UsL7GNwf_V_bdO74eXngsVxY5y395xEEjUcjY=.23090e8a-acbf-4a44-bfac-64b457a0dcd8@github.com>
Message-ID: <AF4yVvpybOrVVtigWxPe_JDhW7bQKr8CVlVL23JVRR0=.7840a352-bd12-40ed-877e-fb0104bd4c1b@github.com>

On Fri, 15 Nov 2024 13:41:09 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This class is currently meaningless, perhaps it should be carefully removed and the documentation for `priviledgedCallable` should be updated.
>
> Deleting it would also mean removing or modifying a bunch of j.u./tck tests. Perhaps deprecation is enough.

ok, for future cleanup

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844084387

From rriggs at openjdk.org  Fri Nov 15 15:50:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 15:50:57 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <e8_4YDp98Q7ckDO2ocBEB-UYXSIdNatufdlP7kcw5mg=.ed46a410-c870-42f2-a018-1ae4a34bc43a@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <e8_4YDp98Q7ckDO2ocBEB-UYXSIdNatufdlP7kcw5mg=.ed46a410-c870-42f2-a018-1ae4a34bc43a@github.com>
Message-ID: <pBIMYvkQd5JUR1nVXGlSjFRp_EYpZyii-HSYHmff_8Y=.0ad9aa4c-05e8-4232-a72a-8f7a3a94a1f0@github.com>

On Fri, 15 Nov 2024 13:30:34 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1108:
>> 
>>> 1106:         implements ForkJoinWorkerThreadFactory {
>>> 1107:         public final ForkJoinWorkerThread newThread(ForkJoinPool pool) {
>>> 1108:             return new ForkJoinWorkerThread(null, pool, true, false);
>> 
>> This doesn't look right. For the common pool it should return InnocuousForkJoinWorkerThread(pool).
>
> I agree on both counts with Alan: The FJP changes are not quite right, and in any case should be postponed until after current FJP PR, and then further simplified, which would be easiest if I did this.

Revert all changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844086214

From asemenyuk at openjdk.org  Fri Nov 15 15:58:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 15:58:03 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v4]
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <Kv-qSDaE-d_tyaaS6gGGQFr10BS0eWLOsm3yQ0HZw5g=.06724b1c-dd5b-44f8-9630-f87badd98107@github.com>

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Remove changes unrelated to the new annotations from the PR

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21996/files
  - new: https://git.openjdk.org/jdk/pull/21996/files/ba89798a..2b746d49

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=02-03

  Stats: 199 lines in 4 files changed: 13 ins; 165 del; 21 mod
  Patch: https://git.openjdk.org/jdk/pull/21996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21996/head:pull/21996

PR: https://git.openjdk.org/jdk/pull/21996

From rriggs at openjdk.org  Fri Nov 15 15:59:32 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 15:59:32 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v2]
In-Reply-To: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
Message-ID: <hucppcuKLRrxLxrOKSV5y2fjunLFKthoSyfP8bpCAYE=.033a56fa-0d6e-41f3-9292-2638cb44c8c3@github.com>

> Refactored to remove use of doPrivileged() and use of SecurityManager.
> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
> 
> A careful review is requested.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Revert all changes to ForkJoinPool; defer remove of SM use
  Addressed other review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22119/files
  - new: https://git.openjdk.org/jdk/pull/22119/files/cd90f45f..21013c28

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22119&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22119&range=00-01

  Stats: 124 lines in 6 files changed: 103 ins; 11 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/22119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22119/head:pull/22119

PR: https://git.openjdk.org/jdk/pull/22119

From rriggs at openjdk.org  Fri Nov 15 15:59:32 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 15:59:32 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v2]
In-Reply-To: <e8_4YDp98Q7ckDO2ocBEB-UYXSIdNatufdlP7kcw5mg=.ed46a410-c870-42f2-a018-1ae4a34bc43a@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <e8_4YDp98Q7ckDO2ocBEB-UYXSIdNatufdlP7kcw5mg=.ed46a410-c870-42f2-a018-1ae4a34bc43a@github.com>
Message-ID: <CxOMq9QyL_NBtXPwSurpRZXo0JK0p_YBIk_sy_1-IZ4=.5aa2d927-2335-49c0-be6f-7f5b32dea81c@github.com>

On Fri, 15 Nov 2024 13:30:34 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 1108:
>> 
>>> 1106:         implements ForkJoinWorkerThreadFactory {
>>> 1107:         public final ForkJoinWorkerThread newThread(ForkJoinPool pool) {
>>> 1108:             return new ForkJoinWorkerThread(null, pool, true, false);
>> 
>> This doesn't look right. For the common pool it should return InnocuousForkJoinWorkerThread(pool).
>
> I agree on both counts with Alan: The FJP changes are not quite right, and in any case should be postponed until after current FJP PR, and then further simplified, which would be easiest if I did this.

@DougLea If you prefer, I can leave any/all changes to you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844096923

From asotona at openjdk.org  Fri Nov 15 16:01:00 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 16:01:00 GMT
Subject: RFR: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
In-Reply-To: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
References: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
Message-ID: <UnlOk1Jo1IxCy1J3E0rN4NN-XxlHcDzDKHMTBvKbcKU=.b068c434-262b-4091-833b-751dfa07c133@github.com>

On Fri, 15 Nov 2024 15:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.
> 
> Please review.
> 
> Thank you,
> Adam

I missed it too.
Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22150#issuecomment-2479295705

From asotona at openjdk.org  Fri Nov 15 16:01:01 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Fri, 15 Nov 2024 16:01:01 GMT
Subject: Integrated: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
In-Reply-To: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
References: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
Message-ID: <RJHkBAZPHGL5f8VapRKfqgaNdrD2wFHcv9jJRRTH7oc=.bee7876c-3665-4daa-a306-b18f5e771be1@github.com>

On Fri, 15 Nov 2024 15:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.
> 
> Please review.
> 
> Thank you,
> Adam

This pull request has now been integrated.

Changeset: 3c38ed41
Author:    Adam Sotona <asotona at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/3c38ed4128f8762d04ae093d7e8f015bfd4fc2da
Stats:     1 line in 1 file changed: 1 ins; 0 del; 0 mod

8344314: Revert removal of jdk.internal.java.PreviewFeature.CLASSFILE_API

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/22150

From liach at openjdk.org  Fri Nov 15 16:01:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 16:01:00 GMT
Subject: RFR: 8344314: Revert removal of
 jdk.internal.java.PreviewFeature.CLASSFILE_API
In-Reply-To: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
References: <qZe4Ybpwlx_WrSVsGfBVUod_gBZ3eydGNU7AQldGErc=.f5c36f20-5145-4a27-a327-37765d6bc2af@github.com>
Message-ID: <3StDzbrqAmKQ4bhWJ_dbb7V4-TLUl4gCRUd3fjJcd1g=.dab69d38-73f4-490f-a589-6d26124c4a3c@github.com>

On Fri, 15 Nov 2024 15:42:29 GMT, Adam Sotona <asotona at openjdk.org> wrote:

> jdk.internal.java.PreviewFeature.CLASSFILE_API has been accidentally removed with JDK-8334714, however it should remain until used in bootstrap build.
> 
> Please review.
> 
> Thank you,
> Adam

Sorry for forgetting to leave that review earlier.  Viktor told me but I forgot to leave the remark on the PR review.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22150#pullrequestreview-2439021986

From iklam at openjdk.org  Fri Nov 15 16:02:46 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 15 Nov 2024 16:02:46 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v13]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <UXGlXYKmEDYo97no_ftYrCUjt9TB0oaTEMyMa6zUp8A=.22c7df53-db50-4f26-956c-7d5b4dee3601@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 181 commits:

 - Merge branch 'master' into jep-483-candidate
 - fixed typo in make/RunTests.gmk comments
 - Merge branch 'master' into jep-483-candidate
 - Merge branch 'master' into jep-483-candidate
 - fixed merge with UseCompactObjectHeaders
 -  Merge branch 'master' into jep-483-candidate
 - fixed merge
 - Merge branch 'master' of https://github.com/openjdk/jdk into merge-mainline
 - @DanHeidinga comment -- exit VM when runtimeSetup() fails
 - fixed merge
 - ... and 171 more: https://git.openjdk.org/jdk/compare/40a055eb...b317b4b5

-------------

Changes: https://git.openjdk.org/jdk/pull/21642/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=12
  Stats: 7192 lines in 107 files changed: 6358 ins; 513 del; 321 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From rriggs at openjdk.org  Fri Nov 15 16:03:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 16:03:09 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
Message-ID: <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>

On Fri, 15 Nov 2024 15:43:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
>> 
>> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
>> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
>> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
>> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
>> 
>> Verification: GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant suppression

LGTM

src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 82:

> 80: 
> 81:     private ClassFileDumper(String key, String path) {
> 82:         /*

The comment might still be relevant if changed to System.getProperty.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22141#pullrequestreview-2439033301
PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844099955

From cstein at openjdk.org  Fri Nov 15 16:04:19 2024
From: cstein at openjdk.org (Christian Stein)
Date: Fri, 15 Nov 2024 16:04:19 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
Message-ID: <h-yi4F3ylqaiXJhUvdkQYwbgW7lbhzlFqCpNo_y5pDg=.cd652669-b8ac-4c35-9d02-1a6ec551df87@github.com>

On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It's somewhat nicer to use \\s instead of space character in regex

Marked as reviewed by cstein (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2439039366

From rriggs at openjdk.org  Fri Nov 15 16:06:41 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 16:06:41 GMT
Subject: RFR: 8344252: SM cleanup in java.util classes [v2]
In-Reply-To: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
References: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
Message-ID: <cj90fQBlZT8HZwgJIz6dRtGg6HhTrrzYbCLPySTeSWo=.b6e32d55-6676-4d68-a307-88157955e734@github.com>

> Remove use of doPrivileged and SecurityManager in java.util.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Applied suggestions from review comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22122/files
  - new: https://git.openjdk.org/jdk/pull/22122/files/9021ee53..f8e518f7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22122&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22122&range=00-01

  Stats: 3 lines in 3 files changed: 0 ins; 1 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22122/head:pull/22122

PR: https://git.openjdk.org/jdk/pull/22122

From bpb at openjdk.org  Fri Nov 15 16:14:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 16:14:59 GMT
Subject: Integrated: 8343039: Remove jdk.internal.misc.InternalLock and usages
 from java.io
In-Reply-To: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
References: <Gk4E5GYhh_gnT9E3yvz2uM5dSMgj0XTEkORfbTSV51o=.510325d0-d7c5-41f0-b9fe-e1664038f177@github.com>
Message-ID: <dSGEp-tgesm3XNp7rlVG_88-IsfmnWLMcigVFFm_Rlc=.aeb31336-9b33-4840-8c64-d54aeebf3874@github.com>

On Tue, 12 Nov 2024 21:45:41 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Uses of `InternalLock` are removed and `synchronized` is reinstated.

This pull request has now been integrated.

Changeset: 0b9b82af
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0b9b82af0376a3e81c118e9219b896c7c40a52d3
Stats:     1880 lines in 19 files changed: 97 ins; 1338 del; 445 mod

8343039: Remove jdk.internal.misc.InternalLock and usages from java.io

Reviewed-by: liach, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22048

From liach at openjdk.org  Fri Nov 15 16:17:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 16:17:53 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
Message-ID: <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>

On Fri, 15 Nov 2024 15:58:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant suppression
>
> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 82:
> 
>> 80: 
>> 81:     private ClassFileDumper(String key, String path) {
>> 82:         /*
> 
> The comment might still be relevant if changed to System.getProperty.

It's fine now: previously user defined security manager was effectively loading user code that uses java.lang.invoke, now users cannot specify security managers, so this problem does not exist any more.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844121917

From rriggs at openjdk.org  Fri Nov 15 16:25:48 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 16:25:48 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
Message-ID: <OjpdbEntZzuLO84Ro3rz7Sutl0YKi0z02HJ_POqAheg=.46dd6984-660d-42ed-9551-c59703926267@github.com>

On Fri, 15 Nov 2024 16:15:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 82:
>> 
>>> 80: 
>>> 81:     private ClassFileDumper(String key, String path) {
>>> 82:         /*
>> 
>> The comment might still be relevant if changed to System.getProperty.
>
> It's fine now: previously user defined security manager was effectively loading user code that uses java.lang.invoke, now users cannot specify security managers, so this problem does not exist any more.

In that case, the code should be calling System.getProperty and not the backup VM saved props.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844128182

From eirbjo at openjdk.org  Fri Nov 15 16:25:48 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 16:25:48 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
Message-ID: <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>

On Fri, 15 Nov 2024 16:15:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/util/ClassFileDumper.java line 82:
>> 
>>> 80: 
>>> 81:     private ClassFileDumper(String key, String path) {
>>> 82:         /*
>> 
>> The comment might still be relevant if changed to System.getProperty.
>
> It's fine now: previously user defined security manager was effectively loading user code that uses java.lang.invoke, now users cannot specify security managers, so this problem does not exist any more.

@liach Does this mean we can/should use `System.getProperty` here?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844129578

From liach at openjdk.org  Fri Nov 15 16:25:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 16:25:49 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
 <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
Message-ID: <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>

On Fri, 15 Nov 2024 16:21:10 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> It's fine now: previously user defined security manager was effectively loading user code that uses java.lang.invoke, now users cannot specify security managers, so this problem does not exist any more.
>
> @liach Does this mean we can/should use `System.getProperty` here?

VM saved props is still better imo as user code cannot tamper it with System.setProperty.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844132661

From rriggs at openjdk.org  Fri Nov 15 16:30:55 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 16:30:55 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
 <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
 <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>
Message-ID: <xa3niIkf416gTYz11PUXGhU83OJAZ3PzLXmQpVkS4zE=.16fff024-e15f-4519-83be-617e0ab72d2c@github.com>

On Fri, 15 Nov 2024 16:23:28 GMT, Chen Liang <liach at openjdk.org> wrote:

>> @liach Does this mean we can/should use `System.getProperty` here?
>
> VM saved props is still better imo as user code cannot tamper it with System.setProperty.

VM.save props should only be used if there is a bootstrap issue.
If tampering is a concern, then the property should be added to StaticProperties.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844138793

From rriggs at openjdk.org  Fri Nov 15 16:34:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 16:34:56 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <xa3niIkf416gTYz11PUXGhU83OJAZ3PzLXmQpVkS4zE=.16fff024-e15f-4519-83be-617e0ab72d2c@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
 <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
 <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>
 <xa3niIkf416gTYz11PUXGhU83OJAZ3PzLXmQpVkS4zE=.16fff024-e15f-4519-83be-617e0ab72d2c@github.com>
Message-ID: <HZYh4a7bjotKhpR85cMbf_4VnhAT8rBnJgYkVHwet3c=.3bfb7378-f257-4501-9f7f-ebfb942cf3ce@github.com>

On Fri, 15 Nov 2024 16:28:13 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> VM saved props is still better imo as user code cannot tamper it with System.setProperty.
>
> VM.save props should only be used if there is a bootstrap issue.
> If tampering is a concern, then the property should be added to StaticProperties.

The use of the properties in ClassFileDumper is all in support of debug capabilities and is not sensitive.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844143559

From iklam at openjdk.org  Fri Nov 15 16:38:20 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 15 Nov 2024 16:38:20 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v14]
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <TKeSI9gfuvj3iZ3wYeoQ7npTzMP8NsxQNgUe77nCc-8=.943e25a1-e8be-4fac-8ac7-c2feeb9e707f@github.com>

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:

  Fixed test after security manager removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21642/files
  - new: https://git.openjdk.org/jdk/pull/21642/files/b317b4b5..5d9a6677

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21642&range=12-13

  Stats: 8 lines in 1 file changed: 0 ins; 4 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/21642.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21642/head:pull/21642

PR: https://git.openjdk.org/jdk/pull/21642

From jrose at openjdk.org  Fri Nov 15 17:04:59 2024
From: jrose at openjdk.org (John R Rose)
Date: Fri, 15 Nov 2024 17:04:59 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v14]
In-Reply-To: <TKeSI9gfuvj3iZ3wYeoQ7npTzMP8NsxQNgUe77nCc-8=.943e25a1-e8be-4fac-8ac7-c2feeb9e707f@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <TKeSI9gfuvj3iZ3wYeoQ7npTzMP8NsxQNgUe77nCc-8=.943e25a1-e8be-4fac-8ac7-c2feeb9e707f@github.com>
Message-ID: <icMCGgjstVnRvma-jZ_rr699IXYnSYxJ9ZMOlWs3V5Y=.8fe2f081-2913-4518-96ae-881eadbf7881@github.com>

On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test after security manager removal

Reviewed again.

-------------

Marked as reviewed by jrose (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21642#pullrequestreview-2439181309

From naoto at openjdk.org  Fri Nov 15 17:08:12 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 17:08:12 GMT
Subject: RFR: 8344252: SM cleanup in java.util classes [v2]
In-Reply-To: <cj90fQBlZT8HZwgJIz6dRtGg6HhTrrzYbCLPySTeSWo=.b6e32d55-6676-4d68-a307-88157955e734@github.com>
References: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
 <cj90fQBlZT8HZwgJIz6dRtGg6HhTrrzYbCLPySTeSWo=.b6e32d55-6676-4d68-a307-88157955e734@github.com>
Message-ID: <Au0s3SZgCys6ZkYeRij8qws78ujjpclSw84G2SO1UTs=.f195da55-d664-49f1-b9f2-75d2f9baf012@github.com>

On Fri, 15 Nov 2024 16:06:41 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Remove use of doPrivileged and SecurityManager in java.util.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Applied suggestions from review comments

src/java.base/share/classes/java/util/spi/AbstractResourceBundleProvider.java line 82:

> 80:  *
> 81:  * @see <a href="ResourceBundle##resource-bundle-modules">
> 82:  * Resource Bundles and Named Modules</a>

I think HTML tag is not needed:
Suggestion:

 * @see ResourceBundle##resource-bundle-modules
 * Resource Bundles and Named Modules

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22122#discussion_r1844187533

From aefimov at openjdk.org  Fri Nov 15 17:09:35 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Fri, 15 Nov 2024 17:09:35 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
Message-ID: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>

This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
- The following two properties are removed:
    - `com.sun.jndi.ldap.object.trustURLCodebase`
    - `com.sun.jndi.rmi.object.trustURLCodebase`
- JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
- The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
- Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.

These changes require a CSR that will be submitted soon.

### Testing
- Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
- `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.

-------------

Commit messages:
 - 8338536: Permanently disable remote code downloading in JNDI

Changes: https://git.openjdk.org/jdk/pull/22154/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8338536
  Stats: 544 lines in 11 files changed: 300 ins; 187 del; 57 mod
  Patch: https://git.openjdk.org/jdk/pull/22154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22154/head:pull/22154

PR: https://git.openjdk.org/jdk/pull/22154

From liach at openjdk.org  Fri Nov 15 17:12:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 17:12:52 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <HZYh4a7bjotKhpR85cMbf_4VnhAT8rBnJgYkVHwet3c=.3bfb7378-f257-4501-9f7f-ebfb942cf3ce@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
 <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
 <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>
 <xa3niIkf416gTYz11PUXGhU83OJAZ3PzLXmQpVkS4zE=.16fff024-e15f-4519-83be-617e0ab72d2c@github.com>
 <HZYh4a7bjotKhpR85cMbf_4VnhAT8rBnJgYkVHwet3c=.3bfb7378-f257-4501-9f7f-ebfb942cf3ce@github.com>
Message-ID: <RMKhkWEj51uFUPfXJdkuTGufhHSvhtdzLpc129bacO0=.b3c9a6db-ad22-4fb9-9f79-f257dba230d9@github.com>

On Fri, 15 Nov 2024 16:31:54 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> VM.save props should only be used if there is a bootstrap issue.
>> If tampering is a concern, then the property should be added to StaticProperties.
>
> The use of the properties in ClassFileDumper is all in support of debug capabilities and is not sensitive.

Either way is fine.  I think we probably need to review the majority of uses of VM.savedPropoerty as they mostly relate to SM boot circularity.  So we will change this one either now or later.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844191576

From liach at openjdk.org  Fri Nov 15 17:12:52 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 17:12:52 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
Message-ID: <pB-WXcrqk7DR01VXqUTbAsnLVjEfa65TmZkHVdIhRGw=.36b52526-408c-4b65-abe5-33f10879d873@github.com>

On Fri, 15 Nov 2024 15:43:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
>> 
>> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
>> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
>> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
>> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
>> 
>> Verification: GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant suppression

Marked as reviewed by liach (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22141#pullrequestreview-2439197929

From psandoz at openjdk.org  Fri Nov 15 17:25:15 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 15 Nov 2024 17:25:15 GMT
Subject: RFR: 8344259: Annotate Float16 with jdk.internal.ValueBased
In-Reply-To: <knHUvDicx9EXar6bRDSBL93WXEmoVYvm_5nAzq87nfo=.56a7024c-d39e-4ed1-ab96-308330b9932e@github.com>
References: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>
 <knHUvDicx9EXar6bRDSBL93WXEmoVYvm_5nAzq87nfo=.56a7024c-d39e-4ed1-ab96-308330b9932e@github.com>
Message-ID: <SimK9cInWUWxte82MoE7TJOBBf4usRpXhUqVowZhdLs=.ae0e95b9-5ce8-49bb-a160-2fb4641a05fc@github.com>

On Fri, 15 Nov 2024 01:02:49 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> Looks fine; please manually verify the expected javac warnings are given for misuse of Float16 in non-value ways.

I manually and successfully tested compilation and execution of source that synchronized on an instance of Float16.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22128#issuecomment-2479491513

From psandoz at openjdk.org  Fri Nov 15 17:25:15 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Fri, 15 Nov 2024 17:25:15 GMT
Subject: Integrated: 8344259: Annotate Float16 with jdk.internal.ValueBased
In-Reply-To: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>
References: <XPMeU7etdasn4OKNZMNQ1BMINHmQjxQR3aZDXxwPV7I=.c4c87ae8-d0d2-41d1-894a-b531b326aac2@github.com>
Message-ID: <ae6l9udZQ9X_Gb5YmURWNeEEFNBH50LEUHYhkFaRtr0=.3732aa42-1229-4be8-8be6-c9bcb5dc65be@github.com>

On Fri, 15 Nov 2024 00:25:20 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> Annotate `Float16` with `jdk.internal.ValueBased`. This requires we export the package `jdk.internal` in module `java.base` to module` jdk.incubator.vector`.
> 
> Doing so enables the compiler and runtime to report warnings about improper attempts to synchronize on instances of `Float16`, as described in [JEP 390](https://openjdk.org/jeps/390).

This pull request has now been integrated.

Changeset: 1866c0c2
Author:    Paul Sandoz <psandoz at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/1866c0c2ce925ed5236532cb7e3bdc61a6cd18d5
Stats:     5 lines in 2 files changed: 2 ins; 1 del; 2 mod

8344259: Annotate Float16 with jdk.internal.ValueBased

Reviewed-by: liach, darcy

-------------

PR: https://git.openjdk.org/jdk/pull/22128

From alanb at openjdk.org  Fri Nov 15 17:35:59 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 17:35:59 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v2]
In-Reply-To: <vjh90OP0en34HdZug3mchir81g_dJ6KLLK3loCafgUQ=.cb302f30-52a6-450e-8f5b-8dcb0f3e8db7@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <vjh90OP0en34HdZug3mchir81g_dJ6KLLK3loCafgUQ=.cb302f30-52a6-450e-8f5b-8dcb0f3e8db7@github.com>
Message-ID: <aqbYwxqi7BZQp1vALPnr77MWaaxoZO8ZsG8eWkH2hgc=.059cb156-08b0-4c47-a12d-d5fb5880e55d@github.com>

On Fri, 15 Nov 2024 15:47:43 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/atomic/AtomicIntegerFieldUpdater.java line 399:
>> 
>>> 397:                 if ((ccl != null) && (ccl != cl) &&
>>> 398:                     ((cl == null) || !isAncestor(cl, ccl))) {
>>> 399:                     sun.reflect.misc.ReflectUtil.checkPackageAccess(tclass);
>> 
>> The ensureMemberAccess needs to stay but the checkPackageAccess can be removed.
>> 
>> @seanjmullan I think you'll want to study this one closely.
>
> ok, removing package access check

I see you've removed it from AtomicIntegerFieldUpdater. There are also checkPackageAccess usages in AtomicLongFieldUpdater and AtomicReferenceFieldUpdater.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844228641

From henryjen at openjdk.org  Fri Nov 15 17:36:46 2024
From: henryjen at openjdk.org (Henry Jen)
Date: Fri, 15 Nov 2024 17:36:46 GMT
Subject: RFR: 8321413: IllegalArgumentException: Code length outside the
 allowed range while creating a jlink image [v11]
In-Reply-To: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
References: <e6ZTwg9pzCXfjgelsGDe0R5bJX-8V1Ci6_M87H_g7hU=.a8955bbc-d364-4721-9f46-e1a5a900f60b@github.com>
Message-ID: <_SOOQjAtP8TDDal0IjHm6708txRiQOcGanjmQCz0Bzk=.feb47b7d-0489-4e38-b0b0-8c61ede46a70@github.com>

> This PR split out large array/set construction into separate factory methods to avoid oversized method trying to construct several of those.
> 
> In order to do that, we will need to generate those help methods on demand in the class builder. Here we have two approach, one is for dedup set, which is processed in advance so we can know what methods should be created.
> 
> Another is for random set, such as packages, thus we put those request into a queue to amend the class later.
> 
> To keep the optimization of caching built value that are references more than once, it was implemented using local vars, which doesn't work well for helper methods. The existing approach to populate local vars doesn't work well with larger scope of split operation, as the slot was allocated on lazily built, but the transfer is captured in advance, this count could mismatch as built time and run time.
> 
> So we make this build in advance, and use a static array for values referred more than once.
> 
> All the codegen instead of giving index to be loaded, the builder snippet now load the wanted set/array to the operand stack to be consistent.

Henry Jen has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Merge remote-tracking branch 'openjdk/master' into JDK-8321413
 - Minor cleanup
 - Rename based on feedback to emphasis building a snippet for loading a reference
 - Fix typo and comment to match latest implementation
 - Fix regression failed to setup helper methods properly
 - Separate out ModuleDescriptorBuilder and use LoadableArray for paging
 - Merge remote-tracking branch 'openjdk/master' into JDK-8321413
 - Loadable support with paging support. The limiting factor is now constant pool size
 - Add more comments, move snippet generation code into standalone class
 - Fix typo and add comments based on review feedback
 - ... and 3 more: https://git.openjdk.org/jdk/compare/d3da5327...4e82d04e

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21022/files
  - new: https://git.openjdk.org/jdk/pull/21022/files/69d84664..4e82d04e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21022&range=09-10

  Stats: 302901 lines in 4502 files changed: 148216 ins; 123438 del; 31247 mod
  Patch: https://git.openjdk.org/jdk/pull/21022.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21022/head:pull/21022

PR: https://git.openjdk.org/jdk/pull/21022

From rriggs at openjdk.org  Fri Nov 15 17:46:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 17:46:07 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v3]
In-Reply-To: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
Message-ID: <ADOzCbRb5rNwKGgcXn29_Q6FI8rCahFAYe0tSVN1uPM=.83f86e9c-f006-44cf-89cd-53557fc88ceb@github.com>

> Refactored to remove use of doPrivileged() and use of SecurityManager.
> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
> 
> A careful review is requested.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove additional package access checks in AtomicLongFieldUpdater and AtomicReferenceFieldUpdater

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22119/files
  - new: https://git.openjdk.org/jdk/pull/22119/files/21013c28..9632ac50

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22119&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22119&range=01-02

  Stats: 12 lines in 2 files changed: 0 ins; 12 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22119.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22119/head:pull/22119

PR: https://git.openjdk.org/jdk/pull/22119

From rriggs at openjdk.org  Fri Nov 15 17:46:07 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 17:46:07 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v3]
In-Reply-To: <aqbYwxqi7BZQp1vALPnr77MWaaxoZO8ZsG8eWkH2hgc=.059cb156-08b0-4c47-a12d-d5fb5880e55d@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <vjh90OP0en34HdZug3mchir81g_dJ6KLLK3loCafgUQ=.cb302f30-52a6-450e-8f5b-8dcb0f3e8db7@github.com>
 <aqbYwxqi7BZQp1vALPnr77MWaaxoZO8ZsG8eWkH2hgc=.059cb156-08b0-4c47-a12d-d5fb5880e55d@github.com>
Message-ID: <pb0vGzhwuLLLVDZqOozfYKNg0NE6jYzp0Am2Ia83aMM=.ef623be9-cc63-47b0-991a-c74e9a0436c6@github.com>

On Fri, 15 Nov 2024 17:32:38 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> ok, removing package access check
>
> I see you've removed it from AtomicIntegerFieldUpdater. There are also checkPackageAccess usages in AtomicLongFieldUpdater and AtomicReferenceFieldUpdater.

also removed

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844240826

From liach at openjdk.org  Fri Nov 15 17:49:58 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 17:49:58 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v2]
In-Reply-To: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
Message-ID: <WFNvdXFc4a-q8Gm-6YrZqWaQjv_YNrC_MXfrljhVryI=.c569054f-8d2b-402b-9c94-e2266d1ae91d@github.com>

> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:

 - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
 - Typos, long lines
 - Labels
 - Wip instr

-------------

Changes: https://git.openjdk.org/jdk/pull/21625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21625&range=01
  Stats: 1396 lines in 29 files changed: 1064 ins; 12 del; 320 mod
  Patch: https://git.openjdk.org/jdk/pull/21625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21625/head:pull/21625

PR: https://git.openjdk.org/jdk/pull/21625

From rriggs at openjdk.org  Fri Nov 15 17:52:28 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 17:52:28 GMT
Subject: RFR: 8344252: SM cleanup in java.util classes [v3]
In-Reply-To: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
References: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
Message-ID: <4MWPGqjfxblaSlsMPqS9V49dZxHfUckyAdopHxdpXFc=.3ba4f181-e96f-4228-afc9-ec2221a2fc45@github.com>

> Remove use of doPrivileged and SecurityManager in java.util.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Correct @see link syntax in AbstractResourceBundleProvider

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22122/files
  - new: https://git.openjdk.org/jdk/pull/22122/files/f8e518f7..1a0814ce

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22122&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22122&range=01-02

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22122.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22122/head:pull/22122

PR: https://git.openjdk.org/jdk/pull/22122

From liach at openjdk.org  Fri Nov 15 18:01:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 18:01:15 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v9]
In-Reply-To: <JE-8A6iE-MZ50BpA8VbCMBmm29cqnOR4vU-kcXm-8cM=.fd906924-946f-49b8-bd3e-816322932b4f@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <JE-8A6iE-MZ50BpA8VbCMBmm29cqnOR4vU-kcXm-8cM=.fd906924-946f-49b8-bd3e-816322932b4f@github.com>
Message-ID: <rVbK_u734YRj8w_IMnFpPNDGT5vCl0zhYxVqktB3R-M=.e070d061-e4a2-481f-aefc-bc6892174064@github.com>

On Fri, 15 Nov 2024 10:19:46 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Do not need -ea -esa in tests, our testing infra adds them already

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 249:

> 247:          * the time.
> 248:          */
> 249:         private Node cache;

Should the cache be soft, as it keeps the 4096-long array reachable?  Not familiar with this matter, please enlighten me.

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 356:

> 354: 
> 355:             // Linked list structure.
> 356:             Node prev;

The prev link seems only ever written but never read.  This can be a singly-linked list, I believe.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844252581
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844256631

From alanb at openjdk.org  Fri Nov 15 18:05:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Fri, 15 Nov 2024 18:05:45 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v3]
In-Reply-To: <ADOzCbRb5rNwKGgcXn29_Q6FI8rCahFAYe0tSVN1uPM=.83f86e9c-f006-44cf-89cd-53557fc88ceb@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <ADOzCbRb5rNwKGgcXn29_Q6FI8rCahFAYe0tSVN1uPM=.83f86e9c-f006-44cf-89cd-53557fc88ceb@github.com>
Message-ID: <crFq3U6Xz7Jc_El_ejh_F-AdCFw27P5sZiTE4FjKvHI=.1dce0a2d-320b-426a-91bc-85adc6e7e63e@github.com>

On Fri, 15 Nov 2024 17:46:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactored to remove use of doPrivileged() and use of SecurityManager.
>> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
>> 
>> A careful review is requested.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove additional package access checks in AtomicLongFieldUpdater and AtomicReferenceFieldUpdater

Thanks for dropping the FJP changes from this patch. I did another pass over the updates in revision 9632ac50 and it looks okay. I've set the Reviewer count to 2 so that Doug or Viktor get a chance to review before this is integrated.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22119#pullrequestreview-2439307715

From dl at openjdk.org  Fri Nov 15 18:05:46 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 15 Nov 2024 18:05:46 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v3]
In-Reply-To: <CxOMq9QyL_NBtXPwSurpRZXo0JK0p_YBIk_sy_1-IZ4=.5aa2d927-2335-49c0-be6f-7f5b32dea81c@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <e8_4YDp98Q7ckDO2ocBEB-UYXSIdNatufdlP7kcw5mg=.ed46a410-c870-42f2-a018-1ae4a34bc43a@github.com>
 <CxOMq9QyL_NBtXPwSurpRZXo0JK0p_YBIk_sy_1-IZ4=.5aa2d927-2335-49c0-be6f-7f5b32dea81c@github.com>
Message-ID: <GPf-TSqhpS7ZJR-GENZwWwPCfPxR2Cd27LxWKHSYpGM=.35dc9704-6f80-4704-9a74-e34e1dd322a2@github.com>

On Fri, 15 Nov 2024 15:56:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> I agree on both counts with Alan: The FJP changes are not quite right, and in any case should be postponed until after current FJP PR, and then further simplified, which would be easiest if I did this.
>
> @DougLea If you prefer, I can leave any/all changes to you.

OK. Will do after https://github.com/DougLea/jdk/tree/JDK-8336707 is integrated

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844265945

From rgiulietti at openjdk.org  Fri Nov 15 18:16:02 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Fri, 15 Nov 2024 18:16:02 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
Message-ID: <l4ubnvIGIIGY6LeWC8-eptfAddk3kMJ4eYJF4iBa3no=.b8e63355-5635-4b83-8ed5-7435645654a9@github.com>

On Fri, 15 Nov 2024 15:43:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
>> 
>> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
>> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
>> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
>> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
>> 
>> Verification: GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant suppression

src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 728:

> 726:     // The following decides which of two strategies initialSeed() will use.
> 727:     private static boolean secureRandomSeedRequested() {
> 728:         return Boolean.getBoolean("java.util.secureRandomSeed");

Not sure why access to this system property required privileges.

It is documented in [SplittableRandom](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/SplittableRandom.html#java.util.secureRandomSeed), so I guess it's OK to have unprivileged access.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844278216

From bpb at openjdk.org  Fri Nov 15 18:20:45 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 18:20:45 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
Message-ID: <57T3wEghAOjMlkt_tTXfJwYOk3gXWSx__4NNc2EcDgg=.937e4872-3611-48f9-8030-ddc78941f224@github.com>

On Fri, 15 Nov 2024 15:43:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
>> 
>> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
>> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
>> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
>> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
>> 
>> Verification: GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant suppression

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22141#pullrequestreview-2439337056

From asemenyuk at openjdk.org  Fri Nov 15 18:25:21 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 18:25:21 GMT
Subject: RFR: 8344326: Move jpackage tests from "jdk.jpackage.tests" package to
 the default package
Message-ID: <oyk1kQHiajPvi6YrzTcvC9VbtnswHRsg26VNp-5e9Vk=.4bb08a1b-bba3-4b22-a896-4975586983a9@github.com>

Move jpackage tests from "jdk.jpackage.tests" package to the default package.

Remove `WindowsHelper.getTempDirectory()`. It is faulty and found limited use. Updated dependent tests accordingly.

-------------

Commit messages:
 - Rollback excessive change
 - Rollback excessive change
 - Unused commit removed
 - - Move tests from "jdk.jpackage.tests" package to the default package.

Changes: https://git.openjdk.org/jdk/pull/22156/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22156&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344326
  Stats: 81 lines in 21 files changed: 1 ins; 44 del; 36 mod
  Patch: https://git.openjdk.org/jdk/pull/22156.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22156/head:pull/22156

PR: https://git.openjdk.org/jdk/pull/22156

From asemenyuk at openjdk.org  Fri Nov 15 18:25:22 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 18:25:22 GMT
Subject: RFR: 8344326: Move jpackage tests from "jdk.jpackage.tests"
 package to the default package
In-Reply-To: <oyk1kQHiajPvi6YrzTcvC9VbtnswHRsg26VNp-5e9Vk=.4bb08a1b-bba3-4b22-a896-4975586983a9@github.com>
References: <oyk1kQHiajPvi6YrzTcvC9VbtnswHRsg26VNp-5e9Vk=.4bb08a1b-bba3-4b22-a896-4975586983a9@github.com>
Message-ID: <hmQZTPAFkVJTijqqCqpR0i8faU3u-IMUNV_KI9KKI9s=.2287e639-083f-484c-b1c8-58558ecb479c@github.com>

On Fri, 15 Nov 2024 18:18:08 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move jpackage tests from "jdk.jpackage.tests" package to the default package.
> 
> Remove `WindowsHelper.getTempDirectory()`. It is faulty and found limited use. Updated dependent tests accordingly.

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22156#issuecomment-2479663596

From rriggs at openjdk.org  Fri Nov 15 18:29:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 18:29:51 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <l4ubnvIGIIGY6LeWC8-eptfAddk3kMJ4eYJF4iBa3no=.b8e63355-5635-4b83-8ed5-7435645654a9@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <l4ubnvIGIIGY6LeWC8-eptfAddk3kMJ4eYJF4iBa3no=.b8e63355-5635-4b83-8ed5-7435645654a9@github.com>
Message-ID: <E2onExsDxFhPAEKb3kpATS4G3fAdeV2hGsAMf5SH-Hw=.c8ed3ad6-1a34-4308-b3e4-a7fbf45dc206@github.com>

On Fri, 15 Nov 2024 18:12:31 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove redundant suppression
>
> src/java.base/share/classes/jdk/internal/util/random/RandomSupport.java line 728:
> 
>> 726:     // The following decides which of two strategies initialSeed() will use.
>> 727:     private static boolean secureRandomSeedRequested() {
>> 728:         return Boolean.getBoolean("java.util.secureRandomSeed");
> 
> Not sure why access to this system property required privileges.
> 
> It is documented in [SplittableRandom](https://docs.oracle.com/en/java/javase/23/docs/api/java.base/java/util/SplittableRandom.html#java.util.secureRandomSeed), so I guess it's OK to have unprivileged access.

Previously, all properties were enabled only if allowed by the security policy. 
Any property could be denied. Though it could/would cause havoc if used indiscriminately.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844297091

From asemenyuk at openjdk.org  Fri Nov 15 18:34:07 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 18:34:07 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v5]
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <42J3-uE8ZhwfJNPByBMPA-zKoD-1xqNsL1xtA-XpKmE=.7c40a6ff-6b26-44c0-b841-f6dbc825277a@github.com>

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Remove JDK-8344322-specific changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21996/files
  - new: https://git.openjdk.org/jdk/pull/21996/files/2b746d49..9c3a81fb

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21996&range=03-04

  Stats: 31 lines in 1 file changed: 0 ins; 28 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/21996.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21996/head:pull/21996

PR: https://git.openjdk.org/jdk/pull/21996

From bchristi at openjdk.org  Fri Nov 15 18:38:54 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 15 Nov 2024 18:38:54 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v8]
In-Reply-To: <huRaj7lMPAUFB5-EkaW6Xjg2KCNBfPyTq9ao-c39pLQ=.340c8505-5017-4460-9efa-33e85d8ae803@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <sP0fEG0kWc5ftWFvPhFM2KtcrwWizw_zFv67gp2uN0o=.5bb8eab9-db17-4b5e-8ec0-f9540c8b290d@github.com>
 <huRaj7lMPAUFB5-EkaW6Xjg2KCNBfPyTq9ao-c39pLQ=.340c8505-5017-4460-9efa-33e85d8ae803@github.com>
Message-ID: <Mo558IaYt3H-b-dhWl2lsAb0sjNdFcw5fS_zYSxSG6I=.f47f6695-db0d-460e-b92f-fb5fbe4ba107@github.com>

On Fri, 15 Nov 2024 10:11:38 GMT, Francesco Nigro <duke at openjdk.org> wrote:

> ...in case having a lock-free structure can be of any help, in JCTools we have...

We should continue to lock the same lock in `insert()` and `remove()`, as it creates the _happens-before_ between the
thread registering the `Cleaner`, and the Cleaner's thread, per [Cleaner.register](https://download.java.net/java/early_access/jdk24/docs/api/java.base/java/lang/ref/Cleaner.html#register(java.lang.Object,java.lang.Runnable)):

> Actions in a thread prior to calling Cleaner.register() _happen-before_ the cleaning action is run by the Cleaner's thread.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2479688813

From rriggs at openjdk.org  Fri Nov 15 18:38:26 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 18:38:26 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
Message-ID: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>

This cleanup of the use of SecurityManager is in the jdk.unsupported module.
Removed the permission check to call getReflectionFactory().

-------------

Commit messages:
 - 8344327: SM cleanup in jdk.unsupported ReflectionFactory

Changes: https://git.openjdk.org/jdk/pull/22158/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22158&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344327
  Stats: 31 lines in 1 file changed: 0 ins; 28 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22158.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22158/head:pull/22158

PR: https://git.openjdk.org/jdk/pull/22158

From naoto at openjdk.org  Fri Nov 15 18:39:58 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 18:39:58 GMT
Subject: RFR: 8344252: SM cleanup in java.util classes [v3]
In-Reply-To: <4MWPGqjfxblaSlsMPqS9V49dZxHfUckyAdopHxdpXFc=.3ba4f181-e96f-4228-afc9-ec2221a2fc45@github.com>
References: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
 <4MWPGqjfxblaSlsMPqS9V49dZxHfUckyAdopHxdpXFc=.3ba4f181-e96f-4228-afc9-ec2221a2fc45@github.com>
Message-ID: <Q3r0BIlPSFr_npTQd3eJDD9XZ3wMfJmSZrDMD-r-gho=.3fe201a6-f68a-440f-93f3-56a58a5c74ed@github.com>

On Fri, 15 Nov 2024 17:52:28 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Remove use of doPrivileged and SecurityManager in java.util.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct @see link syntax in AbstractResourceBundleProvider

LGTM

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22122#pullrequestreview-2439370295

From liach at openjdk.org  Fri Nov 15 18:40:41 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 18:40:41 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <Cj082EttFoJ74RL-aOJDrIJrYwHzW1_BVeiHZNr3nzo=.288d7255-6558-48da-a421-b0292618ee87@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

Good.  We might need a CSR as this changes API specification.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22158#pullrequestreview-2439371461

From vlivanov at openjdk.org  Fri Nov 15 18:53:46 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Fri, 15 Nov 2024 18:53:46 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v5]
In-Reply-To: <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
Message-ID: <_e4cV3iB485lOoKDn_Bkt2G_Qni8XwL9czQFTOhXAis=.91751b42-23cf-4ed3-acc0-68a97b0b0ab9@github.com>

On Thu, 14 Nov 2024 18:24:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

Testing results are clean.

-------------

Marked as reviewed by vlivanov (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2439389187

From dl at openjdk.org  Fri Nov 15 18:59:54 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 15 Nov 2024 18:59:54 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v3]
In-Reply-To: <AF4yVvpybOrVVtigWxPe_JDhW7bQKr8CVlVL23JVRR0=.7840a352-bd12-40ed-877e-fb0104bd4c1b@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <-e_UHt7FselS8wy-lc07nEdmC80ixHt_2kEOBvOGuBc=.3d21aa84-ccd7-486d-8b05-dcde34891e29@github.com>
 <Mat3YDll2sngEQtQ1eJtTu2WzVKTJ3nfxS6LXrKTBnk=.a868c0a1-dc35-4dff-9193-e16c28c5af52@github.com>
 <CS4Zg1UsL7GNwf_V_bdO74eXngsVxY5y395xEEjUcjY=.23090e8a-acbf-4a44-bfac-64b457a0dcd8@github.com>
 <AF4yVvpybOrVVtigWxPe_JDhW7bQKr8CVlVL23JVRR0=.7840a352-bd12-40ed-877e-fb0104bd4c1b@github.com>
Message-ID: <knfVKdvSJAp8CDkm3oBVBSnnTb2FBqFnNxZwXPY7f74=.bfc01fbd-7656-4de0-b8b6-80dc2d265b57@github.com>

On Fri, 15 Nov 2024 15:46:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Deleting it would also mean removing or modifying a bunch of j.u./tck tests. Perhaps deprecation is enough.
>
> ok, for future cleanup

Although it is barely conceivable that someone is using it for the sake of capturing the current class loader, so probably not worth trying to remove. The name will become even more mysterious to users though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22119#discussion_r1844327206

From eirbjo at openjdk.org  Fri Nov 15 19:24:00 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 19:24:00 GMT
Subject: Integrated: 8344231: SecurityManager cleanup in java.lang.module and
 jdk.internal.module
In-Reply-To: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
References: <SQ8m6cTPVB_xc6lfBY7sPuwSpktgZ-QcFhCltURRk2Q=.87d91414-6a34-4f50-96e4-f23b06235d40@github.com>
Message-ID: <DWVLPTSkTrkyyKGPtwKn7gkHtvs2ZlBCjUp2JBrckSo=.a8948513-fe67-40ac-9891-3460724faab6@github.com>

On Thu, 14 Nov 2024 17:32:40 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes code depending on SecurityManager from the `java.lang.module` and `jdk.internal.module` packages:
> 
> * `ModuleFinder::ofSystem` is updated to not check the `"accessSystemModules"` RuntimePermission
> * The `ModuleReferences.ExplodedModuleReader` constructor is updated to remove the check that the caller has access to the directory.
> * `Modules::addProvides` is updated to not use `AccessController::doPrivileged` when getting the module class loader
> * `SystemModuleFinder::ofSystem` is updated to not returned a wrapped result calling `AccessController::doPrivileged`
> * `SystemModuleFinders.SystemImage` is updated to remove a class level comment referring to the SM
> * `SystemModuleFinders.SystemModuleReader::checkPermissionToConnect` is removed. The URI constructor parameter in `SystemModuleReader` becomes unused and is removed.
> 
> 
> Testing: I have run `test/jdk/java/lang/module`, `test/jdk/java/lang/ModuleTests`,  and `test/jdk/java/lang/ModuleLayer` successfully. GHA results pending.

This pull request has now been integrated.

Changeset: f62e05ee
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/f62e05ee96085675041c5cb94762f78abbc89783
Stats:     68 lines in 4 files changed: 0 ins; 60 del; 8 mod

8344231: SecurityManager cleanup in java.lang.module and jdk.internal.module

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22113

From shade at openjdk.org  Fri Nov 15 19:26:56 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Nov 2024 19:26:56 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v9]
In-Reply-To: <rVbK_u734YRj8w_IMnFpPNDGT5vCl0zhYxVqktB3R-M=.e070d061-e4a2-481f-aefc-bc6892174064@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <JE-8A6iE-MZ50BpA8VbCMBmm29cqnOR4vU-kcXm-8cM=.fd906924-946f-49b8-bd3e-816322932b4f@github.com>
 <rVbK_u734YRj8w_IMnFpPNDGT5vCl0zhYxVqktB3R-M=.e070d061-e4a2-481f-aefc-bc6892174064@github.com>
Message-ID: <0W2AKoESGVBmw9v2BIfbtF2y5I1ztWXAtwLXjaGhS6E=.707a1fa5-b8af-46f4-82fb-1c7959e9d5c7@github.com>

On Fri, 15 Nov 2024 17:55:30 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not need -ea -esa in tests, our testing infra adds them already
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 356:
> 
>> 354: 
>> 355:             // Linked list structure.
>> 356:             Node prev;
> 
> The prev link seems only ever written but never read.  This can be a singly-linked list, I believe.

Right! Removed `prev`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844355333

From shade at openjdk.org  Fri Nov 15 19:30:06 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Nov 2024 19:30:06 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  prev is not needed

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/a7584bcc..30c0c7c5

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=09
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=08-09

  Stats: 4 lines in 1 file changed: 0 ins; 4 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Fri Nov 15 19:30:07 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Fri, 15 Nov 2024 19:30:07 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v9]
In-Reply-To: <rVbK_u734YRj8w_IMnFpPNDGT5vCl0zhYxVqktB3R-M=.e070d061-e4a2-481f-aefc-bc6892174064@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <JE-8A6iE-MZ50BpA8VbCMBmm29cqnOR4vU-kcXm-8cM=.fd906924-946f-49b8-bd3e-816322932b4f@github.com>
 <rVbK_u734YRj8w_IMnFpPNDGT5vCl0zhYxVqktB3R-M=.e070d061-e4a2-481f-aefc-bc6892174064@github.com>
Message-ID: <hNJmdBuDDcPQARx4ns_gK2fKjsm9swrRwSq3i2NzS8w=.1bd61b71-ee06-4ff4-8587-e5d45a3de3ea@github.com>

On Fri, 15 Nov 2024 17:53:53 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Do not need -ea -esa in tests, our testing infra adds them already
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 249:
> 
>> 247:          * the time.
>> 248:          */
>> 249:         private Node cache;
> 
> Should the cache be soft, as it keeps the 4096-long array reachable?  Not familiar with this matter, please enlighten me.

I don't think this is necessary. Cleaners are supposed to be shared, so this list is supposed to be global. We are not winning much by using soft refs for this single-node cache.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844358093

From iris at openjdk.org  Fri Nov 15 19:30:55 2024
From: iris at openjdk.org (Iris Clark)
Date: Fri, 15 Nov 2024 19:30:55 GMT
Subject: RFR: 8342979: Start of release updates for JDK 25 [v6]
In-Reply-To: <I_76U8sLnYjjksGSKTE55NmlDK5fmk9Pou6t_sUwegY=.bca73f06-7e51-4d83-a31e-65ca4908241c@github.com>
References: <iPp8dujMOIAevWySqCGtqRMrv_9ZkhV3OxUwxz3p8z8=.395489a2-9e0f-4ba8-953e-8815f707256d@github.com>
 <I_76U8sLnYjjksGSKTE55NmlDK5fmk9Pou6t_sUwegY=.bca73f06-7e51-4d83-a31e-65ca4908241c@github.com>
Message-ID: <k_5IFbg6b1NiCM6cryK6mcTabp_BI1lbs82pp8SFrsw=.235cfeb1-5ece-412a-93b1-fc29fa2cb56e@github.com>

On Fri, 15 Nov 2024 11:35:40 GMT, Pavel Rappo <prappo at openjdk.org> wrote:

>> Prepare for JDK 25.
>
> Pavel Rappo has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains nine additional commits since the last revision:
> 
>  - Update --release 24 symbol information for JDK 24 build 24
>    
>    The macOS/AArch64 build 24 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 23
>    
>    The macOS/AArch64 build 23 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 22
>    
>    The macOS/AArch64 build 22 was taken from https://jdk.java.net/24/
>  - Merge branch 'master' into 8342979
>  - Update --release 24 symbol information for JDK 24 build 21
>    
>    The macOS/AArch64 build 21 was taken from https://jdk.java.net/24/
>  - Add forgotten .jcheck/conf
>  - Initial commit

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21763#pullrequestreview-2439451274

From naoto at openjdk.org  Fri Nov 15 19:32:05 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 19:32:05 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from jdk.charsets
 module
Message-ID: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>

Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/22162/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22162&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344330
  Stats: 12 lines in 1 file changed: 0 ins; 9 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22162/head:pull/22162

PR: https://git.openjdk.org/jdk/pull/22162

From lancea at openjdk.org  Fri Nov 15 19:35:55 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Fri, 15 Nov 2024 19:35:55 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <lvdNwtr7eBc1bqhPXa89G9EZLNb7rLPhzXM2rxaIycs=.1ae64177-3d95-4044-b2fd-b69a7e594448@github.com>

On Fri, 15 Nov 2024 19:26:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439458103

From bpb at openjdk.org  Fri Nov 15 19:41:48 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 19:41:48 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <aUCgEKWaQo4QZ_kVrd6RwdqtTLu8uF3T4CQpg5qu270=.cabd94dc-f2ff-446b-b55b-957ebab33339@github.com>

On Fri, 15 Nov 2024 19:26:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

Looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439470029

From darcy at openjdk.org  Fri Nov 15 19:44:00 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Fri, 15 Nov 2024 19:44:00 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v2]
In-Reply-To: <WFNvdXFc4a-q8Gm-6YrZqWaQjv_YNrC_MXfrljhVryI=.c569054f-8d2b-402b-9c94-e2266d1ae91d@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <WFNvdXFc4a-q8Gm-6YrZqWaQjv_YNrC_MXfrljhVryI=.c569054f-8d2b-402b-9c94-e2266d1ae91d@github.com>
Message-ID: <V6j8uzdZ_u0HxDdhEUiVVTh-FAqtQ1Mnwk_P6ogaANw=.e7eab725-52b2-476a-9ef5-34e5e2367141@github.com>

On Fri, 15 Nov 2024 17:49:58 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains four commits:
> 
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Typos, long lines
>  - Labels
>  - Wip instr

Marked as reviewed by darcy (Reviewer).

src/java.base/share/classes/java/lang/classfile/Opcode.java line 136:

> 134: 
> 135:     /**
> 136:      * Push {@link TypeKind#FLOAT float} constant {@code 0}.

For the float and double constants, it would be a small improvement to write them out as floating-point literals, "0.0f" for a float zero, etc.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21625#pullrequestreview-2439472963
PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1844372129

From dl at openjdk.org  Fri Nov 15 20:13:45 2024
From: dl at openjdk.org (Doug Lea)
Date: Fri, 15 Nov 2024 20:13:45 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v3]
In-Reply-To: <ADOzCbRb5rNwKGgcXn29_Q6FI8rCahFAYe0tSVN1uPM=.83f86e9c-f006-44cf-89cd-53557fc88ceb@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <ADOzCbRb5rNwKGgcXn29_Q6FI8rCahFAYe0tSVN1uPM=.83f86e9c-f006-44cf-89cd-53557fc88ceb@github.com>
Message-ID: <1ibykaUy5b2H2UMbAHun_IZuUFJFpSSdrncmblFwCgY=.f46f9de3-ca32-4a78-ba0a-b17295ae9b5f@github.com>

On Fri, 15 Nov 2024 17:46:07 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Refactored to remove use of doPrivileged() and use of SecurityManager.
>> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
>> 
>> A careful review is requested.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove additional package access checks in AtomicLongFieldUpdater and AtomicReferenceFieldUpdater

These now look OK to me too. 

A side question: Are there now any situations in which Thread.interrupt can throw an exception? If not, a few more things in j.u.c and elsewhere could be simplified someday.

-------------

Marked as reviewed by dl (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22119#pullrequestreview-2439532591

From naoto at openjdk.org  Fri Nov 15 20:17:59 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 20:17:59 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:

  fixed import

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22162/files
  - new: https://git.openjdk.org/jdk/pull/22162/files/ebd0523f..03d25e8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22162&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22162&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22162.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22162/head:pull/22162

PR: https://git.openjdk.org/jdk/pull/22162

From rriggs at openjdk.org  Fri Nov 15 20:17:59 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 20:17:59 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <KDfDQ0yMi-H3O7fVwMHkOVryETpEYG1dNAwfqH2bqsw=.fe6a54e5-93d3-4979-82f2-e2e1438136d4@github.com>

On Fri, 15 Nov 2024 20:15:10 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

looks good.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439536041

From rriggs at openjdk.org  Fri Nov 15 20:31:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 20:31:56 GMT
Subject: Integrated: 8344252: SM cleanup in java.util classes
In-Reply-To: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
References: <qNhTDnRy7n4KURBP8p5dGB7ugAtoNBJwtxyFBM2LkDA=.d9259c4d-10b3-4fa0-a624-a34b01640589@github.com>
Message-ID: <SZPSz5zQ-2fs6ShL-Q0Q2muKCokIueE73L3jGn_Rjds=.e39ec63d-6f9d-44c3-bb3a-2d68759bcbba@github.com>

On Thu, 14 Nov 2024 22:09:59 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Remove use of doPrivileged and SecurityManager in java.util.

This pull request has now been integrated.

Changeset: c5b6ed8c
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c5b6ed8ca0d4f9862fd6a890bcd457f73582696d
Stats:     369 lines in 13 files changed: 36 ins; 206 del; 127 mod

8344252: SM cleanup in java.util classes

Reviewed-by: naoto, smarks

-------------

PR: https://git.openjdk.org/jdk/pull/22122

From rriggs at openjdk.org  Fri Nov 15 20:33:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 20:33:13 GMT
Subject: Integrated: 8344197: SM cleanup in java.util.concurrent
In-Reply-To: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
Message-ID: <XF0WfwQtxyVqDX1QyJX2jU6Zly8ZHmVALiRhR7_q2xo=.54732180-5688-47c7-be0c-27acca3b73eb@github.com>

On Thu, 14 Nov 2024 20:45:49 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactored to remove use of doPrivileged() and use of SecurityManager.
> The DefaultForkJoinWorkerThreadFactory no longer uses the SM to target a common thread pool.
> 
> A careful review is requested.

This pull request has now been integrated.

Changeset: c388455d
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c388455d0a463c9cb52ad18050f1155ec4ac0e6c
Stats:     277 lines in 12 files changed: 7 ins; 237 del; 33 mod

8344197: SM cleanup in java.util.concurrent

Reviewed-by: alanb, dl

-------------

PR: https://git.openjdk.org/jdk/pull/22119

From eirbjo at openjdk.org  Fri Nov 15 20:37:44 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 20:37:44 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <RMKhkWEj51uFUPfXJdkuTGufhHSvhtdzLpc129bacO0=.b3c9a6db-ad22-4fb9-9f79-f257dba230d9@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
 <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
 <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>
 <xa3niIkf416gTYz11PUXGhU83OJAZ3PzLXmQpVkS4zE=.16fff024-e15f-4519-83be-617e0ab72d2c@github.com>
 <HZYh4a7bjotKhpR85cMbf_4VnhAT8rBnJgYkVHwet3c=.3bfb7378-f257-4501-9f7f-ebfb942cf3ce@github.com>
 <RMKhkWEj51uFUPfXJdkuTGufhHSvhtdzLpc129bacO0=.b3c9a6db-ad22-4fb9-9f79-f257dba230d9@github.com>
Message-ID: <2qAIXcZCaQls-gaMu2oAB1AeuyGB8ik2lae1mgXGRRo=.41a2e951-0483-490d-838d-acf2979f8dde@github.com>

On Fri, 15 Nov 2024 17:09:11 GMT, Chen Liang <liach at openjdk.org> wrote:

>> The use of the properties in ClassFileDumper is all in support of debug capabilities and is not sensitive.
>
> Either way is fine.  I think we probably need to review the majority of uses of VM.savedPropoerty as they mostly relate to SM boot circularity.  So we will change this one either now or later.

I would prefer if we could deal with getSavedProperty as a wider area follow up, since that would creep out of scope for this particular PR.

Ok with you, @liach ?

Perhaps @seanjmullan has input on how to deal with VM.getSavedProperty across the code base?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844433544

From mullan at openjdk.org  Fri Nov 15 20:59:55 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 15 Nov 2024 20:59:55 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <2qAIXcZCaQls-gaMu2oAB1AeuyGB8ik2lae1mgXGRRo=.41a2e951-0483-490d-838d-acf2979f8dde@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
 <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
 <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>
 <xa3niIkf416gTYz11PUXGhU83OJAZ3PzLXmQpVkS4zE=.16fff024-e15f-4519-83be-617e0ab72d2c@github.com>
 <HZYh4a7bjotKhpR85cMbf_4VnhAT8rBnJgYkVHwet3c=.3bfb7378-f257-4501-9f7f-ebfb942cf3ce@github.com>
 <RMKhkWEj51uFUPfXJdkuTGufhHSvhtdzLpc129bacO0=.b3c9a6db-ad22-4fb9-9f79-f257dba230d9@github.com>
 <2qAIXcZCaQls-gaMu2oAB1AeuyGB8ik2lae1mgXGRRo=.41a2e951-0483-490d-838d-acf2979f8dde@github.com>
Message-ID: <nzltl-oF378st9HKFqF3tXdys7Hl0Nqjd3_3xCiabB8=.44f9ef5a-b905-49fd-a8e6-984f78c97153@github.com>

On Fri, 15 Nov 2024 20:34:31 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Either way is fine.  I think we probably need to review the majority of uses of VM.savedPropoerty as they mostly relate to SM boot circularity.  So we will change this one either now or later.
>
> I would prefer if we could deal with getSavedProperty as a wider area follow up, since that would creep out of scope for this particular PR.
> 
> Ok with you, @liach ?
> 
> Perhaps @seanjmullan has input on how to deal with VM.getSavedProperty across the code base?

I prefer to minimize code changes for these cleanup issues. We should file a separate issue, "Examine usages of VM.getSavedProperty after JEP 486" or something like that.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844480355

From eirbjo at openjdk.org  Fri Nov 15 21:05:49 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 21:05:49 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <nzltl-oF378st9HKFqF3tXdys7Hl0Nqjd3_3xCiabB8=.44f9ef5a-b905-49fd-a8e6-984f78c97153@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
 <ehLvm5oz5UQQllACpd9h2V2wmUaJztaDF4KpASQaZZI=.567d1fd9-413d-43c4-906f-6742c03cf0e5@github.com>
 <xoBH5KCVa5SXPwFJ_U5NYDu9XTH4z7KAUQAAs1mciYE=.3a017b7b-98ad-463c-b054-9fa3eb626f7c@github.com>
 <WHtHw7XdpngrqfNKNMXXAqTvXWgT24mfUChCZtFLWQo=.6b006ce6-592a-4083-803d-c8ae830add62@github.com>
 <Z8tqtcR_9R8HK14LAIlWY0yysIoZozyPF3rhoOlDzrY=.d53426c0-855b-4c9b-bb3f-780c21a7285d@github.com>
 <xa3niIkf416gTYz11PUXGhU83OJAZ3PzLXmQpVkS4zE=.16fff024-e15f-4519-83be-617e0ab72d2c@github.com>
 <HZYh4a7bjotKhpR85cMbf_4VnhAT8rBnJgYkVHwet3c=.3bfb7378-f257-4501-9f7f-ebfb942cf3ce@github.com>
 <RMKhkWEj51uFUPfXJdkuTGufhHSvhtdzLpc129bacO0=.b3c9a6db-ad22-4fb9-9f79-f257dba230d9@github.com>
 <2qAIXcZCaQls-gaMu2oAB1AeuyGB8ik2lae1mgXGRRo=.41a2e951-0483-490d-838d-acf2979f8dde@github.com>
 <nzltl-oF378st9HKFqF3tXdys7Hl0Nqjd3_
 3xCiabB8=.44f9ef5a-b905-49fd-a8e6-984f78c97153@github.com>
Message-ID: <xq7o8-nrMQvchvz9MXADU2a51m4PU7pW0KjlA9FY6w4=.f8531c92-e127-45a0-9497-d2845e1e75b6@github.com>

On Fri, 15 Nov 2024 20:56:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> I would prefer if we could deal with getSavedProperty as a wider area follow up, since that would creep out of scope for this particular PR.
>> 
>> Ok with you, @liach ?
>> 
>> Perhaps @seanjmullan has input on how to deal with VM.getSavedProperty across the code base?
>
> I prefer to minimize code changes for these cleanup issues. We should file a separate issue, "Examine usages of VM.getSavedProperty after JEP 486" or something like that.

Thanks Sean, I filed https://bugs.openjdk.org/browse/JDK-8344335 to track this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22141#discussion_r1844485351

From eirbjo at openjdk.org  Fri Nov 15 21:09:51 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 21:09:51 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
Message-ID: <REjxVxueZQZAgpb4Z4-BUuxpYukFstizz5A83j526gM=.45ceb789-e11f-4a4e-b719-a9144839095a@github.com>

On Fri, 15 Nov 2024 15:43:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
>> 
>> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
>> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
>> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
>> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
>> 
>> Verification: GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant suppression

Thanks for the reviews and helpful discussions. I'll go ahead and integrate this pending a tier2 run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22141#issuecomment-2479924438

From mullan at openjdk.org  Fri Nov 15 21:29:07 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Fri, 15 Nov 2024 21:29:07 GMT
Subject: RFR: 8329251: Print custom truststore/ keystore name [v11]
In-Reply-To: <w-_vx9k8mompiYC2JYkW1qED5qShwJZdg5kZPutHjfY=.14e98e97-e66f-48c6-8bdd-ef6f07407ca2@github.com>
References: <7T7rmabj_FEYQydHqoWsMfMelTho1lMRE9kJsO-N7gU=.2a7f5d0d-ea54-4729-adc1-e5abd4de0c38@github.com>
 <e9XneE4CQS0xlG3zIFZbOCt6j-gz0kRRUTLh45Pjxbs=.6f4cf332-68e1-4546-a859-435a72669094@github.com>
 <XTQ-TYPeAhQwhk7O73SJY1WycSkshAZgVhrhImCFSaI=.7b10a7ca-42c2-49c7-bd6a-4374e80e90e8@github.com>
 <w-_vx9k8mompiYC2JYkW1qED5qShwJZdg5kZPutHjfY=.14e98e97-e66f-48c6-8bdd-ef6f07407ca2@github.com>
Message-ID: <ikpRpbBTz5TC7KfcmgWsQPC3bQmezd3ydbw_iASm-II=.e159d4ba-e9f9-499c-ab79-0296940e2c43@github.com>

On Thu, 14 Nov 2024 06:28:25 GMT, Prasadrao Koppula <pkoppula at openjdk.org> wrote:

>> src/java.base/share/classes/javax/net/ssl/TrustManagerFactory.java line 283:
>> 
>>> 281:         if (ks != null && SSLLogger.isOn && SSLLogger.isOn("trustmanager")) {
>>> 282:             String keystorePath = SharedSecrets
>>> 283:                     .getJavaSecurityKeyStoreAccess()
>> 
>> This code only works if `java.security.debug=keystore` is also enabled, otherwise it will always return `null`. I think that dependency is not intuitive, and will be hard for users to remember. I think you should change `KeyStore.java` to always cache the filename, whether debug is on or not.
>
> The primary concern is the repeated calls to SharedSecrets to access the inputStream, even though the keystore name is needed in minimal cases ( only when debug enabled) . To optimize, we can cache the filename and access it only when debugging is enabled, reducing unnecessary overhead in the common case.
> 
> I agree that dependency is not intuitive and hard for users to remember.

Perhaps you could cache the `InputStream` instead in `KeyStore`, and only use shared secrets to get the pathname as needed when logging is enabled in the TLS code.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20414#discussion_r1844521411

From bchristi at openjdk.org  Fri Nov 15 21:34:21 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Fri, 15 Nov 2024 21:34:21 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
Message-ID: <mJCxlRB5BP33JI_qBZFLXQmEw5u00EXKHTpPW0Kv1hQ=.15e410bd-881e-4934-99e1-fc18589e9e0f@github.com>

On Fri, 15 Nov 2024 19:30:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   prev is not needed

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 310:

> 308:             }
> 309:             assert phc.node.arr[phc.index] == phc;
> 310:             assert head.size > 0;

I now realize that these assertions in `remove()` won't really "work" because _"exceptions thrown by the cleaning action are ignored"_. :(
When the cleaner thread removes the phc (`ref.clean()` in `run()` on L142 -> `list.remove()` on PhantomCleanable L94 ), any `AssertionError`s will get lost in `run()`'s `catch` statement, L144.

(There is a related RFE [JDK-8305979 : UncaughtExceptionHandler for Cleaner](https://bugs.openjdk.org/browse/JDK-8305979))

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844530605

From eirbjo at openjdk.org  Fri Nov 15 21:41:19 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 21:41:19 GMT
Subject: RFR: 8344336: Remove class System.CallersHolder, leftover from JEP468
Message-ID: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>

Please review this trivial cleanup PR which removes the nested static private class `System.CallersHolder`.

This class was used pre JEP486 to track callers of `System::setSecurityManager` such that warnings were printed only once per caller.

This seems like a leftover from JEP-486 which would be nice to clean up.

-------------

Commit messages:
 - Remove nested static private class System.CallersHolder

Changes: https://git.openjdk.org/jdk/pull/22167/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22167&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344336
  Stats: 7 lines in 1 file changed: 0 ins; 7 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22167.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22167/head:pull/22167

PR: https://git.openjdk.org/jdk/pull/22167

From rriggs at openjdk.org  Fri Nov 15 21:48:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 21:48:54 GMT
Subject: RFR: 8344336: Remove class System.CallersHolder,
 leftover from JEP468
In-Reply-To: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>
References: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>
Message-ID: <BXGAdHgXshcFyP4PyjR3VCCYk9_xcG5djwIN8iC41ts=.c379fa18-a0c1-476b-9a0b-eb36e6d76abf@github.com>

On Fri, 15 Nov 2024 21:36:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this trivial cleanup PR which removes the nested static private class `System.CallersHolder`.
> 
> This class was used pre JEP486 to track callers of `System::setSecurityManager` such that warnings were printed only once per caller.
> 
> This seems like a leftover from JEP-486 which would be nice to clean up.

I'm in the middle of cleanup up the rest of SM removal in java.lang.System, Runtime and that's already removed in the change set.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22167#issuecomment-2479978960

From eirbjo at openjdk.org  Fri Nov 15 21:48:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 21:48:55 GMT
Subject: RFR: 8344336: Remove class System.CallersHolder,
 leftover from JEP468
In-Reply-To: <BXGAdHgXshcFyP4PyjR3VCCYk9_xcG5djwIN8iC41ts=.c379fa18-a0c1-476b-9a0b-eb36e6d76abf@github.com>
References: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>
 <BXGAdHgXshcFyP4PyjR3VCCYk9_xcG5djwIN8iC41ts=.c379fa18-a0c1-476b-9a0b-eb36e6d76abf@github.com>
Message-ID: <yam2Xpz6_mZclS-B_QHrgM_oiuiNdhihv6WqHX4fImI=.07ccaa28-fb32-4aef-856e-feb8884bbf9b@github.com>

On Fri, 15 Nov 2024 21:43:05 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> I'm in the middle of cleanup up the rest of SM removal in java.lang.System, Runtime and that's already removed in the change set.

Thanks Roger, then I'll withdraw this PR. Can you add issue JDK-8344336 as an issue to your PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22167#issuecomment-2479981708

From eirbjo at openjdk.org  Fri Nov 15 21:48:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 21:48:55 GMT
Subject: RFR: 8344336: Remove class System.CallersHolder,
 leftover from JEP468
In-Reply-To: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>
References: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>
Message-ID: <QQ0IynsK_nMx4wfeTDScL0MOyQXf8-SAwUSMKBd1rnI=.8e73c8f4-48fb-439f-8772-8096f2f65ab9@github.com>

On Fri, 15 Nov 2024 21:36:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this trivial cleanup PR which removes the nested static private class `System.CallersHolder`.
> 
> This class was used pre JEP486 to track callers of `System::setSecurityManager` such that warnings were printed only once per caller.
> 
> This seems like a leftover from JEP-486 which would be nice to clean up.

Closing, Roger will take care of this in his PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22167#issuecomment-2479983155

From eirbjo at openjdk.org  Fri Nov 15 21:48:55 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 21:48:55 GMT
Subject: Withdrawn: 8344336: Remove class System.CallersHolder,
 leftover from JEP468
In-Reply-To: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>
References: <meOUBl5YJ4XXaoXQTbL39yZRGGPwLDrohzCOk-Riu7g=.8b58af84-6089-4d57-82cd-d53e0401e3d5@github.com>
Message-ID: <2MXzaCrfAev0LIhBiX9Iw2x9n8jRS_xtzKba4SxRbHA=.d29e2477-aecb-4f9f-9eb1-b6d0359497b0@github.com>

On Fri, 15 Nov 2024 21:36:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this trivial cleanup PR which removes the nested static private class `System.CallersHolder`.
> 
> This class was used pre JEP486 to track callers of `System::setSecurityManager` such that warnings were printed only once per caller.
> 
> This seems like a leftover from JEP-486 which would be nice to clean up.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22167

From rriggs at openjdk.org  Fri Nov 15 22:08:47 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 22:08:47 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <MS4pjQ8rMHtH61o-5v0iM0zSgzdhem0v5ST7YcLIlHc=.4e145f7b-936c-4c6d-ae58-81720b628ea5@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

The `jdk.unsupported` module is not part of the specification.
The JEP and CSR covered the removal of the SM in general.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2480014737

From iklam at openjdk.org  Fri Nov 15 22:22:49 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 15 Nov 2024 22:22:49 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v14]
In-Reply-To: <TKeSI9gfuvj3iZ3wYeoQ7npTzMP8NsxQNgUe77nCc-8=.943e25a1-e8be-4fac-8ac7-c2feeb9e707f@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <TKeSI9gfuvj3iZ3wYeoQ7npTzMP8NsxQNgUe77nCc-8=.943e25a1-e8be-4fac-8ac7-c2feeb9e707f@github.com>
Message-ID: <gqYMn6uTn8msQ8nC4NdNYsvlDGokoEcZpYI3YzAIiLk=.b2aaa0ed-197d-4928-8a55-e2e4a0b76649@github.com>

On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test after security manager removal

Thanks everyone for the review and support!
I ran tiers 1~8 several times in the past few days when merging with mainline. No regressions found.
GHA error is timeout and seems to be unrelated. Integrating now.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21642#issuecomment-2480037673

From rriggs at openjdk.org  Fri Nov 15 22:24:01 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Fri, 15 Nov 2024 22:24:01 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
Message-ID: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>

Removed use of SecurityManager to check permissions.
Relaxed defensive copying of byte arrays (due to lack of SM)

-------------

Commit messages:
 - 8344336: SM cleanup of java.lang.System, Runtime, String, StackWalker

Changes: https://git.openjdk.org/jdk/pull/22168/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22168&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344336
  Stats: 164 lines in 5 files changed: 0 ins; 159 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22168/head:pull/22168

PR: https://git.openjdk.org/jdk/pull/22168

From iklam at openjdk.org  Fri Nov 15 22:31:55 2024
From: iklam at openjdk.org (Ioi Lam)
Date: Fri, 15 Nov 2024 22:31:55 GMT
Subject: Integrated: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking
In-Reply-To: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
Message-ID: <4xos88WJsJcF3QMs1xI1sEacUTohEe70qrJZQHEczXY=.05b9a85a-2a2e-40bc-aeac-fb682fff88ff@github.com>

On Tue, 22 Oct 2024 16:19:48 GMT, Ioi Lam <iklam at openjdk.org> wrote:

> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
> 
> ----
> Note: this is a combined PR of the following individual PRs
> - https://github.com/openjdk/jdk/pull/20516
> - https://github.com/openjdk/jdk/pull/20517
> - https://github.com/openjdk/jdk/pull/20843
> - https://github.com/openjdk/jdk/pull/20958
> - https://github.com/openjdk/jdk/pull/20959
> - https://github.com/openjdk/jdk/pull/21049
> - https://github.com/openjdk/jdk/pull/21143

This pull request has now been integrated.

Changeset: 41a2d49f
Author:    Ioi Lam <iklam at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41a2d49f0a1ed298b8ab023ce634335464454fe7
Stats:     7188 lines in 107 files changed: 6354 ins; 513 del; 321 mod

8331497: Implement JEP 483: Ahead-of-Time Class Loading & Linking

Reviewed-by: jrose, kvn, heidinga, asmehra, vlivanov

-------------

PR: https://git.openjdk.org/jdk/pull/21642

From eirbjo at openjdk.org  Fri Nov 15 22:51:28 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 22:51:28 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
Message-ID: <S4Volj3cwQpFfR8lpER2ZLXY8VeeNdeizuZ3GGzao8c=.0af11192-207c-475b-8e75-432d4c7b1ad1@github.com>

On Fri, 15 Nov 2024 22:11:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)

src/java.base/share/classes/java/lang/String.java line 843:

> 841: 
> 842:     // Trim the given byte array to the given length
> 843:     private static byte[] safeTrim(byte[] ba, int len) {

"safe" no longer carries meaning, this could just be "trim", "trimBuffer" or "trimArray"

src/java.base/share/classes/java/lang/System.java line 1336:

> 1334:         }
> 1335: 
> 1336:         private static Void checkPermission() {

Seems unused?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22168#discussion_r1844623522
PR Review Comment: https://git.openjdk.org/jdk/pull/22168#discussion_r1844626212

From eirbjo at openjdk.org  Fri Nov 15 22:55:40 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Fri, 15 Nov 2024 22:55:40 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
Message-ID: <htg7OdIk35ZZe3o8YlWC0695odS_647B8fuiACNnIKI=.37523fe1-1837-4274-954a-00cd33220918@github.com>

On Fri, 15 Nov 2024 22:11:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)

src/java.base/share/classes/java/lang/LiveStackFrame.java line 1:

> 1: /*

Seems you removed "@throws SecurityException" for the `getStackWalker` override actually throwing, but not for the delegating `getStackWalker` overrides?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22168#discussion_r1844642792

From bpb at openjdk.org  Fri Nov 15 23:15:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Fri, 15 Nov 2024 23:15:53 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <u7ix4dvk3Q-rCODNCtmONmzuVdK36IqG1ITYCTLxBkY=.743d5508-52f9-4d92-a724-7c578e6bb2ce@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Updated version looks fine.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439914323

From almatvee at openjdk.org  Fri Nov 15 23:31:49 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Nov 2024 23:31:49 GMT
Subject: RFR: 8344326: Move jpackage tests from "jdk.jpackage.tests"
 package to the default package
In-Reply-To: <oyk1kQHiajPvi6YrzTcvC9VbtnswHRsg26VNp-5e9Vk=.4bb08a1b-bba3-4b22-a896-4975586983a9@github.com>
References: <oyk1kQHiajPvi6YrzTcvC9VbtnswHRsg26VNp-5e9Vk=.4bb08a1b-bba3-4b22-a896-4975586983a9@github.com>
Message-ID: <8-OxwfB9T7N8BJRFw6QNRZmESxaZPkPPWonbRqFZCK0=.bc90575e-add8-42a6-b085-f2e23ad597a2@github.com>

On Fri, 15 Nov 2024 18:18:08 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move jpackage tests from "jdk.jpackage.tests" package to the default package.
> 
> Remove `WindowsHelper.getTempDirectory()`. It is faulty and found limited use. Updated dependent tests accordingly.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22156#pullrequestreview-2439924552

From jlu at openjdk.org  Fri Nov 15 23:33:05 2024
From: jlu at openjdk.org (Justin Lu)
Date: Fri, 15 Nov 2024 23:33:05 GMT
Subject: RFR: 8344331: SM cleanup in java.scripting
Message-ID: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>

Please review this PR which removes the lone `AccessController.doPrivileged` call from the _java.scripting_ module after JEP486 integration.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/22170/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22170&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344331
  Stats: 5 lines in 1 file changed: 0 ins; 3 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22170/head:pull/22170

PR: https://git.openjdk.org/jdk/pull/22170

From liach at openjdk.org  Fri Nov 15 23:47:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 23:47:55 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
Message-ID: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>

When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.

I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.

Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.

Testing: tier 1-5 green

-------------

Commit messages:
 - Better comments
 - 8343377: Performance regression in reflective invocation of native methods

Changes: https://git.openjdk.org/jdk/pull/22169/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22169&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343377
  Stats: 72 lines in 4 files changed: 52 ins; 7 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/22169.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22169/head:pull/22169

PR: https://git.openjdk.org/jdk/pull/22169

From liach at openjdk.org  Fri Nov 15 23:50:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Fri, 15 Nov 2024 23:50:45 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <zYCgPkYPVOW7bNl82mHjIYp8Y6lQlPZHaTS4UJX6qFY=.95fc5df6-7dd7-4e82-b71b-0d467b21ce15@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

Thanks.  I think these are all to clean up in ReflectionFactory.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22158#pullrequestreview-2439941246

From dlong at openjdk.org  Fri Nov 15 23:51:52 2024
From: dlong at openjdk.org (Dean Long)
Date: Fri, 15 Nov 2024 23:51:52 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long [v2]
In-Reply-To: <lVgbXe_xisP3D9sUnuV0S8l5qxOtjSyMn-vXm8dVllQ=.6535703b-00ba-4f66-b31a-ca960ead09e1@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <lVgbXe_xisP3D9sUnuV0S8l5qxOtjSyMn-vXm8dVllQ=.6535703b-00ba-4f66-b31a-ca960ead09e1@github.com>
Message-ID: <8ULnPzI_27Ji0Yun4IcYfkhEV8dXt4atCVMn4-FTLGE=.56704c3f-50e2-46a7-ae6a-1a00d2896194@github.com>

On Fri, 15 Nov 2024 01:04:58 GMT, Shaojin Wen <swen at openjdk.org> wrote:

>> The type of the Unsafe base offset constant is int, which may cause overflow when adding int offsets, such as 8343925 (PR #22012). 8343984 (PR #22027) fixes most of the offset overflows in JDK, but ArraysSupport and CRC32C are still unfixed.
>> 
>> @liach proposed the idea of ??changing the Unsafe base offset to long, which is a complete solution to the Unsafe offset overflow. After discussing with @liach, I submitted this PR to implement @liach's idea.
>
> Shaojin Wen has updated the pull request incrementally with one additional commit since the last revision:
> 
>   long BaseAndScale base, from @JornVernee

@ExE-Boss , are you saying the CSR doesn't apply to jdk.internal.*?  The CSR FAQ says:
"Changes to public and exported APIs in jdk.*packages."
Whether or not it needs a CSR, I think there are apps outside the JDK that will break because of this change.

-------------

Changes requested by dlong (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22095#pullrequestreview-2439944157

From almatvee at openjdk.org  Fri Nov 15 23:54:55 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Fri, 15 Nov 2024 23:54:55 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v5]
In-Reply-To: <CxPOY5_P4aB0Q3XudbaOqo3t--4t9XKs4T-bTJULWIg=.93c7f356-56ff-4f62-81e5-006d372302b5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
 <gdoBisZwMJSV1NJ7EHqc4i6ZRmx0pbXrB2XuvGkkibM=.a36c4447-f04c-4fec-955d-0926dab61f72@github.com>
 <CxPOY5_P4aB0Q3XudbaOqo3t--4t9XKs4T-bTJULWIg=.93c7f356-56ff-4f62-81e5-006d372302b5@github.com>
Message-ID: <ZX-i1LZz8UJtNogvVkBq3fMG9299cKvMgv48HAv_GKw=.c9c29da5-4d1a-4337-8740-556c84951fc0@github.com>

On Fri, 15 Nov 2024 14:53:18 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/TestMethodSupplier.java line 142:
>> 
>>> 140:                 throw ex;
>>> 141:             }
>>> 142:         }
>> 
>> Maybe move this code into `switch` statement under `default`? Also, should we use `TypeStatus.UNKNOWN` instead of `null`?
>
>> Maybe move this code into switch statement under default?
> 
> Can't use "null" in the switch.
> 
>> should we use TypeStatus.UNKNOWN instead of null?
> 
> To deal with `TypeStatus.UNKNOWN` and `null`? Besides of that what is the semantics of `TypeStatus.UNKNOWN`? 
> 
> - `TypeStatus.NOT_TEST_CLASS` is for types that are NOT test classes.
> - `TypeStatus.VALID_TEST_CLASS` is for types that are valid test classes.
> - `TypeStatus.TEST_CLASS` is for all other types, i.e. invalid test classes.
> 
> How does `TypeStatus.UNKNOWN` fit?

Never mind. I see why it is `null`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21996#discussion_r1844684516

From naoto at openjdk.org  Fri Nov 15 23:57:01 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Fri, 15 Nov 2024 23:57:01 GMT
Subject: RFR: 8344331: SM cleanup in java.scripting
In-Reply-To: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
References: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
Message-ID: <tUjYw7SMDhM8U69Or5nbipudE-slQABEqrfRuS5SBng=.f2ee7d07-5d27-418a-830f-2d5761f0c7ac@github.com>

On Fri, 15 Nov 2024 23:23:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the lone `AccessController.doPrivileged` call from the _java.scripting_ module after JEP486 integration.

Marked as reviewed by naoto (Reviewer).

src/java.scripting/share/classes/javax/script/ScriptEngineManager.java line 89:

> 87:         Iterator<ScriptEngineFactory> itr;
> 88:         try {
> 89:             var sl = getServiceLoader(loader);

Fine as it stands, but this var `sl` is no longer needed.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22170#pullrequestreview-2439959722
PR Review Comment: https://git.openjdk.org/jdk/pull/22170#discussion_r1844689213

From asemenyuk at openjdk.org  Fri Nov 15 23:58:48 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Fri, 15 Nov 2024 23:58:48 GMT
Subject: Integrated: 8344326: Move jpackage tests from "jdk.jpackage.tests"
 package to the default package
In-Reply-To: <oyk1kQHiajPvi6YrzTcvC9VbtnswHRsg26VNp-5e9Vk=.4bb08a1b-bba3-4b22-a896-4975586983a9@github.com>
References: <oyk1kQHiajPvi6YrzTcvC9VbtnswHRsg26VNp-5e9Vk=.4bb08a1b-bba3-4b22-a896-4975586983a9@github.com>
Message-ID: <1zrSsH5Zj-vI23036azPyV3LyYtu0wSriBXFwSEDJKA=.b8261862-88c9-4b72-8fad-8a06e1285dd9@github.com>

On Fri, 15 Nov 2024 18:18:08 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move jpackage tests from "jdk.jpackage.tests" package to the default package.
> 
> Remove `WindowsHelper.getTempDirectory()`. It is faulty and found limited use. Updated dependent tests accordingly.

This pull request has now been integrated.

Changeset: 2c509a15
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/2c509a158fad63e69a8072fa4a7588eaacf37dc0
Stats:     81 lines in 21 files changed: 1 ins; 44 del; 36 mod

8344326: Move jpackage tests from "jdk.jpackage.tests" package to the default package

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/22156

From jlu at openjdk.org  Sat Nov 16 00:03:23 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 16 Nov 2024 00:03:23 GMT
Subject: RFR: 8344331: SM cleanup in java.scripting [v2]
In-Reply-To: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
References: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
Message-ID: <O_tPgxSmIrPoewlOGjPkDH2qPUhXtc2GSXMLARR3mTw=.a88a42f7-2530-4696-af8a-f3bc9c7bd866@github.com>

> Please review this PR which removes the lone `AccessController.doPrivileged` call from the _java.scripting_ module after JEP486 integration.

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  remove local var 'sl'

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22170/files
  - new: https://git.openjdk.org/jdk/pull/22170/files/ca97d16b..abb39ab3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22170&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22170&range=00-01

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22170.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22170/head:pull/22170

PR: https://git.openjdk.org/jdk/pull/22170

From almatvee at openjdk.org  Sat Nov 16 00:03:50 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Sat, 16 Nov 2024 00:03:50 GMT
Subject: RFR: 8343876: Enhancements to jpackage test lib [v5]
In-Reply-To: <42J3-uE8ZhwfJNPByBMPA-zKoD-1xqNsL1xtA-XpKmE=.7c40a6ff-6b26-44c0-b841-f6dbc825277a@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
 <42J3-uE8ZhwfJNPByBMPA-zKoD-1xqNsL1xtA-XpKmE=.7c40a6ff-6b26-44c0-b841-f6dbc825277a@github.com>
Message-ID: <81q7Pia8XXyiF0xhtVOHEAv2yM2OnC6sIXor0qypV5M=.3af4b0ea-e6f3-4916-885f-398922a2e1f9@github.com>

On Fri, 15 Nov 2024 18:34:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Make jpackage test lib more practical. List of changes:
>> 
>> Support multiple args and var args in `@Parameter` annotation:
>> 
>> @Test
>> @Parameter({"12", "foo"})
>> @Parameter({"-89", "bar", "more"})
>> @Parameter({"-89", "bar", "more", "moore"})
>> public void testVarArg(int a, String b, String ... other) {}
>> 
>> 
>> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
>> 
>> class FooTest {
>>     public FooTest(String... args) {}
>>     public FooTest(int o) {}
>>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
>> 
>>     @Parameters
>>     public static Collection<Object[]> input() {
>>         return List.of(new Object[][] {
>>             {},
>>             {"str"},
>>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>>         });
>>     }
>> 
>>     @Parameters
>>     public static Collection<Object[]> input2() {
>>         return List.of(new Object[][] {
>>             {78},
>>             {34, null, null},
>>         });
>>     }
>> }
>> 
>> 
>> Static test method will be executed only once and not as many times as the number of the test class instances.
>> 
>> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
>> 
>> 
>> class FooTest {
>>     @Test
>>     @ParameterSupplier("dateSupplier")
>>     @ParameterSupplier("AnotherClass.dateSupplier")
>>     public void testDates(LocalDate v) {}
>> 
>>     public static Collection<Object[]> dateSupplier() {
>>         return List.of(new Object[][] {
>>             { LocalDate.parse("2018-05-05") },
>>             { LocalDate.parse("2018-07-11") },
>>         });
>>     }
>> }
>> 
>> class AnotherClass {
>>     public static Collection<Object[]> dateSupplier() {
>>         return List.of(new Object[][] {
>>             { LocalDate.parse("2028-07-11") },
>>         });
>>     }
>> }
>> 
>> 
>> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
>> 
>> 
>> @Test(ifOS = OperatingSystem.LINUX)
>> public void testRunIfLinux() {}
>> 
>> @Test(ifNotOS = OperatingSystem.LINUX)
>> public void testRunIfNotLinux() {}
>> 
>> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
>> public void testRunIfNotLinuxOrMacOS() {}
>> 
>> @Test
>> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
>> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LI...
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove JDK-8344322-specific changes

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21996#pullrequestreview-2439982429

From lancea at openjdk.org  Sat Nov 16 00:06:42 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 16 Nov 2024 00:06:42 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <fti-qykjyUPhLPAHCtflVlp5R8-ohdNwamRgOcicmkU=.0ba22560-082d-43a8-b83a-b1a6ac0aecf7@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2439986238

From naoto at openjdk.org  Sat Nov 16 00:11:46 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Sat, 16 Nov 2024 00:11:46 GMT
Subject: RFR: 8344331: SM cleanup in java.scripting [v2]
In-Reply-To: <O_tPgxSmIrPoewlOGjPkDH2qPUhXtc2GSXMLARR3mTw=.a88a42f7-2530-4696-af8a-f3bc9c7bd866@github.com>
References: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
 <O_tPgxSmIrPoewlOGjPkDH2qPUhXtc2GSXMLARR3mTw=.a88a42f7-2530-4696-af8a-f3bc9c7bd866@github.com>
Message-ID: <nfedNOkUaOVpmYuYCyv_CC548_FnM0ttcYove3nYSuk=.5953f10e-5e0b-4365-bb50-3bc29ec1f3c5@github.com>

On Sat, 16 Nov 2024 00:03:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes the lone `AccessController.doPrivileged` call from the _java.scripting_ module after JEP486 integration.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove local var 'sl'

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22170#pullrequestreview-2439994058

From lancea at openjdk.org  Sat Nov 16 00:18:41 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Sat, 16 Nov 2024 00:18:41 GMT
Subject: RFR: 8344331: SM cleanup in java.scripting [v2]
In-Reply-To: <O_tPgxSmIrPoewlOGjPkDH2qPUhXtc2GSXMLARR3mTw=.a88a42f7-2530-4696-af8a-f3bc9c7bd866@github.com>
References: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
 <O_tPgxSmIrPoewlOGjPkDH2qPUhXtc2GSXMLARR3mTw=.a88a42f7-2530-4696-af8a-f3bc9c7bd866@github.com>
Message-ID: <qWqlV7rY3ceoxMqcQ6DAVMyJpM8i1jG0J2jCaDebcr0=.9a02db85-52fa-4c86-b66f-9ed785ad1a09@github.com>

On Sat, 16 Nov 2024 00:03:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes the lone `AccessController.doPrivileged` call from the _java.scripting_ module after JEP486 integration.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove local var 'sl'

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22170#pullrequestreview-2439997134

From bpb at openjdk.org  Sat Nov 16 00:22:44 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Sat, 16 Nov 2024 00:22:44 GMT
Subject: RFR: 8069345: (fs) FileTreeWalker throws NotDirectoryException on
 file junction points [v2]
In-Reply-To: <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
References: <uNXouUncTzFjEcYvZUO-B7PXaBH1IKR74i8gt9_HQVU=.0bb4d7fc-cc06-4fe4-ad92-4fc8eb25367b@github.com>
 <9go8VaL2YIMi8BuOTiVKaGMK_Uq0pnjNU1jLt1OTT1I=.c53669ab-8d1d-483a-a3e3-88f49fde13f6@github.com>
Message-ID: <AbO3igd_qHtGwU8fRIcZPitY8cvItbMX4ZdA5Edg-BE=.2fa9c25f-2b86-44dc-b38b-869c79f60169@github.com>

On Thu, 17 Oct 2024 01:37:01 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Improve support for Windows directory junctions.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8069345: Add os.family == windows to tests

continue;

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21555#issuecomment-2480197204

From jlu at openjdk.org  Sat Nov 16 01:05:41 2024
From: jlu at openjdk.org (Justin Lu)
Date: Sat, 16 Nov 2024 01:05:41 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <k1lmU1CEpzVUOACEOjyLTdIAEosMQ7iquvYwnPH2r8Y=.91b8d6e9-49c8-4108-8387-9188beda51ab@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Marked as reviewed by jlu (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2440013905

From alanb at openjdk.org  Sat Nov 16 07:57:47 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 07:57:47 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <S4Volj3cwQpFfR8lpER2ZLXY8VeeNdeizuZ3GGzao8c=.0af11192-207c-475b-8e75-432d4c7b1ad1@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
 <S4Volj3cwQpFfR8lpER2ZLXY8VeeNdeizuZ3GGzao8c=.0af11192-207c-475b-8e75-432d4c7b1ad1@github.com>
Message-ID: <uZJKZ7CaxQXdsQNAbVk0fpHBnEpzRlAFgZCqIyQHUeU=.49791433-0e78-411e-bde0-0b9c5d141110@github.com>

On Fri, 15 Nov 2024 22:41:22 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>
> src/java.base/share/classes/java/lang/String.java line 843:
> 
>> 841: 
>> 842:     // Trim the given byte array to the given length
>> 843:     private static byte[] safeTrim(byte[] ba, int len) {
> 
> "safe" no longer carries meaning, this could just be "trim", "trimBuffer" or "trimArray"

Right, in other previously prepared changes, this was renamed to trim.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22168#discussion_r1844932173

From alanb at openjdk.org  Sat Nov 16 08:01:45 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 08:01:45 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <NKoM3ajrgBzyZBLzSOOZmRfUTTezSj4As-AaAjhvKQg=.4d2f3dec-f0cd-48b1-b2d6-d214ba32aca7@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

The CSR for JEP 486 included all the API changes for the supported APIs. With this PR we are in grey area of "critical internal APIs" that are undocumented. We have been doing CSRs whenever we remove these anything from jdk.unsupported, and more recently, the stop-gap work for serialization is adding methods that will be tracked by the CSR. I'm sure the CSR will approve this quickly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2480470294

From alanb at openjdk.org  Sat Nov 16 08:16:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 08:16:48 GMT
Subject: RFR: 8344197: SM cleanup in java.util.concurrent [v3]
In-Reply-To: <1ibykaUy5b2H2UMbAHun_IZuUFJFpSSdrncmblFwCgY=.f46f9de3-ca32-4a78-ba0a-b17295ae9b5f@github.com>
References: <oJusXlr6mH-MectsXEhCA5Q-teIsQXScuhP71akhxyg=.a8dbb056-3afa-4c9f-9d78-ddcb9d0d595c@github.com>
 <ADOzCbRb5rNwKGgcXn29_Q6FI8rCahFAYe0tSVN1uPM=.83f86e9c-f006-44cf-89cd-53557fc88ceb@github.com>
 <1ibykaUy5b2H2UMbAHun_IZuUFJFpSSdrncmblFwCgY=.f46f9de3-ca32-4a78-ba0a-b17295ae9b5f@github.com>
Message-ID: <7IYt7seMP5Qaamv0JFnmWiypZ8mlZAV9PxHoUzuAW7U=.5909f705-3be6-4f77-ac17-d56968f59813@github.com>

On Fri, 15 Nov 2024 20:10:45 GMT, Doug Lea <dl at openjdk.org> wrote:

> A side question: Are there now any situations in which Thread.interrupt can throw an exception? If not, a few more things in j.u.c and elsewhere could be simplified someday.

It's possible to extend Thread and override interrupt so in theory it might run anything. Even if not overridden it may have to execute quite a bit of code because of hooks for interruptible channels or interrupting a virtual thread will need to queue the task for the thread. The latter is hardened for cases like OOME but maybe not SOE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22119#issuecomment-2480474661

From alanb at openjdk.org  Sat Nov 16 08:42:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 08:42:53 GMT
Subject: RFR: 8344168: Change Unsafe base offset from int to long
In-Reply-To: <W8_iwDOrq_gtb_bWOpLZT-BEFzT5s6OGvHinzh07y0Y=.fdf1ecd4-8f17-47c2-8083-a1c8be25ed13@github.com>
References: <JwymnZU78RM-dJ843fUrRtNHNDSZwTy5DbruQdlgVlE=.c7b32044-dc77-4226-a5bd-7183db75ffe8@github.com>
 <gs8Jaubur5FzfHn5bi0wvbLh-XQNnzp3gyrXuZp9_hs=.3dbb94ee-0793-4d4b-8a7f-2ad8da268936@github.com>
 <W8_iwDOrq_gtb_bWOpLZT-BEFzT5s6OGvHinzh07y0Y=.fdf1ecd4-8f17-47c2-8083-a1c8be25ed13@github.com>
Message-ID: <pwvWFxQx_FN0Gm7pXKycZQiQNh4RTofb8XkACFHS27s=.bc86878f-4ae9-4708-bf75-e91abacf22f3@github.com>

On Fri, 15 Nov 2024 01:05:10 GMT, ExE Boss <duke at openjdk.org> wrote:

>> Doesn't this break any apps that use these offsets?  Aren't these fields part of the public API of Unsafe, so changing them requires a CSR?
>
> @dean-long
>> Doesn't this break any apps that use these offsets? Aren't these fields part of the public API of Unsafe, so changing them requires a CSR?
> 
> This?is the?encapsulated JDK?internal `Unsafe` in?`java.base`, not?the?legacy `sun.misc.Unsafe`.

> @ExE-Boss , are you saying the CSR doesn't apply to jdk.internal.*? The CSR FAQ says: "Changes to public and exported APIs in jdk.*packages." Whether or not it needs a CSR, I think there are apps outside the JDK that will break because of this change.

jdk.internal.** is JDK internal, none of these packages are exported. It's okay to make changes in any release, any builds. Nothing outside of the JDK should be depending on internal APIs like this.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22095#issuecomment-2480480585

From alanb at openjdk.org  Sat Nov 16 10:08:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Sat, 16 Nov 2024 10:08:16 GMT
Subject: RFR: 8344034: Remove security manager dependency in Serialization
 [v9]
In-Reply-To: <2L6AgFqUJgAKu8fmdDR2yiPaf3D3ijiEAYQ2H8_X7aE=.6c4011d3-1038-49ad-ba2f-6c4be612755b@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
 <2L6AgFqUJgAKu8fmdDR2yiPaf3D3ijiEAYQ2H8_X7aE=.6c4011d3-1038-49ad-ba2f-6c4be612755b@github.com>
Message-ID: <9Djm37Xj90aa574W9aDF4315DsaVuiIyQNQSxXgn16g=.7657c367-231a-416d-9f87-1ac0cb0ecd17@github.com>

On Thu, 14 Nov 2024 17:19:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
>> Some refactoring to cleanup the remaining code is expected.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Wrap more long lines

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22041#pullrequestreview-2440341710

From dholmes at openjdk.org  Sat Nov 16 12:24:42 2024
From: dholmes at openjdk.org (David Holmes)
Date: Sat, 16 Nov 2024 12:24:42 GMT
Subject: RFR: 8344191: Build code should not have classpath exception
In-Reply-To: <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com>
References: <U0XAHfEgxgfvcpBaj8aOZgQgk0cU-GyAMyeJ9cyJrUA=.84aeedaa-ef83-48e9-9eea-1de1e8d0afd6@github.com>
 <M9HkddCRkOHWT_JM7FBHAO4iFklBcnSdRrMwFYStuv0=.5cc2c74b-c7ec-4d2a-981d-93e1f5c4500a@github.com>
 <_ewi33QvJz3HiyEkrJ64eWTUOl52LKXiMkWF4SUfxgM=.33f058b7-f21f-4259-abd2-0cb7e7a2da1a@github.com>
Message-ID: <yBnJF8M2Mq6PH2pwEFI1aHQZcOvjPAubcXJJUBfFtMg=.1c674802-e31e-4f50-9d28-b05b31697604@github.com>

On Fri, 15 Nov 2024 00:07:07 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> The policy has long been to use Classpath Exception in the `src` and `make` directories, but not in the `test` directories. If you're changing the policy, you might want to check and update any documentation where the policy might be written down.

What policy is that? The Classpath exception is for executing classfiles. It is meaningless in any other context.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22104#issuecomment-2480542305

From eirbjo at openjdk.org  Sat Nov 16 13:33:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 16 Nov 2024 13:33:53 GMT
Subject: RFR: 8344289: SM cleanup in jdk.internal.util [v2]
In-Reply-To: <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
 <NPfMQWbhnszqBApgY6tHCsvsxRRKY28lqWUwebMIbMc=.d39e9c10-5795-49b4-ab5f-c94e3e6569f5@github.com>
Message-ID: <gPhI3ryZL7A45cz75BS1Jj5Li7pIWmBG2neVkd8XQ28=.0291c67c-0177-469c-a30f-896a194a9dab@github.com>

On Fri, 15 Nov 2024 15:43:08 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
>> 
>> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
>> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
>> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
>> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
>> 
>> Verification: GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove redundant suppression

tier2 run completed with only `VerifyJimage.java` failing. (This fails for some reason on all tier2 runs in my local MacOS build environment).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22141#issuecomment-2480561454

From eirbjo at openjdk.org  Sat Nov 16 13:33:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sat, 16 Nov 2024 13:33:54 GMT
Subject: Integrated: 8344289: SM cleanup in jdk.internal.util
In-Reply-To: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
References: <Ivsxf8cdLnfnrnJT2TGqFP3kEcRvc2dIvB0_XEbi4A0=.01d79b15-4b33-482a-8f81-e528c20b729d@github.com>
Message-ID: <TmezzXj2nRPdySPKcg6y_yg3uUcmISR3f5xlBrC6Wjw=.c5b52f91-06aa-4a9d-9788-b223b983e88a@github.com>

On Fri, 15 Nov 2024 09:35:17 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR to clean up `RandomSupport`, `ClassFileDumper` and `StaticProperty` in the `jdk.internal.util` namespace:
> 
> * `RandomSupport` is updated to replace an `AccessController::doPrivileged` call with `Boolean::getBoolean`. (Existing code uses `String::equalsIgnoreCase`, equivalent to `Boolean::getBoolean`)
> * `ClassFileDumper` constructor is updated to remove a comment referencing `GetPropertyAction`. (I left the `VM::getSavedProperty` call as-is, please advise if this should be replaced with `System::getProperty)
> * `ClassFileDumper::write` is updated to unwrap a `AccessController::doPrivileged` call
> * `StaticProperty` is updated to remove `SecurityManager::checkPropertyAccess` references in the documentation
> 
> Verification: GHA results pending.

This pull request has now been integrated.

Changeset: d0b770c9
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d0b770c938be6b5b3a0176148265ef33184a9b8b
Stats:     118 lines in 3 files changed: 6 ins; 91 del; 21 mod

8344289: SM cleanup in jdk.internal.util

Reviewed-by: liach, rriggs, bpb

-------------

PR: https://git.openjdk.org/jdk/pull/22141

From dl at openjdk.org  Sat Nov 16 13:51:43 2024
From: dl at openjdk.org (Doug Lea)
Date: Sat, 16 Nov 2024 13:51:43 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v28]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <6kEOigAiHuRMVbT8aV0rMMiDOEnyuwDATohFewX4vAM=.d82f2a70-c0c2-4fdd-87b2-d45851837290@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 49 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Rename variable
 - Merge branch 'openjdk:master' into JDK-8336707
 - Improve readbility; tweak runState checks
 - Address review comments
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Reconcile internal docs; renamings
 - ... and 39 more: https://git.openjdk.org/jdk/compare/b2cc1d00...a32e818d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/cb179dda..a32e818d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=27
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=26-27

  Stats: 21547 lines in 744 files changed: 11045 ins; 7517 del; 2985 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From rriggs at openjdk.org  Sat Nov 16 14:27:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Sat, 16 Nov 2024 14:27:04 GMT
Subject: RFR: 8344319: SM cleanup in jdk.dynlink module
Message-ID: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>

Refactor to remove use of SecurityManager

-------------

Commit messages:
 - 8344319: SM cleanup in jdk.dynlink module

Changes: https://git.openjdk.org/jdk/pull/22152/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22152&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344319
  Stats: 237 lines in 13 files changed: 0 ins; 206 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/22152.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22152/head:pull/22152

PR: https://git.openjdk.org/jdk/pull/22152

From jpai at openjdk.org  Sat Nov 16 14:27:04 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Sat, 16 Nov 2024 14:27:04 GMT
Subject: RFR: 8344319: SM cleanup in jdk.dynlink module
In-Reply-To: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
References: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
Message-ID: <mQA_XYK6AHYdI3HvFAnWZLiR8S4NSejw3wpRK3szGM0=.559dbedc-5145-4600-b458-73b77db5f96b@github.com>

On Fri, 15 Nov 2024 16:38:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor to remove use of SecurityManager

Hello Roger, there's a typo in the JBS title (and thus this PR title too). The module name should have been `jdk.dynalink`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22152#issuecomment-2480592736

From attila at openjdk.org  Sat Nov 16 16:00:44 2024
From: attila at openjdk.org (Attila Szegedi)
Date: Sat, 16 Nov 2024 16:00:44 GMT
Subject: RFR: 8344319: SM cleanup in jdk.dynlink module
In-Reply-To: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
References: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
Message-ID: <lNYFBGkoInEWGNJboEldmaL2DPTGK2xlNp6onJkfRA8=.f0b1385b-bb66-4147-bf15-e6dffe6f7334@github.com>

On Fri, 15 Nov 2024 16:38:53 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Refactor to remove use of SecurityManager

Hey Roger, thanks for doing this no doubt unglamorous maintenance task. I reviewed it, and it mostly looks good, there's few things I thought about maybe taking a step further (and one thing I'd prefer was taken a step back ?)

src/jdk.dynalink/share/classes/jdk/dynalink/DynamicLinkerFactory.java line 462:

> 460: 
> 461:     private static ClassLoader getThreadContextClassLoader() {
> 462:         return Thread.currentThread().getContextClassLoader();

This could get inlined. It's only invoked from a single location, and the sole purpose of it was to evaluate the expression in doPrivileged.

src/jdk.dynalink/share/classes/jdk/dynalink/SecureLookupSupplier.java line 46:

> 44:      * {@link #getLookup()} method.
> 45:      */
> 46:     public static final String GET_LOOKUP_PERMISSION_NAME = "dynalink.getLookup";

This public member is [referenced from Nashorn](https://github.com/search?q=repo%3Aopenjdk%2Fnashorn%20GET_LOOKUP_PERMISSION_NAME&type=code). If we remove it, Nashorn will have to attempt to look it up reflectively as long as it supports older versions of Java. (Presuming the `java.security.AccessController` and related classes aren't also removed altogether. Are they?)

FWIW, as long as we're making breaking changes, this whole class could be removed ? all it did was serve as a secure gate to access to a `MethodHandles.Lookup`. References to it could be replaced by the lookup object itself. I can understand if this might be too much work for this PR, though.

On the other hand, if we do _not_ remove the whole class, I'd prefer to keep the public string constant for the permission name so that we don't break binary compatibility for whoever might be referencing it (specifically, Nashorn.)

src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingDynamicLinkerExporter.java line 53:

> 51:      * anymore as the Security Manager is no longer supported.
> 52:      */
> 53:     public static final String AUTOLOAD_PERMISSION_NAME = "dynalink.exportLinkersAutomatically";

This at least is not used externally, it seems so I guess we can remove it no strings attached.

src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingDynamicLinkerExporter.java line 65:

> 63:         if (sm != null) {
> 64:             sm.checkPermission(AUTOLOAD_PERMISSION);
> 65:         }

We can probably remove the whole empty default constructor now. The class is abstract, the autogenerated default constructor will be protected anyway.

src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingTypeConverterFactory.java line 121:

> 119:      * method on the passed supplier will be subject to the same security checks
> 120:      * as {@link SecureLookupSupplier#getLookup()}. An implementation should avoid
> 121:      * retrieving the lookup if it is not needed.

This whole passage starting with "Invoking the?" and ending with "? is not needed" should be removed now.

-------------

Changes requested by attila (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22152#pullrequestreview-2440557095
PR Review Comment: https://git.openjdk.org/jdk/pull/22152#discussion_r1844995516
PR Review Comment: https://git.openjdk.org/jdk/pull/22152#discussion_r1844997321
PR Review Comment: https://git.openjdk.org/jdk/pull/22152#discussion_r1845001347
PR Review Comment: https://git.openjdk.org/jdk/pull/22152#discussion_r1845003011
PR Review Comment: https://git.openjdk.org/jdk/pull/22152#discussion_r1845009155

From kdnilsen at openjdk.org  Sat Nov 16 18:04:44 2024
From: kdnilsen at openjdk.org (Kelvin Nilsen)
Date: Sat, 16 Nov 2024 18:04:44 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
Message-ID: <moaOE0Z-TY_WqtG7hu1HrVfWVQFc6LnRv0vGvcORy1Q=.626ce099-6451-41df-80c8-3d3da479b36d@github.com>

On Fri, 15 Nov 2024 19:30:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   prev is not needed

Thanks for all your work on this.

-------------

Marked as reviewed by kdnilsen (Author).

PR Review: https://git.openjdk.org/jdk/pull/22043#pullrequestreview-2440781306

From liach at openjdk.org  Sat Nov 16 18:14:53 2024
From: liach at openjdk.org (Chen Liang)
Date: Sat, 16 Nov 2024 18:14:53 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
Message-ID: <wTIRY1w8dzaW27_TTpa6PoT0sr_dgYPu6k8W11e-4-c=.bafac258-210b-4565-9da2-15badc676b4a@github.com>

On Fri, 15 Nov 2024 19:30:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   prev is not needed

test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 30:

> 28:  * @compile/module=java.base jdk/internal/ref/CleanableListTestHelper.java jdk/internal/ref/TestCleanable.java
> 29:  * @modules java.base/jdk.internal.ref
> 30:  * @run testng/othervm --add-exports java.base/jdk.internal.ref=ALL-UNNAMED CleanableListTest

I don't think you need this --add-exports flag; JTReg modules tag should take care of it for you.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1845168888

From darcy at openjdk.org  Sat Nov 16 20:38:51 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Sat, 16 Nov 2024 20:38:51 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <NKoM3ajrgBzyZBLzSOOZmRfUTTezSj4As-AaAjhvKQg=.4d2f3dec-f0cd-48b1-b2d6-d214ba32aca7@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
 <NKoM3ajrgBzyZBLzSOOZmRfUTTezSj4As-AaAjhvKQg=.4d2f3dec-f0cd-48b1-b2d6-d214ba32aca7@github.com>
Message-ID: <1Bhgadfr36WUdHx0lhPjXbD4kK2uDSVne4_UIhIL0SU=.81709809-ff66-432b-a832-50ff257d69d9@github.com>

On Sat, 16 Nov 2024 07:59:15 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> The CSR for JEP 486 included all the API changes for the supported APIs. With this PR we are in grey area of "critical internal APIs" that are undocumented. We have been doing CSRs whenever we remove these anything from jdk.unsupported, and more recently, the stop-gap work for serialization is adding methods that will be tracked by the CSR. I'm sure the CSR will approve this quickly.

Yes; please run a quick CSR for this change. Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2480802625

From rsunderbabu at openjdk.org  Sun Nov 17 04:37:18 2024
From: rsunderbabu at openjdk.org (Ramkumar Sunderbabu)
Date: Sun, 17 Nov 2024 04:37:18 GMT
Subject: RFR: 8318668:
 java/lang/management/MemoryMXBean/CollectionUsageThreshold.java fails with
 Xcomp
Message-ID: <NTzYoZw70URpk4gNsC5O971TLRBeT0u8mFVeZqcne8o=.a0df00bf-f25c-4ad9-8d66-0bb1f9261265@github.com>

Trivial change to exclude the test from running with Xcomp flag.

The test fails because the number of GCs as reported by the MXBean doesn't match the expected number. This is due to the additional GC happening due to CodeCache crossing its threshold.
We could increase the code cache or restrict the specific compiler that fills the cache. But this will not completely eliminate the possibility as cache size could be overridden or the same failure can happen for a different compiler.

So, it is better to restrict the Xcomp flag as a whole.

Testing:
Only local testing done as it is trivial change. One run with Xcomp and another without any flags.

-------------

Commit messages:
 - Excluding the test for Xcomp

Changes: https://git.openjdk.org/jdk/pull/22180/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22180&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8318668
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22180.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22180/head:pull/22180

PR: https://git.openjdk.org/jdk/pull/22180

From dl at openjdk.org  Sun Nov 17 15:33:02 2024
From: dl at openjdk.org (Doug Lea)
Date: Sun, 17 Nov 2024 15:33:02 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request incrementally with one additional commit since the last revision:

  Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/a32e818d..0f5aa3dc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=28
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=27-28

  Stats: 66 lines in 2 files changed: 44 ins; 11 del; 11 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From eirbjo at openjdk.org  Sun Nov 17 19:53:56 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 17 Nov 2024 19:53:56 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and java.sql.rowset
 modules
Message-ID: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>

Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486

There are quite a few changes to review, but all relatively straightforward:

`DriverManager`
* Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
* Remove two now-unused package private SQLPermission constants
* `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers

`CachedRowSetImpl`
*  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
* `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`


`SerialJavaObject`
*  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.

`SyncFactory`
* `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
* `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
* `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
* `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`

`RowsetProvider`
*  Static initializer is updated to call `System::getProperty` directly
* `newFactory` is updated to call `System::getProperty` directly
* `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
* `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
* `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
* `getSystemProperty` is removed


`SQLInputImpl`
*  A call to `ReflectUtil::checkPackageAccess` is removed

`XmlReaderContentHandler::endElement`
* Replace `ReflectUtil.forName` with `Class::forName`

 `TestPolicy.java` in `test/java/sql/testng/util`
* This  is now unused and removed

Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.

-------------

Commit messages:
 - Remove unused class TestPolicy from test/java/sql/testng/util
 - Remove unused SQLPermission constants
 - Update copyright
 - Remove calls to ReflectUtil.checkPackageAccess
 - Inline call to Class.forName
 - Remove call to ReflectUtil::checkPackageAccess
 - Remove @SuppressWarnings("removal")
 - SecurityManager-related cleanups for java.sql and java.sql.rowset

Changes: https://git.openjdk.org/jdk/pull/22185/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22185&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344365
  Stats: 403 lines in 9 files changed: 10 ins; 349 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/22185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22185/head:pull/22185

PR: https://git.openjdk.org/jdk/pull/22185

From eirbjo at openjdk.org  Sun Nov 17 20:30:00 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Sun, 17 Nov 2024 20:30:00 GMT
Subject: RFR: 8178966: Don't swallow early bootstrap exceptions in
 Boolean.getBoolean, Integer.getInteger and Long.getLong
Message-ID: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>

Please review this PR which removes exceptional control flow in `Boolean::getBoolean`, `Integer::getInteger` and `Long::getLong`.

These methods are catching `IllegalArgumentException` and `NullPointerException`, thrown by `System::getProperty` via `System::checkKey`. This PR replaces the exceptional control flow with explicit checks that the system property name is non-null and non-empty before calling into `System::getProperty`.

As JDK-8178966 points out, there is a possibility that System.getProperty could throw one of NPE and IAE for other reasons than the name being null or empty. This risk is reduced now that custom security managers cannot interfere. Adding to that, if such exceptions are thrown today, they are masked by these methods catching and swallowing them by returning false or default values. It's better to expose such  bugs if they exist.

GHA results pending. Local tier2 ran successfully.

-------------

Commit messages:
 - Avoid exceptional control flow in Boolean.getBoolean, Integer.getInteger, Long.getLong

Changes: https://git.openjdk.org/jdk/pull/22183/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22183&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8178966
  Stats: 16 lines in 3 files changed: 0 ins; 13 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22183.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22183/head:pull/22183

PR: https://git.openjdk.org/jdk/pull/22183

From asemenyuk at openjdk.org  Sun Nov 17 23:49:55 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Sun, 17 Nov 2024 23:49:55 GMT
Subject: Integrated: 8343876: Enhancements to jpackage test lib
In-Reply-To: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
References: <y_Yq5DEaHdDBNUMvyPG88nJQoi5guvjsp7uvWT-7vLc=.00ed33a1-00bc-463e-aa71-9f7c0ec91bc5@github.com>
Message-ID: <LolxtxkF9SQqTSN8chOKbZorjplcAyCwwUhq0vMqPRY=.b783ea0f-4205-4cc4-8479-5498e175c43b@github.com>

On Sat, 9 Nov 2024 00:51:03 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Make jpackage test lib more practical. List of changes:
> 
> Support multiple args and var args in `@Parameter` annotation:
> 
> @Test
> @Parameter({"12", "foo"})
> @Parameter({"-89", "bar", "more"})
> @Parameter({"-89", "bar", "more", "moore"})
> public void testVarArg(int a, String b, String ... other) {}
> 
> 
> Full support for var args in test constructors.<br/>Better results when looking up the suitable ctor for the ctor args with `null`-s.<br/>Support multiple functions with `@Parameteres` annotation, all will be executed instead of the first one earlier:
> 
> class FooTest {
>     public FooTest(String... args) {}
>     public FooTest(int o) {}
>     public FooTest(int a, Boolean[] b, String c, String ... other) {}
> 
>     @Parameters
>     public static Collection<Object[]> input() {
>         return List.of(new Object[][] {
>             {},
>             {"str"},
>             {55, new Boolean[]{false, true, false}, "foo", "bar"},
>         });
>     }
> 
>     @Parameters
>     public static Collection<Object[]> input2() {
>         return List.of(new Object[][] {
>             {78},
>             {34, null, null},
>         });
>     }
> }
> 
> 
> Static test method will be executed only once and not as many times as the number of the test class instances.
> 
> Introduced `@ParameterSupplier` annotation as a flexible alternative to `@Parameter`:
> 
> 
> class FooTest {
>     @Test
>     @ParameterSupplier("dateSupplier")
>     @ParameterSupplier("AnotherClass.dateSupplier")
>     public void testDates(LocalDate v) {}
> 
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2018-05-05") },
>             { LocalDate.parse("2018-07-11") },
>         });
>     }
> }
> 
> class AnotherClass {
>     public static Collection<Object[]> dateSupplier() {
>         return List.of(new Object[][] {
>             { LocalDate.parse("2028-07-11") },
>         });
>     }
> }
> 
> 
> All annotations support `ifOS` and `ifNotOS` properties of type `jdk.internal.util.OperatingSystem`:
> 
> 
> @Test(ifOS = OperatingSystem.LINUX)
> public void testRunIfLinux() {}
> 
> @Test(ifNotOS = OperatingSystem.LINUX)
> public void testRunIfNotLinux() {}
> 
> @Test(ifNotOS = {OperatingSystem.LINUX,OperatingSystem.MACOS})
> public void testRunIfNotLinuxOrMacOS() {}
> 
> @Test
> @Parameter(value = "foo", ifOS = OperatingSystem.LINUX)
> @Parameter(value = {"foo", "bar"}, ifOS = { OperatingSystem.LINUX, OperatingSystem.MACOS })
> @Parameter(value = {}, ifNotOS = { OperatingSystem.WINDOWS })
> @ParameterSupplier(value = "getWindowsStrings", ifOS = OperatingSyst...

This pull request has now been integrated.

Changeset: 41a627b7
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41a627b7890ab7fefef49e3bac3aad8403d0e82e
Stats:     1658 lines in 13 files changed: 1321 ins; 196 del; 141 mod

8343876: Enhancements to jpackage test lib

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/21996

From jlu at openjdk.org  Mon Nov 18 00:19:02 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Nov 2024 00:19:02 GMT
Subject: RFR: 8343237: Improve the copying of the available set of
 Currencies
In-Reply-To: <PuaktdmoJvTll6jpRanMGp6RoG85xw-FSn86s9IA0xQ=.f2db1c2e-3b14-48d3-a8f4-92a4ae338f52@github.com>
References: <PuaktdmoJvTll6jpRanMGp6RoG85xw-FSn86s9IA0xQ=.f2db1c2e-3b14-48d3-a8f4-92a4ae338f52@github.com>
Message-ID: <rO1pkNCeOTcctrBGTXn0fj0x99NkFNfkW_M4xkgrYfs=.b40f948a-ddcd-4075-9d56-7f90bff6e5e7@github.com>

On Fri, 1 Nov 2024 23:17:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a small cleanup in `Currency.getAvailableCurrencies()`. We can use the `HashSet` constructor over `clone()` to make the defensive copy of the set of available currencies. This gets rid of the unsightly unchecked cast and SuppressWarnings annotation.

Thanks for the review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21845#issuecomment-2481695608

From jlu at openjdk.org  Mon Nov 18 00:19:02 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Nov 2024 00:19:02 GMT
Subject: Integrated: 8343237: Improve the copying of the available set of
 Currencies
In-Reply-To: <PuaktdmoJvTll6jpRanMGp6RoG85xw-FSn86s9IA0xQ=.f2db1c2e-3b14-48d3-a8f4-92a4ae338f52@github.com>
References: <PuaktdmoJvTll6jpRanMGp6RoG85xw-FSn86s9IA0xQ=.f2db1c2e-3b14-48d3-a8f4-92a4ae338f52@github.com>
Message-ID: <GzwJayK7_OpTGZhKkSszMS2dAsfNcBZHsnWqMHRETI4=.74d4a3eb-f90e-413d-956a-d88a8cd008be@github.com>

On Fri, 1 Nov 2024 23:17:01 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which is a small cleanup in `Currency.getAvailableCurrencies()`. We can use the `HashSet` constructor over `clone()` to make the defensive copy of the set of available currencies. This gets rid of the unsightly unchecked cast and SuppressWarnings annotation.

This pull request has now been integrated.

Changeset: e1c4b497
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e1c4b4977ec613efe4f51151433e242a256204ee
Stats:     4 lines in 1 file changed: 0 ins; 3 del; 1 mod

8343237: Improve the copying of the available set of Currencies

Reviewed-by: bpb

-------------

PR: https://git.openjdk.org/jdk/pull/21845

From liach at openjdk.org  Mon Nov 18 00:18:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 00:18:55 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
Message-ID: <280hRVhkkj5Qio59CpMkhpMF9un2_o9VLBCnuLHHIJQ=.41491d89-4fc5-408f-9c2a-9c3f5bbe3149@github.com>

On Fri, 15 Nov 2024 22:11:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)

src/java.base/share/classes/java/lang/String.java line 691:

> 689:                     System.getSecurityManager() != null) {
> 690:                 bytes = Arrays.copyOfRange(bytes, offset, offset + length);
> 691:                 offset = 0;

Was this defensive copy particularly important to security managers but has no effect for other scenarios?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22168#discussion_r1845705327

From iris at openjdk.org  Mon Nov 18 01:35:07 2024
From: iris at openjdk.org (Iris Clark)
Date: Mon, 18 Nov 2024 01:35:07 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
Message-ID: <Tp6ovDvXsen9cOyCVWF5mUyuqKBmLJsV0CCd99cOflk=.08ed9a29-6f05-4987-ba14-828ffd450b27@github.com>

On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It's somewhat nicer to use \\s instead of space character in regex

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22081#pullrequestreview-2441317522

From liach at openjdk.org  Mon Nov 18 02:58:31 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 02:58:31 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v3]
In-Reply-To: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
Message-ID: <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>

> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.

Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Further facelift
 - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
 - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
 - Typos, long lines
 - Labels
 - Wip instr

-------------

Changes: https://git.openjdk.org/jdk/pull/21625/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21625&range=02
  Stats: 2380 lines in 38 files changed: 1976 ins; 27 del; 377 mod
  Patch: https://git.openjdk.org/jdk/pull/21625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21625/head:pull/21625

PR: https://git.openjdk.org/jdk/pull/21625

From liach at openjdk.org  Mon Nov 18 04:12:42 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 04:12:42 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v3]
In-Reply-To: <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
Message-ID: <D6k05zAvtApNvtxeezcMtQIhednn1T4b1lTomAzr63M=.646dd6e3-a907-4333-90c2-c925f14348c9@github.com>

On Mon, 18 Nov 2024 02:58:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Further facelift
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Typos, long lines
>  - Labels
>  - Wip instr

After offline discussions, I believe it is necessary to also include the data models of instructions in the javadoc; they will be removed from the `java.lang.classfile` top-level documentation later.

I am pleased with the current state of the documentation, and have submitted a CSR.
Please review the renderings:

API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html

(Omitted the constant rendering changes; committed locally, will push with other review fixes later)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21625#issuecomment-2481906372

From alanb at openjdk.org  Mon Nov 18 07:18:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Nov 2024 07:18:49 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules
In-Reply-To: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
Message-ID: <oJ2g50O6G5wyx-vRnbnc-mhXXPZJbSk6t4GvKfVG0bo=.2fd81029-a5e7-4acd-b490-e73794001661@github.com>

On Sun, 17 Nov 2024 19:01:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
> 
> There are quite a few changes to review, but all relatively straightforward:
> 
> `DriverManager`
> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
> * Remove two now-unused package private SQLPermission constants
> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
> 
> `CachedRowSetImpl`
> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
> 
> `CachedRowSetWriter`
> * A call to `ReflectUtil::checkPackageAccess` is removed.
> 
> `SerialJavaObject`
> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
> 
> `SyncFactory`
> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
> 
> `RowsetProvider`
> *  Static initializer is updated to call `System::getProperty` directly
> * `newFactory` is updated to call `System::getProperty` directly
> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getSystemProperty` is removed
> 
> 
> `SQLInputImpl`
> *  A call to `ReflectUtil::checkPackageAccess` is removed
> 
> `XmlReaderContentHandler::endElement`
> * Replace `ReflectUtil.forName` with `Class::forName`
> 
>  `TestPolicy.java` in `test/java/sql/testng/util`
> * This  is now unused and removed
> 
> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.

I think Brent and/or Lance have been working on this already. If you are taking this, can you remove src/java.sql.rowset/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java from the patch as it introduces a behavioural change that may require further work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2482131898

From jlu at openjdk.org  Mon Nov 18 07:45:57 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Nov 2024 07:45:57 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
Message-ID: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>

Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change. Alternatively the diffs can be viewed on the API diff link attached on the CSR.

-------------

Commit messages:
 - remove the manual dashes
 - init

Changes: https://git.openjdk.org/jdk/pull/22192/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22192&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8341923
  Stats: 298 lines in 1 file changed: 101 ins; 87 del; 110 mod
  Patch: https://git.openjdk.org/jdk/pull/22192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22192/head:pull/22192

PR: https://git.openjdk.org/jdk/pull/22192

From eirbjo at openjdk.org  Mon Nov 18 08:13:41 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 08:13:41 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules
In-Reply-To: <oJ2g50O6G5wyx-vRnbnc-mhXXPZJbSk6t4GvKfVG0bo=.2fd81029-a5e7-4acd-b490-e73794001661@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <oJ2g50O6G5wyx-vRnbnc-mhXXPZJbSk6t4GvKfVG0bo=.2fd81029-a5e7-4acd-b490-e73794001661@github.com>
Message-ID: <budWWSLHsuXUFHmup-PMuQ5jl1An2SPsdZSit2TN2DY=.e5698429-0592-4eee-94a2-9ca23ef1da6d@github.com>

On Mon, 18 Nov 2024 07:16:32 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I think Brent and/or Lance have been working on this already.

Happy to yield if Brent/Lance has something cooking. Otherwise, perhaps their time is better spent as reviewers.

> If you are taking this, can you remove src/java.sql.rowset/share/classes/com/sun/rowset/internal/XmlReaderContentHandler.java from the patch as it introduces a behavioural change that may require further work.

Seems like a clean inline, how does this introduce a behavioural change?

`ReflectUtil`:


public static Class<?> forName(String name) throws ClassNotFoundException {
    return Class.forName(name);
}

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2482224945

From alanb at openjdk.org  Mon Nov 18 08:25:42 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Nov 2024 08:25:42 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules
In-Reply-To: <budWWSLHsuXUFHmup-PMuQ5jl1An2SPsdZSit2TN2DY=.e5698429-0592-4eee-94a2-9ca23ef1da6d@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <oJ2g50O6G5wyx-vRnbnc-mhXXPZJbSk6t4GvKfVG0bo=.2fd81029-a5e7-4acd-b490-e73794001661@github.com>
 <budWWSLHsuXUFHmup-PMuQ5jl1An2SPsdZSit2TN2DY=.e5698429-0592-4eee-94a2-9ca23ef1da6d@github.com>
Message-ID: <IbUA6GsY5kVltzKlSAbbD7b4azT3nUawu5OV6nZIgWA=.219c83a2-114d-402d-a59d-ee014716e331@github.com>

On Mon, 18 Nov 2024 08:11:03 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Seems like a clean inline, how does this introduce a behavioural change?

Class.forName's behavior depends on the caller's defining class loader. I don't know where Brent and/or Lance is on the changes for this module but if you are taking it then I would prefer if the changes to XmlReaderContentHandler were dropped.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2482249585

From mbaesken at openjdk.org  Mon Nov 18 08:26:20 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 18 Nov 2024 08:26:20 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302 [v2]
In-Reply-To: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
Message-ID: <a7n2qIhrXauXNrVYRpccM_AhGkLbGc44lsyh2vkotj8=.360d434c-73bb-461c-900d-18ddece27409@github.com>

> On AIX we run into errors below, for example in test tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug binaries, opt worked :
> 
> jlink options: --output java-base-with-opts-jlink-tmp --add-modules jdk.jlink,java.base --generate-linkable-runtime --keep-packaged-modules=java-base-with-opts-jlink-tmp/jmods
> Error: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.io.InputStream.readNBytes(InputStream.java:447)
> at java.base/java.io.InputStream.readAllBytes(InputStream.java:348)
> at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127)
> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.ResourcePoolReader.getResourceBytes(ResourcePoolReader.java:54)
> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.JimageDiffGenerator.generateDiff(JimageDiffGenerator.java:89)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.addResourceDiffFiles(ImageFileCreator.java:357)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:264)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:202)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:131)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:1041)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:501)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:294)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:713)
> at AbstractLinkableRuntimeTest.createRuntimeLinkImage(AbstractLinkableRuntimeTest.java:273)
> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:126)
> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:121)
> at AddOptionsTest.runTest(AddOptionsTest.java:64)
> at AbstractLinkableRuntimeTest.run(AbstractLinkableRuntimeTest.java:62)
> at AddOptionsTest.main(AddOptionsTest.java:49)
> at java.base/java.lang.invoke.LambdaForm$DMH/0x0a0001009070c3e0.invokeStatic(LambdaForm$DMH)
> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090710c10.invoke(LambdaForm$MH)
> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090711408.invokeExact_MT(LambdaForm$MH)
> at ja...

Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:

  use Xmx1400m

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22140/files
  - new: https://git.openjdk.org/jdk/pull/22140/files/b6a5aa85..1c911f63

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22140&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22140&range=00-01

  Stats: 14 lines in 14 files changed: 0 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/22140.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22140/head:pull/22140

PR: https://git.openjdk.org/jdk/pull/22140

From mbaesken at openjdk.org  Mon Nov 18 08:35:52 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Mon, 18 Nov 2024 08:35:52 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302 [v2]
In-Reply-To: <a7n2qIhrXauXNrVYRpccM_AhGkLbGc44lsyh2vkotj8=.360d434c-73bb-461c-900d-18ddece27409@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
 <a7n2qIhrXauXNrVYRpccM_AhGkLbGc44lsyh2vkotj8=.360d434c-73bb-461c-900d-18ddece27409@github.com>
Message-ID: <JMxnmbl0_zo1SrrImLODtdZBuORxXmvCJzPDyi9bFmw=.b78088f6-04d4-4dad-ac6f-a981ebf4acdb@github.com>

On Mon, 18 Nov 2024 08:26:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On AIX we run into errors below, for example in test tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug binaries, opt worked :
>> 
>> jlink options: --output java-base-with-opts-jlink-tmp --add-modules jdk.jlink,java.base --generate-linkable-runtime --keep-packaged-modules=java-base-with-opts-jlink-tmp/jmods
>> Error: Java heap space
>> java.lang.OutOfMemoryError: Java heap space
>> at java.base/java.io.InputStream.readNBytes(InputStream.java:447)
>> at java.base/java.io.InputStream.readAllBytes(InputStream.java:348)
>> at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127)
>> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.ResourcePoolReader.getResourceBytes(ResourcePoolReader.java:54)
>> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.JimageDiffGenerator.generateDiff(JimageDiffGenerator.java:89)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.addResourceDiffFiles(ImageFileCreator.java:357)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:264)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:202)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:131)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:1041)
>> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:501)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:294)
>> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
>> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:713)
>> at AbstractLinkableRuntimeTest.createRuntimeLinkImage(AbstractLinkableRuntimeTest.java:273)
>> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:126)
>> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:121)
>> at AddOptionsTest.runTest(AddOptionsTest.java:64)
>> at AbstractLinkableRuntimeTest.run(AbstractLinkableRuntimeTest.java:62)
>> at AddOptionsTest.main(AddOptionsTest.java:49)
>> at java.base/java.lang.invoke.LambdaForm$DMH/0x0a0001009070c3e0.invokeStatic(LambdaForm$DMH)
>> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090710c10.invoke(LambdaForm$MH)
>> at java.base/java.lang.invoke.LambdaFo...
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Xmx1400m

I reduced to Xmx1400m seems that is sufficient for the memory requirements on AIX.

Unfortunately I still get now in the PackagedModulesVsRuntimeImageLinkTest
Timeout information:
Running jstack on process 16253352
16253352: Unable to open socket file /tmp/.java_pid16253352: target process 16253352 doesn't respond within 10500ms or HotSpot VM not loaded
(when running centrally in the concurrent tests)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22140#issuecomment-2482270742

From eirbjo at openjdk.org  Mon Nov 18 08:37:26 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 08:37:26 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v2]
In-Reply-To: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
Message-ID: <okJ2mkNbFajOLo5-sWw1E2DyfqrlgbPv0So4chqy2KE=.8acabafb-300a-488c-b52e-224057022ad6@github.com>

> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
> 
> There are quite a few changes to review, but all relatively straightforward:
> 
> `DriverManager`
> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
> * Remove two now-unused package private SQLPermission constants
> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
> 
> `CachedRowSetImpl`
> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
> 
> `CachedRowSetWriter`
> * A call to `ReflectUtil::checkPackageAccess` is removed.
> 
> `SerialJavaObject`
> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
> 
> `SyncFactory`
> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
> 
> `RowsetProvider`
> *  Static initializer is updated to call `System::getProperty` directly
> * `newFactory` is updated to call `System::getProperty` directly
> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getSystemProperty` is removed
> 
> 
> `SQLInputImpl`
> *  A call to `ReflectUtil::checkPackageAccess` is removed
> 
>  `TestPolicy.java` in `test/java/sql/testng/util`
> * This  is now unused and removed
> 
> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:

 - Revert caller-sensitive inlining of ReflectUtil.forName
 - SerialJavaObject::getFields is no longer @CallerSensitive, remove it from CheckCSM test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22185/files
  - new: https://git.openjdk.org/jdk/pull/22185/files/d45c5ec0..d539a31a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22185&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22185&range=00-01

  Stats: 7 lines in 2 files changed: 0 ins; 3 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22185/head:pull/22185

PR: https://git.openjdk.org/jdk/pull/22185

From eirbjo at openjdk.org  Mon Nov 18 08:37:26 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 08:37:26 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules
In-Reply-To: <IbUA6GsY5kVltzKlSAbbD7b4azT3nUawu5OV6nZIgWA=.219c83a2-114d-402d-a59d-ee014716e331@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <oJ2g50O6G5wyx-vRnbnc-mhXXPZJbSk6t4GvKfVG0bo=.2fd81029-a5e7-4acd-b490-e73794001661@github.com>
 <budWWSLHsuXUFHmup-PMuQ5jl1An2SPsdZSit2TN2DY=.e5698429-0592-4eee-94a2-9ca23ef1da6d@github.com>
 <IbUA6GsY5kVltzKlSAbbD7b4azT3nUawu5OV6nZIgWA=.219c83a2-114d-402d-a59d-ee014716e331@github.com>
Message-ID: <i-F_sz4NVdT1SbMDtqdop9ij7XAiyJQMZuq2WUB4m3s=.e39dc140-c6bb-4560-9e47-8ecf08044afc@github.com>

On Mon, 18 Nov 2024 08:23:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Class.forName's behavior depends on the caller's defining class loader. I don't know where Brent and/or Lance is on the changes for this module but if you are taking it then I would prefer if the changes to XmlReaderContentHandler were dropped.

Thanks, makes sense. I have reverted changes in `XmlReaderContentHandler`

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2482264338

From shade at openjdk.org  Mon Nov 18 09:29:49 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Nov 2024 09:29:49 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <wTIRY1w8dzaW27_TTpa6PoT0sr_dgYPu6k8W11e-4-c=.bafac258-210b-4565-9da2-15badc676b4a@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
 <wTIRY1w8dzaW27_TTpa6PoT0sr_dgYPu6k8W11e-4-c=.bafac258-210b-4565-9da2-15badc676b4a@github.com>
Message-ID: <HboLqjDKSLvEN0WGaX7sfc1l-Ny6ajYN6CeoxmRrZMQ=.adc10c88-5292-49bf-9697-0d7de64a97f1@github.com>

On Sat, 16 Nov 2024 18:11:32 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   prev is not needed
>
> test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 30:
> 
>> 28:  * @compile/module=java.base jdk/internal/ref/CleanableListTestHelper.java jdk/internal/ref/TestCleanable.java
>> 29:  * @modules java.base/jdk.internal.ref
>> 30:  * @run testng/othervm --add-exports java.base/jdk.internal.ref=ALL-UNNAMED CleanableListTest
> 
> I don't think you need this --add-exports flag; JTReg modules tag should take care of it for you.

Indeed. I'll drop it in next update.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1846163165

From ihse at openjdk.org  Mon Nov 18 09:29:52 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 09:29:52 GMT
Subject: Integrated: 8344056: Use markdown format for man pages
In-Reply-To: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
Message-ID: <_LM2L_tT9Q4OZvoeWztNyLUkzQcLPQIE_En639Pu_lA=.31310c87-64b4-4b97-bb0c-f044e312e9ef@github.com>

On Wed, 13 Nov 2024 17:05:25 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
> 
> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
> 
> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.

This pull request has now been integrated.

Changeset: 475feb06
Author:    Magnus Ihse Bursie <ihse at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/475feb064bb6b9dfd34fc52762e3e0ab825254ec
Stats:     41386 lines in 66 files changed: 18876 ins; 22500 del; 10 mod

8344056: Use markdown format for man pages

Reviewed-by: cstein, iris, dholmes

-------------

PR: https://git.openjdk.org/jdk/pull/22081

From shade at openjdk.org  Mon Nov 18 09:41:46 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Nov 2024 09:41:46 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <mJCxlRB5BP33JI_qBZFLXQmEw5u00EXKHTpPW0Kv1hQ=.15e410bd-881e-4934-99e1-fc18589e9e0f@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
 <mJCxlRB5BP33JI_qBZFLXQmEw5u00EXKHTpPW0Kv1hQ=.15e410bd-881e-4934-99e1-fc18589e9e0f@github.com>
Message-ID: <lOhJCQiBzujJzH7tGdmaCa1KZigppbR_IYR-5LZcjr8=.2cac2da7-0b03-4a69-aa63-c432f4aaecb4@github.com>

On Fri, 15 Nov 2024 21:31:54 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   prev is not needed
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 310:
> 
>> 308:             }
>> 309:             assert phc.node.arr[phc.index] == phc;
>> 310:             assert head.size > 0;
> 
> I now realize that these assertions in `remove()` won't really "work" because _"exceptions thrown by the cleaning action are ignored"_. :(
> When the cleaner thread removes the phc (`ref.clean()` in `run()` on L142 -> `list.remove()` on PhantomCleanable L94 ), any `AssertionError`s will get lost in `run()`'s `catch` statement, L144.
> 
> (There is a related RFE [JDK-8305979 : UncaughtExceptionHandler for Cleaner](https://bugs.openjdk.org/browse/JDK-8305979))

Ah, true. Yes, this is inconvenient, but I think these asserts are opportunistic to catch internal errors, so they are of interest of JDK testing and catching JDK bugs, not the issues in the user code in Cleaners. I see the asserts would fire from the direct invocation of `clean()`, as deliberately breaking the asserts in `remove()` gets me this failure immediately:


Running test 'jtreg:test/jdk/java/lang/ref'
Directory "/Users/shipilev/Work/shipilev-jdk/build/macosx-aarch64-server-release/test-results/jtreg_test_jdk_java_lang_ref" not found: creating
Error: A JNI error has occurred, please check your installation and try again
Exception in thread "main" java.lang.AssertionError
	at java.base/jdk.internal.ref.CleanerImpl$CleanableList.remove(CleanerImpl.java:310)
	at java.base/jdk.internal.ref.PhantomCleanable.clean(PhantomCleanable.java:94)
	at java.base/java.util.zip.ZipFile$ZipFileInflaterInputStream.close(ZipFile.java:416)
	at java.base/java.util.jar.JarFile.getBytes(JarFile.java:803)
	at java.base/java.util.jar.JarFile.checkForSpecialAttributes(JarFile.java:1006)
	at java.base/java.util.jar.JarFile.hasClassPathAttribute(JarFile.java:954)
	at java.base/java.util.jar.JavaUtilJarAccessImpl.jarFileHasClassPathAttribute(JavaUtilJarAccessImpl.java:34)
	at java.base/jdk.internal.loader.URLClassPath$JarLoader.getClassPath(URLClassPath.java:922)
	at java.base/jdk.internal.loader.URLClassPath.getLoader(URLClassPath.java:447)
	at java.base/jdk.internal.loader.URLClassPath.getResource(URLClassPath.java:314)
	at java.base/jdk.internal.loader.BuiltinClassLoader.findClassOnClassPathOrNull(BuiltinClassLoader.java:757)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClassOrNull(BuiltinClassLoader.java:681)
	at java.base/jdk.internal.loader.BuiltinClassLoader.loadClass(BuiltinClassLoader.java:639)
	at java.base/jdk.internal.loader.ClassLoaders$AppClassLoader.loadClass(ClassLoaders.java:188)
	at java.base/java.lang.ClassLoader.loadClass(ClassLoader.java:497)
	at java.base/java.lang.Class.forName0(Native Method)
	at java.base/java.lang.Class.forName(Class.java:577)
	at java.base/java.lang.Class.forName(Class.java:556)
	at java.base/sun.launcher.LauncherHelper.loadMainClass(LauncherHelper.java:854)
	at java.base/sun.launcher.LauncherHelper.checkAndLoadMain(LauncherHelper.java:739)


So I don't regard this as blocking.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1846180271

From alanb at openjdk.org  Mon Nov 18 09:42:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Nov 2024 09:42:20 GMT
Subject: RFR: 8342380: Implement JEP 498: Warn upon Use of Memory-Access
 Methods in sun.misc.Unsafe [v3]
In-Reply-To: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
Message-ID: <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>

> Change default value of the command line option --sun-misc-unsafe-memory-access from "allow" to "warn".

Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:

 - Merge branch 'master' into JDK-8342380
 - Merge branch 'master' into JDK-8342380
 - Update test
 - Merge branch 'master' into JDK-8342380
 - Update usage/man page
 - Initial commit

-------------

Changes: https://git.openjdk.org/jdk/pull/21762/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21762&range=02
  Stats: 29 lines in 4 files changed: 10 ins; 5 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/21762.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21762/head:pull/21762

PR: https://git.openjdk.org/jdk/pull/21762

From shade at openjdk.org  Mon Nov 18 09:46:50 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Mon, 18 Nov 2024 09:46:50 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v11]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <yTGlChV6gSyRFN_7Vm2FNVWGcomGXSv5r7_vnPOqzM0=.c966918e-d540-4329-a492-c4713080f172@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Drop --add-exports from the test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/30c0c7c5..de1a1b70

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=10
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=09-10

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From ihse at openjdk.org  Mon Nov 18 10:25:56 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 10:25:56 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v11]
In-Reply-To: <2EQObSBYG9ZtB0qDRKvYjERfxkYKTlGAlQ9JVEj9zYg=.61c7c77a-746a-4c30-9c58-dfb564ecf24d@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7MvsbWwg0NapAkQ45NF2u-KUtT7JaeyDjjPJa3bgK70=.9e181a2f-5d7d-43de-b943-cbd76de06e2f@github.com>
 <zNCkkRVUN1in536PEjPTyTRlvrjgd5082V4cQ_KnjU4=.db76a175-9dce-4431-ac30-db7fd8829f50@github.com>
 <d1amVzHP2IX0PFufkHNm7W4_vRy6U_JSBJg6yXOAp5g=.49e079ba-42d2-4d8a-b3b9-224996db2ef0@github.com>
 <OYtzjDOsfGW4aH2apZYeRIodfhVOygYCJG2f8yqwLG8=.904c30ae-5778-4f51-a249-c5e81f6e7316@github.com>
 <vMfVw435X4Ib8xTY7T938WIiBKPMCSa6k7n0-H7KpzU=.6c96e323-f40b-4791-932e-31645e2149a4@github.com>
 <2PNXRviwavdaWvhjoHUOC8iwQzeF7zub2JoHjfj9wiI=.f502c575-ffc7-4570-891e-4c61b89c1cf4@github.com>
 <2EQObSBYG9ZtB0qDRKvYjERfxkYKTlGAlQ9JVEj9zYg=.61c7c77a-746a-4c30-9c58-dfb564ecf24d@github.com>
Message-ID: <9hxLf3Da2FuthkQQ_rWuy15NcB6mv8qN6a0H2Figd54=.e6f301da-8351-4aa7-acf3-533e6cdf5857@github.com>

On Wed, 16 Oct 2024 07:39:06 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Yes, I just pushed a commit that does that. I have manually inspected the values and it looks sane, but I need to verify it on our CI system as well. The reasoning for us setting some of the ld flags are less than clear, so it is a bit hard to tell if they should be included or not.
>
> This change started to expose some other problems as well. I'll need to work a bit more on getting this right.

The "other problems" I noted where not related to the `LDFLAGS_STATIC_JDK` fix, so this part should be okay now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846311675

From vklang at openjdk.org  Mon Nov 18 10:33:44 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 18 Nov 2024 10:33:44 GMT
Subject: RFR: 8342380: Implement JEP 498: Warn upon Use of Memory-Access
 Methods in sun.misc.Unsafe [v3]
In-Reply-To: <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
 <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
Message-ID: <YrHwVuhmhWRGTM24TgG8jpjHc5iemb4-USz-3YDLhzE=.998391f5-e10a-4506-b236-6597c0745c27@github.com>

On Mon, 18 Nov 2024 09:42:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Change default value of the command line option --sun-misc-unsafe-memory-access from "allow" to "warn".
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8342380
>  - Merge branch 'master' into JDK-8342380
>  - Update test
>  - Merge branch 'master' into JDK-8342380
>  - Update usage/man page
>  - Initial commit

?

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21762#pullrequestreview-2442211701

From jpai at openjdk.org  Mon Nov 18 10:42:17 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Mon, 18 Nov 2024 10:42:17 GMT
Subject: RFR: 8178966: Don't swallow early bootstrap exceptions in
 Boolean.getBoolean, Integer.getInteger and Long.getLong
In-Reply-To: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
References: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
Message-ID: <wL6MmvNTNhgAJtZUHlNr17mItxoCAVId7JY32k83cAk=.b13ca6ba-75ec-4bb9-81e0-e10fd60b95dc@github.com>

On Sun, 17 Nov 2024 14:52:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes exceptional control flow in `Boolean::getBoolean`, `Integer::getInteger` and `Long::getLong`.
> 
> These methods are catching `IllegalArgumentException` and `NullPointerException`, thrown by `System::getProperty` via `System::checkKey`. This PR replaces the exceptional control flow with explicit checks that the system property name is non-null and non-empty before calling into `System::getProperty`.
> 
> As JDK-8178966 points out, there is a possibility that System.getProperty could throw one of NPE and IAE for other reasons than the name being null or empty. This risk is reduced now that custom security managers cannot interfere. Adding to that, if such exceptions are thrown today, they are masked by these methods catching and swallowing them by returning false or default values. It's better to expose such  bugs if they exist.
> 
> GHA results pending. Local tier2 ran successfully.

Hello Eirik, this looks reasonable to me. Is this something that you want to add Peter as a contributor to, given his original proposal in the issue?

I can't think of any reason not to do this change, but it would be good to have one more review for this one. So please wait for one before integrating.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22183#pullrequestreview-2442238986

From ihse at openjdk.org  Mon Nov 18 10:42:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 10:42:33 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v12]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <90EUZdTLd7PXDJxlcyHtNLEmLffK7xQoKCs7qWZM858=.599310f0-d23f-4cbc-bd26-5eb7d857638d@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Remove unnecessary change for macOS in java_md.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/0e5ff083..922d7e76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=10-11

  Stats: 3 lines in 1 file changed: 0 ins; 3 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From ihse at openjdk.org  Mon Nov 18 10:42:33 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 10:42:33 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v7]
In-Reply-To: <PcJxaNFB6UcGSbywAdz0OLCnSp_tYi_zBJdd4gtUQ78=.f56e03b4-3984-4f3c-a4b5-a1cd12847ff7@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <p9lmyrgXh8Une2LPqOY75ctFIHuDg2OWMt-9yN2ip7Y=.e8724881-2e0a-4eed-8482-aef3b3d13b7d@github.com>
 <iP9XRtTeh8wPBqtj-o6JGhHkRqZTia-qt9ghVH0E0Iw=.31a75e2b-b453-4e8f-956d-2ce6c86a39ac@github.com>
 <PcJxaNFB6UcGSbywAdz0OLCnSp_tYi_zBJdd4gtUQ78=.f56e03b4-3984-4f3c-a4b5-a1cd12847ff7@github.com>
Message-ID: <9DaE4BsBl9ygp4bZVE1owYJVc129QRVFgXX3ZGC_sqs=.e6358bb4-2e36-43dd-ade9-fb8ef0f3c775@github.com>

On Mon, 21 Oct 2024 13:07:34 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> src/java.base/unix/native/libjli/java_md.c line 279:
>> 
>>> 277:                            char jvmpath[], jint so_jvmpath,
>>> 278:                            char jvmcfg[],  jint so_jvmcfg) {
>>> 279:     /* Compute/set the name of the executable. This is needed for macOS. */
>> 
>> But this file is not used when on macOS, is it? (cfr java_md_macosx.m) )
>
> Hm. I think both are used? I'll need to double-check that.

You are right. Don't know how this got in here, I must have thought it needed at some point when trying to get this to work on macOS. 

This really is a sign that I've been doing cargo-cult programming. The entire JDK bootstrapping mechanism is so spread-out and difficult to follow that it ends up being more "poke a bit here and see if it works" kind of programming instead of understanding what needs to be done and doing it. We should really make a follow-up refactoring on this to get it to a better state, across all modules and components...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846348477

From ihse at openjdk.org  Mon Nov 18 10:49:49 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 10:49:49 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>
 <QEyhmjtUis_7E8umUO_S7CpGfLxFMCGcKpkYbqxyR-c=.52160107-9ba4-4884-a6d9-1bc208126e7c@github.com>
 <u2fHrEnR89C-zHBHVzzTWT9OxlkbWj-a653OQVhPTt4=.b9bf0775-d5fb-4aa5-b441-d4a8db85b15e@github.com>
 <RMacEqw-EG630Un-DYa-lMKkRFNsItFUqzvvRf6dT64=.349aceb7-a266-4fbd-b11f-3420ba56fd81@github.com>
 <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com>
Message-ID: <8pjs3UQ6kUD7MB-FwKrINVyKt2iqHPvpB_Wo3pGuDg0=.0fddc8b7-0985-4e0b-8ee2-26bbb0cc75c9@github.com>

On Wed, 13 Nov 2024 01:40:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> @jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much.
>
> @magicus Just want to check if there's anything that you are waiting from me for this PR. My understanding is that you'll update the PR to fix the incremental build and debuginfo before the last review iteration. Please let me know if there are anything else. Thanks!

@jianglizhou 
> I think we would need to decide what is the dll_dir with the static JDK support and hermetic support.

>From my understanding, `_sun_boot_library_path` does not have any meaning when running with static builds. As I said before, I think we really ought to take a step back, consider the wider picture, and refactor the way we interact with internal native libraries. Determining how to handle `_sun_boot_library_path` for static builds are definitely part of that work.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2482664528

From ihse at openjdk.org  Mon Nov 18 11:10:08 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 11:10:08 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v13]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <egAeShKs1EBGhsRbFFvbR4O8v5ca8Y55r9g4vUDtJho=.9268d3cd-c93a-466a-8362-819b19ff40f1@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:

 - Also include information about where generated data is consumed.
 - Document how and why we keep track of native libraries per module

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/922d7e76..d491b481

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=11-12

  Stats: 10 lines in 2 files changed: 10 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From ihse at openjdk.org  Mon Nov 18 11:10:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 11:10:09 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v13]
In-Reply-To: <FQ5Ecut4VNYYHMBRZhCcVejcHrInMe7vDkyNIPZkprA=.aa9111b7-e3e3-4f4a-9031-d1fb5b9f6ffb@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <FQ5Ecut4VNYYHMBRZhCcVejcHrInMe7vDkyNIPZkprA=.aa9111b7-e3e3-4f4a-9031-d1fb5b9f6ffb@github.com>
Message-ID: <2AuWIwJHwHeyLprvYcjNGSdmVM4cH39VOrMVhnnxmBE=.c85a7591-6644-4200-bc56-cfa37028a752@github.com>

On Tue, 3 Sep 2024 19:51:39 GMT, Erik Joelsson <erikj at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Also include information about where generated data is consumed.
>>  - Document how and why we keep track of native libraries per module
>
> make/ModuleWrapper.gmk line 59:
> 
>> 57:   endif
>> 58: endif
>> 59: 
> 
> This part looks a bit convoluted. It would be nice with a comment explaining what it does, where `$($(MODULE)_JDK_LIBS)` is coming from and what consumes the module-libs.txt.

Fixed.

> make/common/JdkNativeCompilation.gmk line 310:
> 
>> 308:       $$(MODULE)_JDK_LIBS += $$($1_NAME)
>> 309:     endif
>> 310:   endif
> 
> Same, here as in ModuleWrapper.gmk, I think we need a comment explaining how this is consumed.

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846394969
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1846398235

From ihse at openjdk.org  Mon Nov 18 11:21:09 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 11:21:09 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v14]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <7K6aTd3mVPdWmwPwNeW6AYlK7a1MnTXgLBs3cMCnizA=.9ae66afa-0240-44e8-9b09-db13b6dc7031@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 16 commits:

 - Merge branch 'master' into static-jdk-image
 - Also include information about where generated data is consumed.
 - Document how and why we keep track of native libraries per module
 - Remove unnecessary change for macOS in java_md.c
 - Merge branch 'master' into static-jdk-image
 - Merge branch 'master' into static-jdk-image
 - Merge branch 'master' into static-jdk-image
 - Fix bug in filtering out -Wl,--exclude-libs,ALL
 - Don't hardcode server variant
 - Setup LDFLAGS_STATIC_JDK
 - ... and 6 more: https://git.openjdk.org/jdk/compare/b8b70c8b...783f34d3

-------------

Changes: https://git.openjdk.org/jdk/pull/20837/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=13
  Stats: 453 lines in 26 files changed: 374 ins; 5 del; 74 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From ihse at openjdk.org  Mon Nov 18 11:38:07 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 11:38:07 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v15]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <VxfRG-hXJALjFlzICTqsm_jzVgrTTwcBK67KooJeLqQ=.9d37348b-e198-4118-9dcd-98b681fa7b65@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Fix incremental builds

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/783f34d3..a6c61140

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=13-14

  Stats: 2 lines in 1 file changed: 2 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From eirbjo at openjdk.org  Mon Nov 18 11:39:54 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 11:39:54 GMT
Subject: RFR: 8178966: Don't swallow early bootstrap exceptions in
 Boolean.getBoolean, Integer.getInteger and Long.getLong
In-Reply-To: <wL6MmvNTNhgAJtZUHlNr17mItxoCAVId7JY32k83cAk=.b13ca6ba-75ec-4bb9-81e0-e10fd60b95dc@github.com>
References: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
 <wL6MmvNTNhgAJtZUHlNr17mItxoCAVId7JY32k83cAk=.b13ca6ba-75ec-4bb9-81e0-e10fd60b95dc@github.com>
Message-ID: <W4j4mheuNcdSJ5ZOmfYpO8nak-SeSRZYN14T3L2MeZQ=.579678de-263e-465f-ad1c-1024eb050f56@github.com>

On Mon, 18 Nov 2024 10:40:00 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Is this something that you want to add Peter as a contributor to, given his original proposal in the issue?

Thanks! Yes indeed, the JBS even included a patch with a suggsted change. Not sure why it was never integratd. 

> I can't think of any reason not to do this change, but it would be good to have one more review for this one. 

Yes, setting reviewers to 2 for this one :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22183#issuecomment-2482790339

From pminborg at openjdk.org  Mon Nov 18 12:45:52 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Nov 2024 12:45:52 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
Message-ID: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>

This PR proposes to use a static property already resolved instead of calling `System.getProperty()`.

-------------

Commit messages:
 - Use StaticProperty.javaHome()

Changes: https://git.openjdk.org/jdk/pull/22205/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22205&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344134
  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22205.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22205/head:pull/22205

PR: https://git.openjdk.org/jdk/pull/22205

From jvernee at openjdk.org  Mon Nov 18 12:46:57 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Mon, 18 Nov 2024 12:46:57 GMT
Subject: RFR: 8331735: UpcallLinker::on_exit races with GC when copying frame
 anchor
Message-ID: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>

There is a subtle race in `UpcallLinker::on_exit` between copying of the old frame anchor back into place, and the GC. Since this copy is not atomic, it may briefly appear as if a thread has no last Java frame, while still in the `_thread_in_native` state, which leads to the GC skipping processing of any active Java frames.

This code was originally adapted from `JavaCallWrapper::!JavaCallWrapper` - the JNI mechanism for upcalls - but in that case the frame anchor copy happens in the `_thread_in_vm` state, which means the GC will wait for the thread to get to a safepoint.

The solution proposed here is to do the frame anchor copy in the java thread state, before transitioning  back to the native state. The java thread state, like the vm thread state, is also 'safe' i.e. the GC will wait for the thread to get to a safepoint, so we can safely do our non-atomic copy of the frame anchor.

Additionally, this PR resolves a similar issue in `on_entry`, by moving the clearing of the pending exception (in case native code use a JNI API and didn't handle the exception afterwards). We now also skip checking for async exceptions when transitioning from native to java, so we don't immediately clear them. Any async exceptions will be picked up at the next safepoint instead.

Special thanks to @stefank and @fisk for finding the root cause, and @jaikiran for testing and debugging.

Testing: tier 1-4, 20k runs of the failing test on linux-aarch64.

-------------

Commit messages:
 - Merge branch 'master' into SafeFrameAnchor
 - Merge branch 'master' into SafeFrameAnchor
 - Don't touch frame anchor or current exception oop in native state

Changes: https://git.openjdk.org/jdk/pull/21742/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21742&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8331735
  Stats: 15 lines in 1 file changed: 5 ins; 9 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21742.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21742/head:pull/21742

PR: https://git.openjdk.org/jdk/pull/21742

From asemenyuk at openjdk.org  Mon Nov 18 13:29:54 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 13:29:54 GMT
Subject: RFR: 8336087: Doccheck: the jpackage command page doesn't show the
 correct command-line options
Message-ID: <EMqlFQpnM8EVIutihC6dZ-ZR8ReMDtpQKBUCplV-BEU=.39cdcc24-ff7c-4cf4-83c6-e63071b79f32@github.com>

Simple typo fix.

Old view: https://github.com/openjdk/jdk/blob/dfddbcaab886b9baa731cd748bb7f547e1903b64/src/jdk.jpackage/share/man/jpackage.md

New view: https://github.com/alexeysemenyukoracle/jdk/blob/JDK-8336087/src/jdk.jpackage/share/man/jpackage.md

Navigate to "Group value of the RPM" text to see the diff

-------------

Commit messages:
 - 8336087: Doccheck: the jpackage command page doesn't show the correct command-line options

Changes: https://git.openjdk.org/jdk/pull/22206/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22206&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8336087
  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22206.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22206/head:pull/22206

PR: https://git.openjdk.org/jdk/pull/22206

From asemenyuk at openjdk.org  Mon Nov 18 13:29:54 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 13:29:54 GMT
Subject: RFR: 8336087: Doccheck: the jpackage command page doesn't show the
 correct command-line options
In-Reply-To: <EMqlFQpnM8EVIutihC6dZ-ZR8ReMDtpQKBUCplV-BEU=.39cdcc24-ff7c-4cf4-83c6-e63071b79f32@github.com>
References: <EMqlFQpnM8EVIutihC6dZ-ZR8ReMDtpQKBUCplV-BEU=.39cdcc24-ff7c-4cf4-83c6-e63071b79f32@github.com>
Message-ID: <C7k9Iu8zokvb8JGMLekdimZMJzHUeN_sQQZ524op-og=.303d18b1-9dbd-4782-8982-7ecfe3a741f2@github.com>

On Mon, 18 Nov 2024 13:21:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Simple typo fix.
> 
> Old view: https://github.com/openjdk/jdk/blob/dfddbcaab886b9baa731cd748bb7f547e1903b64/src/jdk.jpackage/share/man/jpackage.md
> 
> New view: https://github.com/alexeysemenyukoracle/jdk/blob/JDK-8336087/src/jdk.jpackage/share/man/jpackage.md
> 
> Navigate to "Group value of the RPM" text to see the diff

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22206#issuecomment-2483039720

From asemenyuk at openjdk.org  Mon Nov 18 13:47:58 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 13:47:58 GMT
Subject: RFR: 8344322: Improve capabilities of jpackage test lib to validate
 error output of jpackage
Message-ID: <Z8rT9yMl4LFbpTnDKffpBhu9J4xiuVRsze4KxrYHnSY=.a507cdb8-8ddd-4e70-b5a9-4d6ccd67abaf@github.com>

Support using jpackage l10n keys instead of string values when examining jpackage error output.

-------------

Commit messages:
 - Comment reworded
 - Merge branch 'master' into JDK-8343876.JPackageErrorOutputVerify
 - Remove redundant "method.setAccessible(true);" calls
 - Fix finding in the review
 - Minor cleanup
 - Merge branch 'master' into JDK-8343876
 - Use "validate" instead of "verify" for the new API
 - Don't run static test methods with test instances
 - Don't create intermediate set of expected test descs for very test class when building the total set of all test descs
 - Add test case to validate static test case will be executed only once in parameterized test
 - ... and 27 more: https://git.openjdk.org/jdk/compare/dfddbcaa...521e1fd5

Changes: https://git.openjdk.org/jdk/pull/22207/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22207&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344322
  Stats: 229 lines in 5 files changed: 192 ins; 12 del; 25 mod
  Patch: https://git.openjdk.org/jdk/pull/22207.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22207/head:pull/22207

PR: https://git.openjdk.org/jdk/pull/22207

From ihse at openjdk.org  Mon Nov 18 13:57:29 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 13:57:29 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v16]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <7AJAaqfu2qc0QX0p2WYUzB73rSbPZeOwUwFAEHl0irI=.0fb2ef18-e16d-4563-98d1-2610c6f21916@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Restore SetExecname in java_md.c

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/a6c61140..de243c34

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=15
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=14-15

  Stats: 3 lines in 1 file changed: 3 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From sgehwolf at openjdk.org  Mon Nov 18 14:06:10 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Mon, 18 Nov 2024 14:06:10 GMT
Subject: RFR: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302 [v2]
In-Reply-To: <a7n2qIhrXauXNrVYRpccM_AhGkLbGc44lsyh2vkotj8=.360d434c-73bb-461c-900d-18ddece27409@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
 <a7n2qIhrXauXNrVYRpccM_AhGkLbGc44lsyh2vkotj8=.360d434c-73bb-461c-900d-18ddece27409@github.com>
Message-ID: <p3VjeBA4EnuhyptL9xatrhE5JMtasZMOjz1xFmpEz8M=.04c70dac-9d1f-4a36-9e9e-fb5e89fc8eb6@github.com>

On Mon, 18 Nov 2024 08:26:20 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

>> On AIX we run into errors below, for example in test tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug binaries, opt worked :
>> 
>> jlink options: --output java-base-with-opts-jlink-tmp --add-modules jdk.jlink,java.base --generate-linkable-runtime --keep-packaged-modules=java-base-with-opts-jlink-tmp/jmods
>> Error: Java heap space
>> java.lang.OutOfMemoryError: Java heap space
>> at java.base/java.io.InputStream.readNBytes(InputStream.java:447)
>> at java.base/java.io.InputStream.readAllBytes(InputStream.java:348)
>> at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127)
>> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.ResourcePoolReader.getResourceBytes(ResourcePoolReader.java:54)
>> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.JimageDiffGenerator.generateDiff(JimageDiffGenerator.java:89)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.addResourceDiffFiles(ImageFileCreator.java:357)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:264)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:202)
>> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:131)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:1041)
>> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:501)
>> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:294)
>> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
>> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
>> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:713)
>> at AbstractLinkableRuntimeTest.createRuntimeLinkImage(AbstractLinkableRuntimeTest.java:273)
>> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:126)
>> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:121)
>> at AddOptionsTest.runTest(AddOptionsTest.java:64)
>> at AbstractLinkableRuntimeTest.run(AbstractLinkableRuntimeTest.java:62)
>> at AddOptionsTest.main(AddOptionsTest.java:49)
>> at java.base/java.lang.invoke.LambdaForm$DMH/0x0a0001009070c3e0.invokeStatic(LambdaForm$DMH)
>> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090710c10.invoke(LambdaForm$MH)
>> at java.base/java.lang.invoke.LambdaFo...
>
> Matthias Baesken has updated the pull request incrementally with one additional commit since the last revision:
> 
>   use Xmx1400m

Seems fine to me.

-------------

Marked as reviewed by sgehwolf (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22140#pullrequestreview-2442720815

From alanb at openjdk.org  Mon Nov 18 14:10:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Nov 2024 14:10:44 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
In-Reply-To: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
Message-ID: <wxrWM6bXgTFNa1-oS27CKQUUqLFRHP4Ng-VLsucbrfs=.3c413e8f-d126-463d-bba6-e66d48b523a4@github.com>

On Mon, 18 Nov 2024 12:40:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use a static property already resolved instead of calling `System.getProperty()`.

This looks okay, makes it immune to crazy code that changes java.home.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22205#pullrequestreview-2442732099

From rgiulietti at openjdk.org  Mon Nov 18 14:16:59 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Nov 2024 14:16:59 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v17]
In-Reply-To: <KW-U-91MyntIMaUwjtxY0h21c3ZiDU0MvBZHGHplZe0=.65fcb40d-7f42-4278-acfa-a84377c81757@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <KW-U-91MyntIMaUwjtxY0h21c3ZiDU0MvBZHGHplZe0=.65fcb40d-7f42-4278-acfa-a84377c81757@github.com>
Message-ID: <zd-vraoffPK17e27kdpujyHNmPP4NFKRcJrzV7nUj9U=.952beef0-84ed-4176-a160-01b631f5a277@github.com>

On Fri, 15 Nov 2024 14:21:21 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Optimize sqrt branch for exact results

src/java.base/share/classes/java/math/BigDecimal.java line 2248:

> 2246:                             }
> 2247:                         }
> 2248:                     } else { // mc.roundingMode == RoundingMode.UP || mc.roundingMode == RoundingMode.CEILING

It would be more robust to make all enum constant explicit, and reserve the `else` to throw a `RuntimeException` of some sort, e.g., `MatchException`. Should an additional enum constant be added to `RoundingMode` in the future, this code will then throw instead of silently producing a wrong result.

If possible at all, it would be preferable to use a `switch` rather than `if`s.

src/java.base/share/classes/java/math/RoundingMode.java line 425:

> 423:             default -> false;
> 424:         };
> 425:     }

For this PR, it would be preferable to move this method as a private static in BigDecimal itself, even if its usefulness is more broad.

Also, I suggest making all the cases explicit, like so

Suggestion:

    private static boolean isHalfWay(RoundingMode m) {
        return switch (m) {
            case HALF_DOWN, HALF_UP, HALF_EVEN -> true;
            case FLOOR, CEILING, DOWN, UP, UNNECESSARY -> false;
        };
    }


In this way, should another enum constant be added in the future, the method will throw instead of silently returning a wrong value, indicating that a new case must be added to the switch for it to be exhaustive. (There's a hidden `default` that throws.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1846658170
PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1846627164

From rgiulietti at openjdk.org  Mon Nov 18 14:23:49 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Mon, 18 Nov 2024 14:23:49 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v17]
In-Reply-To: <zd-vraoffPK17e27kdpujyHNmPP4NFKRcJrzV7nUj9U=.952beef0-84ed-4176-a160-01b631f5a277@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <KW-U-91MyntIMaUwjtxY0h21c3ZiDU0MvBZHGHplZe0=.65fcb40d-7f42-4278-acfa-a84377c81757@github.com>
 <zd-vraoffPK17e27kdpujyHNmPP4NFKRcJrzV7nUj9U=.952beef0-84ed-4176-a160-01b631f5a277@github.com>
Message-ID: <wrIrBVSNEeOc4aMpWPmb_Z8whdxn40geeFn_JUhrl5g=.e2d75a9c-12a9-4409-bdd1-2badb392bdff@github.com>

On Mon, 18 Nov 2024 14:11:43 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Optimize sqrt branch for exact results
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2248:
> 
>> 2246:                             }
>> 2247:                         }
>> 2248:                     } else { // mc.roundingMode == RoundingMode.UP || mc.roundingMode == RoundingMode.CEILING
> 
> It would be more robust to make all enum constant explicit, and reserve the `else` to throw a `RuntimeException` of some sort, e.g., `MatchException`. Should an additional enum constant be added to `RoundingMode` in the future, this code will then throw instead of silently producing a wrong result.
> 
> If possible at all, it would be preferable to use a `switch` rather than `if`s.

Also, please merge master into this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1846673296

From ihse at openjdk.org  Mon Nov 18 14:40:03 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 14:40:03 GMT
Subject: RFR: 8331497: Implement JEP 483: Ahead-of-Time Class Loading &
 Linking [v14]
In-Reply-To: <TKeSI9gfuvj3iZ3wYeoQ7npTzMP8NsxQNgUe77nCc-8=.943e25a1-e8be-4fac-8ac7-c2feeb9e707f@github.com>
References: <jpsnN41rStn3U6zyvpjWulfiYWxbonAWQfTyWlfF4oA=.b788997b-aa7e-45dd-8473-948e9cd9b055@github.com>
 <TKeSI9gfuvj3iZ3wYeoQ7npTzMP8NsxQNgUe77nCc-8=.943e25a1-e8be-4fac-8ac7-c2feeb9e707f@github.com>
Message-ID: <e9PnGOzhmml54wvt2NaYCykFojaA4vVdzDgAKjfTWag=.b8f50a5e-3706-4dd2-b1b5-e88764e41299@github.com>

On Fri, 15 Nov 2024 16:38:20 GMT, Ioi Lam <iklam at openjdk.org> wrote:

>> This is an implementation of [JEP 483: Ahead-of-Time Class Loading & Linking](https://openjdk.org/jeps/483).
>> 
>> ----
>> Note: this is a combined PR of the following individual PRs
>> - https://github.com/openjdk/jdk/pull/20516
>> - https://github.com/openjdk/jdk/pull/20517
>> - https://github.com/openjdk/jdk/pull/20843
>> - https://github.com/openjdk/jdk/pull/20958
>> - https://github.com/openjdk/jdk/pull/20959
>> - https://github.com/openjdk/jdk/pull/21049
>> - https://github.com/openjdk/jdk/pull/21143
>
> Ioi Lam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fixed test after security manager removal

make/RunTests.gmk line 706:

> 704: endef
> 705: 
> 706: 

This PR was not tagged with the `build` label, and was therefore not brought to the attention of the build team.

This file contains a large number of unacceptable changes. :-( It would under no circumstance have been approved as it looks. 

Please make sure that the Github labels actually matches the set of files that are changed in the PR. Skara tooling will assist in this, but the ultimate responsibility lies with the Author and Reviewers of the PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21642#discussion_r1846696988

From asemenyuk at openjdk.org  Mon Nov 18 14:40:53 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 14:40:53 GMT
Subject: RFR: 8344322: Improve capabilities of jpackage test lib to
 validate error output of jpackage
In-Reply-To: <Z8rT9yMl4LFbpTnDKffpBhu9J4xiuVRsze4KxrYHnSY=.a507cdb8-8ddd-4e70-b5a9-4d6ccd67abaf@github.com>
References: <Z8rT9yMl4LFbpTnDKffpBhu9J4xiuVRsze4KxrYHnSY=.a507cdb8-8ddd-4e70-b5a9-4d6ccd67abaf@github.com>
Message-ID: <-JZyIwelErdZRkMtiWd-6f_RRAqIJQ5-0CvKoe-B38E=.c5293690-800e-448a-96f9-96ada5e31251@github.com>

On Mon, 18 Nov 2024 13:41:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Support using jpackage l10n keys instead of string values when examining jpackage error output.

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22207#issuecomment-2483240933

From rriggs at openjdk.org  Mon Nov 18 14:58:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 14:58:09 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <VvC4fSK1bQ0zHD1v2W2Odv3-aAE6DbxwI_h0rh95E1Y=.4fa68137-fe71-4c48-8052-badb1cc502d1@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22162#pullrequestreview-2442860753

From rriggs at openjdk.org  Mon Nov 18 15:03:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 15:03:51 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <S4Volj3cwQpFfR8lpER2ZLXY8VeeNdeizuZ3GGzao8c=.0af11192-207c-475b-8e75-432d4c7b1ad1@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
 <S4Volj3cwQpFfR8lpER2ZLXY8VeeNdeizuZ3GGzao8c=.0af11192-207c-475b-8e75-432d4c7b1ad1@github.com>
Message-ID: <cJkQOrAuVcg-FtVPQOctxUxlzYMaSPSUhBjQu_s2C50=.debd52f4-d7a7-4ef4-b502-34f1ace33969@github.com>

On Fri, 15 Nov 2024 22:43:13 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>
> src/java.base/share/classes/java/lang/System.java line 1336:
> 
>> 1334:         }
>> 1335: 
>> 1336:         private static Void checkPermission() {
> 
> Seems unused?

Cleanup of the Logger should remove the use in `LoggerFinder()`

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22168#discussion_r1846740457

From rriggs at openjdk.org  Mon Nov 18 15:11:46 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 15:11:46 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <280hRVhkkj5Qio59CpMkhpMF9un2_o9VLBCnuLHHIJQ=.41491d89-4fc5-408f-9c2a-9c3f5bbe3149@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
 <280hRVhkkj5Qio59CpMkhpMF9un2_o9VLBCnuLHHIJQ=.41491d89-4fc5-408f-9c2a-9c3f5bbe3149@github.com>
Message-ID: <vdl9qCosi672Cdg7sUYvx3oMcl4vo7XK8QKxDbeydUY=.278ae574-2e98-4e0a-b538-796d3ff8c784@github.com>

On Mon, 18 Nov 2024 00:16:00 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>
> src/java.base/share/classes/java/lang/String.java line 691:
> 
>> 689:                     System.getSecurityManager() != null) {
>> 690:                 bytes = Arrays.copyOfRange(bytes, offset, offset + length);
>> 691:                 offset = 0;
> 
> Was this defensive copy particularly important to security managers but has no effect for other scenarios?

Application supplied Charsets are not any more or less trusted than any other class in the application.
So the copy is not (adequately) effective as a defensive measure here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22168#discussion_r1846753458

From ihse at openjdk.org  Mon Nov 18 15:12:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 15:12:12 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v17]
In-Reply-To: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
Message-ID: <YIPIccykqXpQc2UGuoaE99ZabdrBSYRpOrAWg721qus=.cbd8ae38-2631-479a-a915-ca17f3ab8707@github.com>

> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
> 
> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
> 
> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:

  Copy debuginfo

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/20837/files
  - new: https://git.openjdk.org/jdk/pull/20837/files/de243c34..41d37075

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=20837&range=15-16

  Stats: 53 lines in 3 files changed: 31 ins; 21 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/20837.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20837/head:pull/20837

PR: https://git.openjdk.org/jdk/pull/20837

From ihse at openjdk.org  Mon Nov 18 15:12:12 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 15:12:12 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v16]
In-Reply-To: <7AJAaqfu2qc0QX0p2WYUzB73rSbPZeOwUwFAEHl0irI=.0fb2ef18-e16d-4563-98d1-2610c6f21916@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <7AJAaqfu2qc0QX0p2WYUzB73rSbPZeOwUwFAEHl0irI=.0fb2ef18-e16d-4563-98d1-2610c6f21916@github.com>
Message-ID: <HjVPmkP2TZQOcHONfvfqBCHWc_9UYB-0qJmWqElbp_E=.1d1d6168-b4e9-4bd4-8a76-3e3d5b823537@github.com>

On Mon, 18 Nov 2024 13:57:29 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Restore SetExecname in java_md.c

I think I have addressed all known outstanding issues with this PR, and that it is ready for final review and integration.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2483323302

From rriggs at openjdk.org  Mon Nov 18 15:18:04 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 15:18:04 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
In-Reply-To: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
Message-ID: <8EKVH1JYL8EZvKdvDMARCQZXyfJ5-TMVFvHOqF4nNtM=.10e63616-5a90-40f0-8a20-e51aed7dc3b7@github.com>

On Mon, 18 Nov 2024 12:40:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use a static property already resolved instead of calling `System.getProperty()`.

Looks good. Thanks

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22205#pullrequestreview-2442915374

From eirbjo at openjdk.org  Mon Nov 18 15:27:42 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 15:27:42 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
In-Reply-To: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
Message-ID: <NRiwItd5VUMkK6Zeiui8tjwpc6HK6gd0vYh3pfZVMp0=.d3eb43a6-2b0d-4d57-8366-bb5cfcbe390e@github.com>

On Mon, 18 Nov 2024 12:40:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use a static property already resolved instead of calling `System.getProperty()`.

Drive by observation: In java.base, there are four similar instances in `ImageReaderFactory.JAVA_HOME`, `SystemImage::findHome`, `CDS::dumpSharedArchive` and `DomainName::getPubSuffixStream`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22205#issuecomment-2483368727

From rriggs at openjdk.org  Mon Nov 18 15:32:54 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 15:32:54 GMT
Subject: RFR: 8178966: Don't swallow early bootstrap exceptions in
 Boolean.getBoolean, Integer.getInteger and Long.getLong
In-Reply-To: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
References: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
Message-ID: <tYS0tAUhoyz53p3ZfCsacVLXvpIcb88OXNLk_Xu4ys0=.d43b8cac-403c-4eab-8ce9-6197b3be8694@github.com>

On Sun, 17 Nov 2024 14:52:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes exceptional control flow in `Boolean::getBoolean`, `Integer::getInteger` and `Long::getLong`.
> 
> These methods are catching `IllegalArgumentException` and `NullPointerException`, thrown by `System::getProperty` via `System::checkKey`. This PR replaces the exceptional control flow with explicit checks that the system property name is non-null and non-empty before calling into `System::getProperty`.
> 
> As JDK-8178966 points out, there is a possibility that System.getProperty could throw one of NPE and IAE for other reasons than the name being null or empty. This risk is reduced now that custom security managers cannot interfere. Adding to that, if such exceptions are thrown today, they are masked by these methods catching and swallowing them by returning false or default values. It's better to expose such  bugs if they exist.
> 
> GHA results pending. Local tier2 ran successfully.

Circumventing and duplicating the checks in System.getProperty isn't good coding technique and is not necessary for performance improvement or code size.

-------------

Changes requested by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22183#pullrequestreview-2442959716

From cstein at openjdk.org  Mon Nov 18 15:42:38 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 18 Nov 2024 15:42:38 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
Message-ID: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>

Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

-------------

Commit messages:
 - 8293040: Argfile documentation for java launcher tool is confusing regarding usage of wildcards

Changes: https://git.openjdk.org/jdk/pull/22208/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22208&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8293040
  Stats: 3 lines in 1 file changed: 2 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22208.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22208/head:pull/22208

PR: https://git.openjdk.org/jdk/pull/22208

From eirbjo at openjdk.org  Mon Nov 18 15:46:02 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 15:46:02 GMT
Subject: RFR: 8178966: Don't swallow early bootstrap exceptions in
 Boolean.getBoolean, Integer.getInteger and Long.getLong
In-Reply-To: <tYS0tAUhoyz53p3ZfCsacVLXvpIcb88OXNLk_Xu4ys0=.d43b8cac-403c-4eab-8ce9-6197b3be8694@github.com>
References: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
 <tYS0tAUhoyz53p3ZfCsacVLXvpIcb88OXNLk_Xu4ys0=.d43b8cac-403c-4eab-8ce9-6197b3be8694@github.com>
Message-ID: <GXlgau8n1eLXXnCd19MosF0wkP_3_1j7Ny543jVmuBg=.2230863a-17c4-4fa1-a5f7-9e925062220e@github.com>

On Mon, 18 Nov 2024 15:30:15 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Circumventing and duplicating the checks in System.getProperty isn't good coding technique and is not necessary for performance improvement or code size.

My understanding of JDK-8178966 is that the motivation was correctness rather than performance. 

`Boolean::getBoolean` and friends are not specified to throw `IAE` or `NPE`, but to return false `if the specified name is empty or {@code null}`. So the implementation must either check for null and emptiness, or it must catch the exceptions and hope they came from `System::checkKey` and nothing else.

I'm not sure what your alternative solution is here? Drop the PR / issue?

We can't simply drop the null and emptiness checks, since that could throw unspecified IAE/NPE.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22183#issuecomment-2483416370

From jlahoda at openjdk.org  Mon Nov 18 15:50:49 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Nov 2024 15:50:49 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v9]
In-Reply-To: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
Message-ID: <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>

> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
> 
> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
> 
> openjdk 24-internal 2025-03-18
> 
> Usage: java [java options...] <application> [application arguments...]
> 
> Where <application> is one of:
>   <mainclass>                to execute the main method of a compiled class
>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>   -m <module>[/<mainclass>]  to execute the main class of a module
>   <sourcefile>.java          to compile and execute a source-file program
> 
> Where key java options include:
>   --class-path <class path>
>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>   --module-path <module path>
>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
> 
> For additional help on usage:           java --help
> For an interactive Java environment:    jshell
> 
> 
> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
> 
> What do you think?
> 
> Thanks!

Jan Lahoda 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 'master' into JDK-8340133-2
 - - suffixing <jarfile> and <sourcefile> with .jar and .java in both the concise and full help.
   - using a stderr version instead of the stdout version.
 - Reflecting review feedback:
   - using "conciseVersionString" intead of "shortVersionString"
   - using <jarfile>.jar <jarfile>
 - Merge branch 'master' into JDK-8340133-2
 - Using correct pplaceholders.
 - Adjusting text as suggested.
 - Cleaning up the concise message:
   - using 2 spaces instead of 4,
   - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
 - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
 - Using an enum instead of booleans, as suggested.
 - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
 - ... and 4 more: https://git.openjdk.org/jdk/compare/dfddbcaa...439fa40f

-------------

Changes: https://git.openjdk.org/jdk/pull/21411/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21411&range=08
  Stats: 124 lines in 6 files changed: 63 ins; 2 del; 59 mod
  Patch: https://git.openjdk.org/jdk/pull/21411.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21411/head:pull/21411

PR: https://git.openjdk.org/jdk/pull/21411

From ihse at openjdk.org  Mon Nov 18 15:51:57 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 15:51:57 GMT
Subject: Withdrawn: 8333268: Fixes for static build
In-Reply-To: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
References: <S6ajdzuJF5_bbTkPPBN3OqBtygw-akaFlAJY2A4RXYw=.3175c31d-38b1-465b-94bd-763992e9237b@github.com>
Message-ID: <cWSH2ztjo93kaqennPJ8iBAWxfSgTeHk-PkFAtCztGU=.c8d3f1c9-93f4-4953-b4d5-1664b4d9f0ae@github.com>

On Thu, 30 May 2024 13:00:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> This patch contains a set of changes to improve static builds. They will pave the way for implementing a full static-only java launcher. The changes here will:
> 
> 1) Make sure non-exported symbols are made local in the static libraries. This means that the risk of symbol conflict is the same for static libraries as for dynamic libraries (i.e. in practice zero, as long as a consistent naming scheme is used for exported functions).
> 
> 2) Remove the work-arounds to exclude duplicated symbols.
> 
> 3) Fix some code in hotspot and the JDK libraries that did not work properly with a static java launcher.
> 
> The latter fixes are copied from or inspired by the work done by @jianglizhou and her team as part of the Project Leyden [Hermetic Java](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/19478

From vklang at openjdk.org  Mon Nov 18 15:52:47 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 18 Nov 2024 15:52:47 GMT
Subject: RFR: 8344253: Test
 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed
Message-ID: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>

This change now halves each side of the split regardless, the old code would end up in a situation where it wouldn't decrement since unsigned shift right twice would lead to decrementing estimated size by 0.

It's worth noting the probabilistic nature of skip lists and that their spliterators are not SIZED and their estimatedSize() is therefor not to be relied upon for deterministic correctness.

-------------

Commit messages:
 - Correcting the size estimation for ConcurrentSkipListMap spliterators

Changes: https://git.openjdk.org/jdk/pull/22210/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22210&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344253
  Stats: 3 lines in 1 file changed: 0 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22210.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22210/head:pull/22210

PR: https://git.openjdk.org/jdk/pull/22210

From vklang at openjdk.org  Mon Nov 18 15:52:47 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 18 Nov 2024 15:52:47 GMT
Subject: RFR: 8344253: Test
 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed
In-Reply-To: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
References: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
Message-ID: <G7XxBUqjnsK7H7VNxdZK_Rsy4-y0Im-coGh7w209bcQ=.21de3a61-1164-44e6-83b0-21cca8b82f23@github.com>

On Mon, 18 Nov 2024 15:46:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change now halves each side of the split regardless, the old code would end up in a situation where it wouldn't decrement since unsigned shift right twice would lead to decrementing estimated size by 0.
> 
> It's worth noting the probabilistic nature of skip lists and that their spliterators are not SIZED and their estimatedSize() is therefor not to be relied upon for deterministic correctness.

@DougLea @AlanBateman FYI

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22210#issuecomment-2483426539

From asemenyuk at openjdk.org  Mon Nov 18 15:53:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 15:53:03 GMT
Subject: RFR: 8342299: Document that jpackage includes (possibly old) VC
 Redistributable MSVCP140.dll from JDK
In-Reply-To: <n7qPzuZYqFKRPTrTsndU-0g3rCDM44gd4Ywm33Rax5A=.147dd696-e7b9-4f10-b494-27b60c9fb30c@github.com>
References: <n7qPzuZYqFKRPTrTsndU-0g3rCDM44gd4Ywm33Rax5A=.147dd696-e7b9-4f10-b494-27b60c9fb30c@github.com>
Message-ID: <CUZz832o0Lg1pweCEaPlwUlcbGv9_553YPQN5zf9E94=.ffe9f226-7fb6-4849-ac19-8465f0c3a241@github.com>

On Mon, 18 Nov 2024 15:45:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage man page update

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22209#issuecomment-2483435507

From asemenyuk at openjdk.org  Mon Nov 18 15:53:03 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 15:53:03 GMT
Subject: RFR: 8342299: Document that jpackage includes (possibly old) VC
 Redistributable MSVCP140.dll from JDK
Message-ID: <n7qPzuZYqFKRPTrTsndU-0g3rCDM44gd4Ywm33Rax5A=.147dd696-e7b9-4f10-b494-27b60c9fb30c@github.com>

jpackage man page update

-------------

Commit messages:
 - Better wording
 - 8342299: Document that jpackage includes (possibly old) VC Redistributable MSVCP140.dll from JDK

Changes: https://git.openjdk.org/jdk/pull/22209/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22209&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342299
  Stats: 8 lines in 1 file changed: 8 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22209.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22209/head:pull/22209

PR: https://git.openjdk.org/jdk/pull/22209

From jlahoda at openjdk.org  Mon Nov 18 16:00:52 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Nov 2024 16:00:52 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v9]
In-Reply-To: <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>
Message-ID: <lHowWkK0Ha7i4dwuxCp6vWZN0-AIrNiRVlpMMPfXpcA=.90b02659-dcd5-4fe5-9ac3-e8888be60c11@github.com>

On Mon, 18 Nov 2024 15:50:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk version "24-internal" 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled main class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda 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 'master' into JDK-8340133-2
>  - - suffixing <jarfile> and <sourcefile> with .jar and .java in both the concise and full help.
>    - using a stderr version instead of the stdout version.
>  - Reflecting review feedback:
>    - using "conciseVersionString" intead of "shortVersionString"
>    - using <jarfile>.jar <jarfile>
>  - Merge branch 'master' into JDK-8340133-2
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.
>  - Cleaning up the concise message:
>    - using 2 spaces instead of 4,
>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>  - Using an enum instead of booleans, as suggested.
>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/dfddbcaa...439fa40f

I am a bit confused about what's the recommendation about the version, as there seem to be conflicting comments on that . I replaced the version with the stderr version here:
https://github.com/openjdk/jdk/pull/21411/commits/d4860961e2ff7e6218a16a2ed3990a0deba3ae1a

I can drop the version altogether if/as desired.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2483456980

From jlahoda at openjdk.org  Mon Nov 18 16:00:53 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Mon, 18 Nov 2024 16:00:53 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <zVIkkJgsKJjmTkMhdCALT9j40KNVz2ShIwX8HQCSBQE=.c73ba1fe-2bd4-4608-9382-f0796b31505f@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
 <A0B6qDEx6Ib2WKeIxBs-f9fIGTMedalFjvxCIvXQ74g=.2cb99e10-4e92-4225-bcb3-22273c1106a4@github.com>
 <zVIkkJgsKJjmTkMhdCALT9j40KNVz2ShIwX8HQCSBQE=.c73ba1fe-2bd4-4608-9382-f0796b31505f@github.com>
Message-ID: <8bsRmYUMq4JicTqyl3RCDqgYvRyldEoh7772V9YI1Wk=.135e7a17-aed0-454f-a95d-49225352c51a@github.com>

On Tue, 12 Nov 2024 15:34:16 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>>> @AlanBateman I'd like to respectfully disagree that this was an improvement. If consistency was the important objection here, maybe it would have been better to update "java -help" to include the .jar?
>> 
>> I assume your disagreement is with Jan's latest update rather than my comment. My comment was just pointing out that it's confusing to use `-jar <jarfile>.jar` in one case and `-jar <jarfile>` in the other.
>
> So, just to double-check: given the request is to make the helps consistent, and dropping the extensions from the concise help is not what was meant, I'll add the extensions both here and to the ordinary help. Correct?

Done here:
https://github.com/openjdk/jdk/pull/21411/commits/d4860961e2ff7e6218a16a2ed3990a0deba3ae1a

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1846850656

From alanb at openjdk.org  Mon Nov 18 16:10:48 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Mon, 18 Nov 2024 16:10:48 GMT
Subject: RFR: 8344253: Test
 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed
In-Reply-To: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
References: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
Message-ID: <Gw4im1ngVAv29vrYhtPuL0E6X6Tl2rbMO7ka_5Tml7w=.59c3e8cb-f558-49e1-9e40-fff5e1e644d2@github.com>

On Mon, 18 Nov 2024 15:46:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change now halves each side of the split regardless, the old code would end up in a situation where it wouldn't decrement since unsigned shift right twice would lead to decrementing estimated size by 0.
> 
> It's worth noting the probabilistic nature of skip lists and that their spliterators are not SIZED and their estimatedSize() is therefor not to be relied upon for deterministic correctness.

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22210#pullrequestreview-2443081660

From duke at openjdk.org  Mon Nov 18 16:12:52 2024
From: duke at openjdk.org (Billy Korando)
Date: Mon, 18 Nov 2024 16:12:52 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
Message-ID: <EJvhbWfqAoWPCB2ESd_moIahsbH8n4fB0xX9qJDp8gs=.423b5ea7-a1d1-4524-a914-449be7d76c0c@github.com>

On Mon, 18 Nov 2024 15:22:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

Marked as reviewed by wkorando at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22208#pullrequestreview-2443088489

From rriggs at openjdk.org  Mon Nov 18 16:13:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 16:13:27 GMT
Subject: RFR: 8344319: SM cleanup in jdk.dynalink module [v2]
In-Reply-To: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
References: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
Message-ID: <j48UHyLK6C8bju1CTRaOC7QY5wq5Jeb9KRQcPUhcBLY=.1309622f-c344-4dac-acfc-6857ef951995@github.com>

> Refactor to remove use of SecurityManager

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Apply review comments:
  Retain public static constants for permission names to avoid source/binary compatible changes that affect cross version use.
  Remove obsolete mention of security considerations.
  (The protected constructor is retained to avoid changing the access for subclass use)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22152/files
  - new: https://git.openjdk.org/jdk/pull/22152/files/7ab08ccd..a75af80f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22152&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22152&range=00-01

  Stats: 22 lines in 4 files changed: 13 ins; 7 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22152.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22152/head:pull/22152

PR: https://git.openjdk.org/jdk/pull/22152

From rriggs at openjdk.org  Mon Nov 18 16:13:27 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 16:13:27 GMT
Subject: RFR: 8344319: SM cleanup in jdk.dynalink module [v2]
In-Reply-To: <lNYFBGkoInEWGNJboEldmaL2DPTGK2xlNp6onJkfRA8=.f0b1385b-bb66-4147-bf15-e6dffe6f7334@github.com>
References: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
 <lNYFBGkoInEWGNJboEldmaL2DPTGK2xlNp6onJkfRA8=.f0b1385b-bb66-4147-bf15-e6dffe6f7334@github.com>
Message-ID: <trnGMre-yZDz6s-x2yj5bXd1_W7v7wyQfKi1qfTSNog=.01369895-5c84-4a7b-b167-6a1769ad9f05@github.com>

On Sat, 16 Nov 2024 15:24:03 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review comments:
>>   Retain public static constants for permission names to avoid source/binary compatible changes that affect cross version use.
>>   Remove obsolete mention of security considerations.
>>   (The protected constructor is retained to avoid changing the access for subclass use)
>
> src/jdk.dynalink/share/classes/jdk/dynalink/SecureLookupSupplier.java line 46:
> 
>> 44:      * {@link #getLookup()} method.
>> 45:      */
>> 46:     public static final String GET_LOOKUP_PERMISSION_NAME = "dynalink.getLookup";
> 
> This public member is [referenced from Nashorn](https://github.com/search?q=repo%3Aopenjdk%2Fnashorn%20GET_LOOKUP_PERMISSION_NAME&type=code). If we remove it, Nashorn will have to attempt to look it up reflectively as long as it supports older versions of Java. (Presuming the `java.security.AccessController` and related classes aren't also removed altogether. Are they?)
> 
> FWIW, as long as we're making breaking changes, this whole class could be removed ? all it did was serve as a secure gate to access to a `MethodHandles.Lookup`. References to it could be replaced by the lookup object itself. I can understand if this might be too much work for this PR, though.
> 
> On the other hand, if we do _not_ remove the whole class, I'd prefer to keep the public string constant for the permission name so that we don't break binary compatibility for whoever might be referencing it (specifically, Nashorn.)

Agreed, it is cleaner to retain the permission names in the public API.

> src/jdk.dynalink/share/classes/jdk/dynalink/linker/GuardingDynamicLinkerExporter.java line 65:
> 
>> 63:         if (sm != null) {
>> 64:             sm.checkPermission(AUTOLOAD_PERMISSION);
>> 65:         }
> 
> We can probably remove the whole empty default constructor now. The class is abstract, the autogenerated default constructor will be protected anyway.

Keeping the explicitly declared constructor for clarity.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22152#discussion_r1846872687
PR Review Comment: https://git.openjdk.org/jdk/pull/22152#discussion_r1846873840

From rriggs at openjdk.org  Mon Nov 18 16:20:13 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 16:20:13 GMT
Subject: Integrated: 8344034: Remove security manager dependency in
 Serialization
In-Reply-To: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
References: <KSDuNYd4aMaQVQol7gKN2AB9ttdhy0Sa6bEdKmMWQd0=.0cd5d8ae-6138-4d3d-b675-a0b675153503@github.com>
Message-ID: <HeohEtxeuN40iH_z750o0rGbxHhjWaPtYCM3LBNjkUU=.7e8328a9-b9b9-4340-8ba9-bf7e4e445bda@github.com>

On Tue, 12 Nov 2024 15:09:23 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> After [JDK-8338411](https://bugs.openjdk.org/browse/JDK-8338411), Serialization implementation dependencies on SecurityManager, doPrivildged, and AccessController are removed.
> Some refactoring to cleanup the remaining code is expected.

This pull request has now been integrated.

Changeset: 9b0ab92b
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/9b0ab92b16f682e65e9847e8127b6ce09fc5759c
Stats:     421 lines in 7 files changed: 7 ins; 320 del; 94 mod

8344034: Remove security manager dependency in Serialization

Reviewed-by: mullan, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22041

From pminborg at openjdk.org  Mon Nov 18 16:23:49 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Nov 2024 16:23:49 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
In-Reply-To: <NRiwItd5VUMkK6Zeiui8tjwpc6HK6gd0vYh3pfZVMp0=.d3eb43a6-2b0d-4d57-8366-bb5cfcbe390e@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
 <NRiwItd5VUMkK6Zeiui8tjwpc6HK6gd0vYh3pfZVMp0=.d3eb43a6-2b0d-4d57-8366-bb5cfcbe390e@github.com>
Message-ID: <qtkA7OFoQPHF0J4Q2M5k8HXGpy_npMILFhKaS271sSs=.d1dd887c-198a-4144-9852-57af664c104e@github.com>

On Mon, 18 Nov 2024 15:25:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Drive by observation: In java.base, there are four similar instances in `ImageReaderFactory.JAVA_HOME`, `SystemImage::findHome`, `CDS::dumpSharedArchive` and `DomainName::getPubSuffixStream`.

Good find: Let's fix them under this issue: https://bugs.openjdk.org/browse/JDK-8344419

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22205#issuecomment-2483508936

From pminborg at openjdk.org  Mon Nov 18 16:23:49 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Mon, 18 Nov 2024 16:23:49 GMT
Subject: Integrated: 8344134: Use static property in SystemLookup
In-Reply-To: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
Message-ID: <SSFxD53k-Xh-Id8Klqlba4zEJDQ6UIVob5VA9VYhep4=.6833aa77-9a7b-49ac-989e-3f3e9263d5fd@github.com>

On Mon, 18 Nov 2024 12:40:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use a static property already resolved instead of calling `System.getProperty()`.

This pull request has now been integrated.

Changeset: 20783295
Author:    Per Minborg <pminborg at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/207832952be3e57faf3db9303d492faa391d507c
Stats:     2 lines in 1 file changed: 1 ins; 0 del; 1 mod

8344134: Use static property in SystemLookup

Reviewed-by: alanb, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/22205

From liach at openjdk.org  Mon Nov 18 16:28:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 16:28:00 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry
In-Reply-To: <UsWuxzhC_BjzIcX5ooaEN1SOfg9RjWgc_VwTFsSMbtA=.45d9e5a3-d1ea-483e-8d95-89e778755fef@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <dolTFlm-5GyQV66gwSjwxJX4_J_O6ofMliOwHX6LimA=.67ea06df-8eee-4478-b5e3-1b4a476e734c@github.com>
 <UsWuxzhC_BjzIcX5ooaEN1SOfg9RjWgc_VwTFsSMbtA=.45d9e5a3-d1ea-483e-8d95-89e778755fef@github.com>
Message-ID: <V2pp-LOwRiaMbmelLE-eKe9nmvsZwf4UXd5L1r17Xw4=.ae4d9dac-35b9-4562-8f9d-e72573653fd9@github.com>

On Mon, 28 Oct 2024 06:05:50 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> To get a JBS issue, please open a bug report about this typo in https://bugs.java.com/bugdatabase/. Also follow https://openjdk.org/guide for the rest of the steps for contributions.
>
>> To get a JBS issue, please open a bug report about this typo in https://bugs.java.com/bugdatabase/. Also follow https://openjdk.org/guide for the rest of the steps for contributions.
> 
> Thank you for your response @liach, I have
> - [x] filed the bug and referenced its ID
> - [x] signed the [OCA](https://oca.opensource.oracle.com/) and waiting for its approval
> 
> Please help me understand whom to add as a reviewer (and how) for such changes.

@namannigam FYI you need to issue a `/integrate` command in a comment if you want to merge this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2483523904

From rriggs at openjdk.org  Mon Nov 18 16:55:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 16:55:16 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <OnlvEK_xhBcq-8TkkcVtp24xtqOLIDf-SoGed-WSXjE=.87a1209b-09f3-43d1-9ab3-12e1c9f1c44c@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

CSR created, please review: [JDK-8344423](https://bugs.openjdk.org/browse/JDK-8344423)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2483587242

From smarks at openjdk.org  Mon Nov 18 17:05:40 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 18 Nov 2024 17:05:40 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
Message-ID: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>

First cut at removal of Security Manager stuff from RMI.

This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).

Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff.

-------------

Commit messages:
 - First cut at removal of Security Manager stuff from RMI.

Changes: https://git.openjdk.org/jdk/pull/22129/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22129&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344149
  Stats: 717 lines in 27 files changed: 6 ins; 549 del; 162 mod
  Patch: https://git.openjdk.org/jdk/pull/22129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22129/head:pull/22129

PR: https://git.openjdk.org/jdk/pull/22129

From vklang at openjdk.org  Mon Nov 18 17:08:53 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 18 Nov 2024 17:08:53 GMT
Subject: RFR: 8344253: Test
 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed
In-Reply-To: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
References: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
Message-ID: <gcSm1mSzhqppXt8p2hNPt9hxywo_mbwCHpWqv663zeI=.8ca0d78d-fb21-46bd-a21e-2166b7ef6531@github.com>

On Mon, 18 Nov 2024 15:46:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change now halves each side of the split regardless, the old code would end up in a situation where it wouldn't decrement since unsigned shift right twice would lead to decrementing estimated size by 0.
> 
> It's worth noting the probabilistic nature of skip lists and that their spliterators are not SIZED and their estimatedSize() is therefor not to be relied upon for deterministic correctness.

@kabutz This one popped up as a consequence of the improvements to the CSLM spliterators, just tagging you here for knowledge.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22210#issuecomment-2483620502

From nbenalla at openjdk.org  Mon Nov 18 17:18:18 2024
From: nbenalla at openjdk.org (Nizar Benalla)
Date: Mon, 18 Nov 2024 17:18:18 GMT
Subject: RFR: 8343598: Since Checker can mark some preview elements as new even
 if bytecode reference is identical
Message-ID: <_ynHDCQaQ6MOs0P_Tr8DdDke4j6jmokZFHin56WS2vQ=.1a6888b9-38e8-45fc-88ac-e54abfcc72cf@github.com>

Can I get a review for this test only change to the Since Checker?

I drop the distinction between classes and interfaces when generating ids and use a generic name "class" to describe both, as to not consider classes that get converted to interfaces (and vice versa) as new API (Something that may happen to APIs in preview).

TIA.

-------------

Commit messages:
 - drop uses of "interface:"

Changes: https://git.openjdk.org/jdk/pull/22213/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22213&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343598
  Stats: 12 lines in 1 file changed: 0 ins; 4 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22213.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22213/head:pull/22213

PR: https://git.openjdk.org/jdk/pull/22213

From duke at openjdk.org  Mon Nov 18 17:29:56 2024
From: duke at openjdk.org (kabutz)
Date: Mon, 18 Nov 2024 17:29:56 GMT
Subject: RFR: 8344253: Test
 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed
In-Reply-To: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
References: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
Message-ID: <THZYc0GWrFDCP9zSlIGxnU067IroxtJrH2_duD8T8yA=.a9e07ec8-8356-4d65-8064-ef78a7222ece@github.com>

On Mon, 18 Nov 2024 15:46:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change now halves each side of the split regardless, the old code would end up in a situation where it wouldn't decrement since unsigned shift right twice would lead to decrementing estimated size by 0.
> 
> It's worth noting the probabilistic nature of skip lists and that their spliterators are not SIZED and their estimatedSize() is therefor not to be relied upon for deterministic correctness.

Nice, good catch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22210#issuecomment-2483672606

From kevinw at openjdk.org  Mon Nov 18 17:32:55 2024
From: kevinw at openjdk.org (Kevin Walls)
Date: Mon, 18 Nov 2024 17:32:55 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
Message-ID: <JkewJ7z5vqR-YotscCJ0SvKDdrTmBka4bqJb_IqLSMk=.76a0b577-224f-4ea3-98e3-3c636703040c@github.com>

On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> First cut at removal of Security Manager stuff from RMI.
> 
> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
> 
> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff.

Looks good to me. 8-)

-------------

Marked as reviewed by kevinw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22129#pullrequestreview-2443275232

From vklang at openjdk.org  Mon Nov 18 17:34:15 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Mon, 18 Nov 2024 17:34:15 GMT
Subject: Integrated: 8344253: Test
 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed
In-Reply-To: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
References: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
Message-ID: <d8HpvSKYYLv2NrJA6jAFunI2sN9gH4pr-TyWCTvifSY=.30d0f1f0-d069-49aa-aace-c2a600d707a5@github.com>

On Mon, 18 Nov 2024 15:46:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change now halves each side of the split regardless, the old code would end up in a situation where it wouldn't decrement since unsigned shift right twice would lead to decrementing estimated size by 0.
> 
> It's worth noting the probabilistic nature of skip lists and that their spliterators are not SIZED and their estimatedSize() is therefor not to be relied upon for deterministic correctness.

This pull request has now been integrated.

Changeset: d76b5b88
Author:    Viktor Klang <vklang at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d76b5b888e15b507631068f508e261cab75c841e
Stats:     3 lines in 1 file changed: 0 ins; 0 del; 3 mod

8344253: Test java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22210

From dl at openjdk.org  Mon Nov 18 17:39:46 2024
From: dl at openjdk.org (Doug Lea)
Date: Mon, 18 Nov 2024 17:39:46 GMT
Subject: RFR: 8344253: Test
 java/util/Spliterator/SpliteratorTraversingAndSplittingTest.java failed
In-Reply-To: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
References: <FWAr_pMTvdZTlQAFT9NzG3JcBhqWt5CPtVk49yu7F-M=.248519cc-4b8e-4f16-b9d3-7ddd8ecdb4d0@github.com>
Message-ID: <Iuythel5nhVleM8ms-vVDb6oQYFdf6EAIIcJMbOt-ys=.3a79da62-2ee2-4636-986b-9d9ff2d3beec@github.com>

On Mon, 18 Nov 2024 15:46:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

> This change now halves each side of the split regardless, the old code would end up in a situation where it wouldn't decrement since unsigned shift right twice would lead to decrementing estimated size by 0.
> 
> It's worth noting the probabilistic nature of skip lists and that their spliterators are not SIZED and their estimatedSize() is therefor not to be relied upon for deterministic correctness.

I jest checked parallelStream performance, across some possible variants of this change, and this is at least as good as any of them.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22210#issuecomment-2483701539

From aefimov at openjdk.org  Mon Nov 18 18:07:47 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 18 Nov 2024 18:07:47 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
Message-ID: <GVm9b-jRlU3gfqbcdqFK7aB5MBtgVQL9OwLHs5V3RJ8=.379a701b-5e8c-409e-9907-c02cd72c89fc@github.com>

On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> First cut at removal of Security Manager stuff from RMI.
> 
> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
> 
> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff.

The changes look good to me, with two suggestions below.

src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java line 65:

> 63:     /**
> 64:      * special child of the system thread group for running tasks that
> 65:      * may execute user code, so that the security policy for threads in

Do we still want to mention `security policy` here?

src/java.rmi/share/classes/sun/rmi/server/MarshalInputStream.java line 69:

> 67: 
> 68:     /** table to hold sun classes to which access is explicitly permitted */
> 69:     protected static Map<String, Class<?>> permittedSunClasses

It looks like `permittedSunClasses` map can be removed alongside to `checkSunClass(String, AccessControlException)` method, since it is only called on [line 198](https://github.com/openjdk/jdk/pull/22129/files#diff-491ee160d740152081c000fc513091e00181c41fd3c423c466fd30448a2a47e6R198):

} catch (@SuppressWarnings("removal") AccessControlException e) {
     return checkSunClass(className, e);

-------------

PR Review: https://git.openjdk.org/jdk/pull/22129#pullrequestreview-2443295343
PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847003817
PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847024207

From aefimov at openjdk.org  Mon Nov 18 18:07:48 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 18 Nov 2024 18:07:48 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <GVm9b-jRlU3gfqbcdqFK7aB5MBtgVQL9OwLHs5V3RJ8=.379a701b-5e8c-409e-9907-c02cd72c89fc@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
 <GVm9b-jRlU3gfqbcdqFK7aB5MBtgVQL9OwLHs5V3RJ8=.379a701b-5e8c-409e-9907-c02cd72c89fc@github.com>
Message-ID: <jk9xmu18wPuwd5Prr4yvxiwGeYOIpI_mnT6VJGKYpLk=.9c36ab89-1438-4357-b434-1d250a0d3041@github.com>

On Mon, 18 Nov 2024 17:55:31 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> First cut at removal of Security Manager stuff from RMI.
>> 
>> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
>> 
>> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff.
>
> src/java.rmi/share/classes/sun/rmi/server/MarshalInputStream.java line 69:
> 
>> 67: 
>> 68:     /** table to hold sun classes to which access is explicitly permitted */
>> 69:     protected static Map<String, Class<?>> permittedSunClasses
> 
> It looks like `permittedSunClasses` map can be removed alongside to `checkSunClass(String, AccessControlException)` method, since it is only called on [line 198](https://github.com/openjdk/jdk/pull/22129/files#diff-491ee160d740152081c000fc513091e00181c41fd3c423c466fd30448a2a47e6R198):
> 
> } catch (@SuppressWarnings("removal") AccessControlException e) {
>      return checkSunClass(className, e);

Sorry, missed your comment in a PR description - ignore the comment above

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847038115

From mbalao at openjdk.org  Mon Nov 18 18:11:38 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 18 Nov 2024 18:11:38 GMT
Subject: RFR: 8328119: SunPKCS#11 implementation of HKDF
Message-ID: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com>

We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).

This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements.

The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDFWithHmacSHA1, HKDFWithHmacSHA224, HKDFWithHmacSHA256, HKDFWithHmacSHA384, and, HKDFWithHmacSHA512.

Derivation modes supported: extract, expand, and, extract-expand.

We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map.

Generic keys now supported in SecretKeyFactory. Derived keys could be Generic.

Testing

 * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added
   * All RFC 5869 test vectors checked (7 tests)
   * Cross-checking against SunJCE's HKDF implementation for every algorithm possible
      * Static assertion data for resilience if SunJCE were not available
   * Use of derived key for encryption check
   * Concatenation of input key material and salt checked (multiple combinations)
   * Multiple derivation types checked (extract only, expand only, and, extract-expand)
   * Derive key and derive data checked
   * All supported HKDF algorithms tested (HKDFWithHmacSHA1, HKDFWithHmacSHA224, HKDFWithHmacSHA256, HKDFWithHmacSHA384, HKDFWithHmacSHA512)
   * DH and ECDH key derivation for TLS checked
   * Informative output for debugging purposes (shown automatically if there is a test failure)
     * Note: test failures do not prevent all tests for running
   * Test integrated to the SunPKCS11 tests framework

 * No regressions observed in jdk/sun/security/pkcs11 (114 tests passed, 0 failed)

A CSR will be proposed.

This proposal is a contribution of @martinuy  and @franferrax .

-------------

Commit messages:
 - 8328119: SunPKCS#11 implementation of HKDF

Changes: https://git.openjdk.org/jdk/pull/22215/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22215&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8328119
  Stats: 1645 lines in 16 files changed: 1585 ins; 29 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/22215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22215/head:pull/22215

PR: https://git.openjdk.org/jdk/pull/22215

From aefimov at openjdk.org  Mon Nov 18 18:17:52 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Mon, 18 Nov 2024 18:17:52 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
Message-ID: <AYl-MOB6FKNkTyjYkfpoVzDerodkS6Ig4W_ZuH5yAO0=.2223a2a4-2dc0-422b-9f4b-88232ea0a7e0@github.com>

On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> First cut at removal of Security Manager stuff from RMI.
> 
> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
> 
> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff.

Marked as reviewed by aefimov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22129#pullrequestreview-2443368454

From duke at openjdk.org  Mon Nov 18 18:19:43 2024
From: duke at openjdk.org (duke)
Date: Mon, 18 Nov 2024 18:19:43 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v3]
In-Reply-To: <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
Message-ID: <8BGllezHDeV8iOPGn2vgZ6ogFnvsx6ys6nbcQsWtHuQ=.9a5d538c-d62f-49ad-a3dc-00efd16d3782@github.com>

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
>> 
>> if no such entry exists, returns the entry for the least key greater than the specified key;
>> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
>> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.
>
> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8343125 : Empty tree case explicitly specified.

@namannigam 
Your change (at version 48a0fc1ab2f7c6eec0f6b0bfff431b921d22684f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2483789125

From naoto at openjdk.org  Mon Nov 18 18:24:55 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 18:24:55 GMT
Subject: RFR: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module [v2]
In-Reply-To: <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
 <I2oi1fMP0yb47PWlQb31Rw8PKU9DT5qHcG3W13f_ubk=.866bf702-9312-42d6-8d89-6a414a77412e@github.com>
Message-ID: <WczcXqXBNNc65alyRCEp03ofhcQnSEEETVKcEZXOvXU=.ee032011-4057-4a21-8337-93dcd703624b@github.com>

On Fri, 15 Nov 2024 20:17:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.
>
> Naoto Sato has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fixed import

Thank you for your reviews!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22162#issuecomment-2483799286

From naoto at openjdk.org  Mon Nov 18 18:24:56 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 18:24:56 GMT
Subject: Integrated: 8344330: Remove AccessController.doPrivileged() from
 jdk.charsets module
In-Reply-To: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
References: <D9qv9BoD-2vpuLANukXj-KzNrWnODzQR0lgW8IqXrxA=.b6a032fb-f2c0-4474-9abc-ade3bfd2031c@github.com>
Message-ID: <uQ0jSNtYfmGheaGR6ZTjsW2r0Q_UQVAvSsvCKKCDJnA=.7c6957f3-f5c9-4ec8-a806-0185bcac1f10@github.com>

On Fri, 15 Nov 2024 19:26:15 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Removing a `AccessController.doPrivileged()` call from jdk.charsets module after JEP486 integration.

This pull request has now been integrated.

Changeset: c59adf68
Author:    Naoto Sato <naoto at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/c59adf68d9ac49b41fb778041e3949a8057e8d7f
Stats:     12 lines in 1 file changed: 0 ins; 9 del; 3 mod

8344330: Remove AccessController.doPrivileged() from jdk.charsets module

Reviewed-by: lancea, bpb, rriggs, jlu

-------------

PR: https://git.openjdk.org/jdk/pull/22162

From liach at openjdk.org  Mon Nov 18 18:32:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 18:32:54 GMT
Subject: RFR: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry [v3]
In-Reply-To: <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
 <qPaSD6xdMehImrw08zDleH-t1r-eR-sLPXxrVQO9IxU=.f5d2ca00-2d0d-4c0e-aa8b-3f1f0e7563ca@github.com>
Message-ID: <utZj39zNPyti0cQ9gMrTXrLNTtRQ5qkW8ZyHHAE9zMA=.f4418a8f-d579-41a4-bc64-2a956f2db4d7@github.com>

On Thu, 14 Nov 2024 03:23:29 GMT, Naman Nigam <duke at openjdk.org> wrote:

>> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
>> 
>> if no such entry exists, returns the entry for the least key greater than the specified key;
>> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
>> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.
>
> Naman Nigam has updated the pull request incrementally with one additional commit since the last revision:
> 
>   JDK-8343125 : Empty tree case explicitly specified.

Thanks for this comment fix!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21729#issuecomment-2483813990

From duke at openjdk.org  Mon Nov 18 18:32:54 2024
From: duke at openjdk.org (Naman Nigam)
Date: Mon, 18 Nov 2024 18:32:54 GMT
Subject: Integrated: 8343125: Correct the documentation for TreeMap's
 getFloorEntry and getCeilingEntry
In-Reply-To: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
References: <O43zdRhPy6B5P8yKCVAmbpG7_IdjHEGS4dDyyQlREd0=.81360b49-1369-43b1-b2c2-ffa517b6960f@github.com>
Message-ID: <WXKEU3aY8P_BY6IjVCaRPgnODJzy7QeIvdNxjw4KCm4=.01675fd8-4b58-44ca-995b-6043f370bc9f@github.com>

On Sat, 26 Oct 2024 14:06:37 GMT, Naman Nigam <duke at openjdk.org> wrote:

> As the documentation of getCeilingEntry currently reads, the inference is misleading as follows:
> 
> if no such entry exists, returns the entry for the least key greater than the specified key;
> if no such entry exists (i.e., the greatest key in the Tree is less than the specified key), returns {@code null}
> Have modified the first section to ensure that its clear that the value returned is upon existence of the key. Added a similar change for getFloorEntry.

This pull request has now been integrated.

Changeset: e9e4200a
Author:    Naman Nigam <namannigam12 at gmail.com>
Committer: Chen Liang <liach at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e9e4200a6aaacc11442f0298525e2531bf08240e
Stats:     8 lines in 1 file changed: 0 ins; 2 del; 6 mod

8343125: Correct the documentation for TreeMap's getFloorEntry and getCeilingEntry

Reviewed-by: liach, acobbs

-------------

PR: https://git.openjdk.org/jdk/pull/21729

From asemenyuk at openjdk.org  Mon Nov 18 18:37:20 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 18:37:20 GMT
Subject: RFR: 8344415: Restruct jpackage utility classes
Message-ID: <XWlQEer4GtF9Vz28SoF7dPJ74WghnRxZc05pPfkI8AQ=.1e607c0a-e6cf-4dd1-983f-f486a94b13cd@github.com>

Move child classes of "jdk.jpackage.test.Functional" class to "jdk.jpackage.internal.util.function" package.
Split "jdk.jpackage.internal.IOUtils" class in "PathUtils", "FileUtils", "XmlUtils" classes in "jdk.jpackage.internal.util" package.

Implmenetation didnt change except of `FileUtils.deleteRecursive()` that was cleared from the dependency on "AtomicReference".

Applied `bin/blessed-modifier-order.sh` script to the modified files.

-------------

Commit messages:
 - Bugfix
 - Merge bugfix
 - Copyright year fixed
 - Copyright fixed
 - Bugfix
 - Fix bad merge
 - Bugfix
 - Merge branch 'master' into SplitIOUtils
 - Added missing ThrowingBiConsumer class
 - Revert "Get rid of FunctionalUtils.java". Brings back Functional.java to make the diff easier to digest. It will be replaced with redoing c58b6587b3b4fb9c08afd27eacf139e0ed9afb83 commit in the next PR.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/e1c4b497...dbb96904

Changes: https://git.openjdk.org/jdk/pull/22216/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22216&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344415
  Stats: 1431 lines in 67 files changed: 860 ins; 417 del; 154 mod
  Patch: https://git.openjdk.org/jdk/pull/22216.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22216/head:pull/22216

PR: https://git.openjdk.org/jdk/pull/22216

From asemenyuk at openjdk.org  Mon Nov 18 18:37:20 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Mon, 18 Nov 2024 18:37:20 GMT
Subject: RFR: 8344415: Restruct jpackage utility classes
In-Reply-To: <XWlQEer4GtF9Vz28SoF7dPJ74WghnRxZc05pPfkI8AQ=.1e607c0a-e6cf-4dd1-983f-f486a94b13cd@github.com>
References: <XWlQEer4GtF9Vz28SoF7dPJ74WghnRxZc05pPfkI8AQ=.1e607c0a-e6cf-4dd1-983f-f486a94b13cd@github.com>
Message-ID: <g00aIPgS3ZS1JsXb7UiucoQXfDywIzwkNgPSi4XR6OI=.25348b40-0362-4c0b-9394-86ad936f8302@github.com>

On Mon, 18 Nov 2024 18:31:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move child classes of "jdk.jpackage.test.Functional" class to "jdk.jpackage.internal.util.function" package.
> Split "jdk.jpackage.internal.IOUtils" class in "PathUtils", "FileUtils", "XmlUtils" classes in "jdk.jpackage.internal.util" package.
> 
> Implmenetation didnt change except of `FileUtils.deleteRecursive()` that was cleared from the dependency on "AtomicReference".
> 
> Applied `bin/blessed-modifier-order.sh` script to the modified files.

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22216#issuecomment-2483820364

From rriggs at openjdk.org  Mon Nov 18 18:59:46 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 18:59:46 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
Message-ID: <Px2jNqhg5Yt2V-AnbcYfvHrAguqB8nZKvX_3FYAb5fs=.451085a4-a353-4364-9a18-464fd2f226f3@github.com>

On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> First cut at removal of Security Manager stuff from RMI.
> 
> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
> 
> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff.

Looks ok, but some additional cleanup is recommended.

src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java line 49:

> 47:  * @author      Peter Jones
> 48:  **/
> 49: public final class NewThreadAction {

Suggest inlining the methods and getting rid of the class, moving non-trivial methods to an existing Util class.
Or at least renaming it to to drop the "Action" that is indicative of doPrivileged.

src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java line 404:

> 402:      */
> 403:     public void startNewAcceptor() {
> 404:         Thread t =

Fold to previous line.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22129#pullrequestreview-2443440493
PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847092598
PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847098808

From lancea at openjdk.org  Mon Nov 18 19:07:47 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Mon, 18 Nov 2024 19:07:47 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v2]
In-Reply-To: <okJ2mkNbFajOLo5-sWw1E2DyfqrlgbPv0So4chqy2KE=.8acabafb-300a-488c-b52e-224057022ad6@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <okJ2mkNbFajOLo5-sWw1E2DyfqrlgbPv0So4chqy2KE=.8acabafb-300a-488c-b52e-224057022ad6@github.com>
Message-ID: <bAQIvCh5GkYst7WKVWsOwF4dl77IEKdeFDA2MdXtDLk=.298be906-4e35-494d-a6f0-107504541ffe@github.com>

On Mon, 18 Nov 2024 08:37:26 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
>> 
>> There are quite a few changes to review, but all relatively straightforward:
>> 
>> `DriverManager`
>> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
>> * Remove two now-unused package private SQLPermission constants
>> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
>> 
>> `CachedRowSetImpl`
>> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
>> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
>> 
>> `CachedRowSetWriter`
>> * A call to `ReflectUtil::checkPackageAccess` is removed.
>> 
>> `SerialJavaObject`
>> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
>> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
>> 
>> `SyncFactory`
>> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
>> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
>> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
>> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
>> 
>> `RowsetProvider`
>> *  Static initializer is updated to call `System::getProperty` directly
>> * `newFactory` is updated to call `System::getProperty` directly
>> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
>> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getSystemProperty` is removed
>> 
>> 
>> `SQLInputImpl`
>> *  A call to `ReflectUtil::checkPackageAccess` is removed
>> 
>>  `TestPolicy.java` in `test/java/sql/testng/util`
>> * This  is now unused and removed
>> 
>> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert caller-sensitive inlining of ReflectUtil.forName
>  - SerialJavaObject::getFields is no longer @CallerSensitive, remove it from CheckCSM test

Thanks for tackling this Eirik.  I made a pass through and I think the changes are reasonable.

I have asked Sean to also make a pass as well

-------------

PR Review: https://git.openjdk.org/jdk/pull/22185#pullrequestreview-2443473243

From rriggs at openjdk.org  Mon Nov 18 19:22:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 19:22:33 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v2]
In-Reply-To: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
Message-ID: <w3R1Ab4uKMmtwnFN0UCWDAZwvKVsUR2qHrwCXtPoIgI=.1a7cb021-e8ca-43fe-889a-c414da3c0839@github.com>

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Review suggestions applied:
  Remove SecurityExceptions from LiveStackFrame
  Rename safeTrim to trimArray

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22168/files
  - new: https://git.openjdk.org/jdk/pull/22168/files/6663749a..b873e116

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22168&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22168&range=00-01

  Stats: 20 lines in 2 files changed: 0 ins; 17 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22168/head:pull/22168

PR: https://git.openjdk.org/jdk/pull/22168

From dfuchs at openjdk.org  Mon Nov 18 19:25:56 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Mon, 18 Nov 2024 19:25:56 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
In-Reply-To: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
Message-ID: <LmIKipbpH0jhn0NiKWuKZsO3XQBw-cBnouCIchjmfvs=.f3827369-1c36-4518-aef0-2493b0b79581@github.com>

On Fri, 15 Nov 2024 17:03:50 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
> - The following two properties are removed:
>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>     - `com.sun.jndi.rmi.object.trustURLCodebase`
> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
> 
> These changes require a CSR that will be submitted soon.
> 
> ### Testing
> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.

src/java.naming/share/classes/com/sun/naming/internal/NamingManagerHelper.java line 205:

> 203:         if (clas == null &&
> 204:             ref.getFactoryClassLocation() != null) {
> 205:             return null;

This is what I suggest: 

at line 197 above (CNFE) just do:


        } catch (ClassNotFoundException e) {
            return null;
        }


Then you can remove the rest of the code that follows and simply do


        assert clas != null
        @SuppressWarnings("deprecation") // Class.newInstance
        ObjectFactory result = clas.newInstance();
        return result;
    }

src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 129:

> 127:      *    is not supported, unless a custom {@link ObjectFactoryBuilder}
> 128:      *    {@linkplain #setObjectFactoryBuilder(ObjectFactoryBuilder) is set}
> 129:      *    to determine object factories load policy.

Maybe change to something like:


Downloading a factory class from a location specified in the reference
is not supported out of the box. A custom {@link ObjectFactoryBuilder} 
{@linkplain #setObjectFactoryBuilder(ObjectFactoryBuilder) may be used}
if a different policy is desired.

src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java line 472:

> 470:              * Classes may only be loaded from an arbitrary URL codebase when
> 471:              *  a custom ObjectFactoryBuilder() is setup, otherwise load from
> 472:              *  arbitrary URL codebase is disabled.

Maybe reuse the text above:


Downloading a factory class from a location specified in the reference
is not supported out of the box. A custom {@link ObjectFactoryBuilder} 
{@linkplain #setObjectFactoryBuilder(ObjectFactoryBuilder) may be used}
if a different policy is desired.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1847105861
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1847123637
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1847129710

From rriggs at openjdk.org  Mon Nov 18 19:32:50 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 19:32:50 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v2]
In-Reply-To: <okJ2mkNbFajOLo5-sWw1E2DyfqrlgbPv0So4chqy2KE=.8acabafb-300a-488c-b52e-224057022ad6@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <okJ2mkNbFajOLo5-sWw1E2DyfqrlgbPv0So4chqy2KE=.8acabafb-300a-488c-b52e-224057022ad6@github.com>
Message-ID: <ZOAGEXBITYbNrogsb7k6nqYjNMta5TEsZPrqV6v6aU0=.cd266be5-95bb-4aa0-b614-61152379dfb9@github.com>

On Mon, 18 Nov 2024 08:37:26 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
>> 
>> There are quite a few changes to review, but all relatively straightforward:
>> 
>> `DriverManager`
>> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
>> * Remove two now-unused package private SQLPermission constants
>> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
>> 
>> `CachedRowSetImpl`
>> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
>> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
>> 
>> `CachedRowSetWriter`
>> * A call to `ReflectUtil::checkPackageAccess` is removed.
>> 
>> `SerialJavaObject`
>> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
>> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
>> 
>> `SyncFactory`
>> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
>> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
>> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
>> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
>> 
>> `RowsetProvider`
>> *  Static initializer is updated to call `System::getProperty` directly
>> * `newFactory` is updated to call `System::getProperty` directly
>> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
>> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getSystemProperty` is removed
>> 
>> 
>> `SQLInputImpl`
>> *  A call to `ReflectUtil::checkPackageAccess` is removed
>> 
>>  `TestPolicy.java` in `test/java/sql/testng/util`
>> * This  is now unused and removed
>> 
>> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Revert caller-sensitive inlining of ReflectUtil.forName
>  - SerialJavaObject::getFields is no longer @CallerSensitive, remove it from CheckCSM test

Looks fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22185#pullrequestreview-2443522088

From eirbjo at openjdk.org  Mon Nov 18 19:32:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 19:32:53 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
In-Reply-To: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
Message-ID: <247YUHnpQpNcVDhb1Pf2vjrGd4bXDf6sBKT3bzSEcFA=.e4243266-6967-4fa1-b62b-6e680b66c2d7@github.com>

On Mon, 18 Nov 2024 12:40:43 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> This PR proposes to use a static property already resolved instead of calling `System.getProperty()`.

The CSR for this change has been approved. I plan to integrate this tomorrow pending a final tier2 run.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22205#issuecomment-2483927909

From eirbjo at openjdk.org  Mon Nov 18 19:47:25 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 19:47:25 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v3]
In-Reply-To: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
Message-ID: <TQ67ZZ2KeXEwTObDliMr7vYUvWWV81xy87eyLwbWjkc=.2294aaac-fbf2-46c2-9b76-540b1dcc8f7a@github.com>

> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
> 
> There are quite a few changes to review, but all relatively straightforward:
> 
> `DriverManager`
> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
> * Remove two now-unused package private SQLPermission constants
> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
> 
> `CachedRowSetImpl`
> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
> 
> `CachedRowSetWriter`
> * A call to `ReflectUtil::checkPackageAccess` is removed.
> 
> `SerialJavaObject`
> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
> 
> `SyncFactory`
> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
> 
> `RowsetProvider`
> *  Static initializer is updated to call `System::getProperty` directly
> * `newFactory` is updated to call `System::getProperty` directly
> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getSystemProperty` is removed
> 
> 
> `SQLInputImpl`
> *  A call to `ReflectUtil::checkPackageAccess` is removed
> 
>  `TestPolicy.java` in `test/java/sql/testng/util`
> * This  is now unused and removed
> 
> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.

Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:

 - Merge branch 'master' into sm-cleanup-sql
   
   # Conflicts:
   #	test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java
 - Revert caller-sensitive inlining of ReflectUtil.forName
 - SerialJavaObject::getFields is no longer @CallerSensitive, remove it from CheckCSM test
 - Remove unused class TestPolicy from test/java/sql/testng/util
 - Remove unused SQLPermission constants
 - Update copyright
 - Remove calls to ReflectUtil.checkPackageAccess
 - Inline call to Class.forName
 - Remove call to ReflectUtil::checkPackageAccess
 - Remove @SuppressWarnings("removal")
 - ... and 1 more: https://git.openjdk.org/jdk/compare/92271af6...3f1df59a

-------------

Changes: https://git.openjdk.org/jdk/pull/22185/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22185&range=02
  Stats: 406 lines in 9 files changed: 10 ins; 352 del; 44 mod
  Patch: https://git.openjdk.org/jdk/pull/22185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22185/head:pull/22185

PR: https://git.openjdk.org/jdk/pull/22185

From liach at openjdk.org  Mon Nov 18 20:04:25 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 20:04:25 GMT
Subject: RFR: 8342468: Improve API documentation for
 java.lang.classfile.constantpool
Message-ID: <3vFQsVbVNWwkMmujMjMqpMA-ZvbxbWqRp5W-4XrycYM=.c60d6f08-74eb-4874-bbee-aa2d0365e8f3@github.com>

Improve documentation for constant pool entries.  This include some models for those entries, symbolic descriptors, and some general guidance in package summary.

APIDiff: https://cr.openjdk.org/~liach/apidiff/cf-consts/
Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-consts/

Please review the associated CSR as well.

Companion PRs: #21625

-------------

Commit messages:
 - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool
 - More concise message about exceptions
 - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-constantpool
 - Improve api docs for constantpool

Changes: https://git.openjdk.org/jdk/pull/22217/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22217&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342468
  Stats: 1114 lines in 30 files changed: 781 ins; 69 del; 264 mod
  Patch: https://git.openjdk.org/jdk/pull/22217.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22217/head:pull/22217

PR: https://git.openjdk.org/jdk/pull/22217

From rriggs at openjdk.org  Mon Nov 18 20:08:52 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 20:08:52 GMT
Subject: RFR: 8178966: Don't swallow early bootstrap exceptions in
 Boolean.getBoolean, Integer.getInteger and Long.getLong
In-Reply-To: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
References: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
Message-ID: <1AD0givJo5SO2yVODD-mMw7fpvYXnyWEH0LpN-FnAqU=.ef1c524b-626a-4c6a-ae31-89fa0e38e13d@github.com>

On Sun, 17 Nov 2024 14:52:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes exceptional control flow in `Boolean::getBoolean`, `Integer::getInteger` and `Long::getLong`.
> 
> These methods are catching `IllegalArgumentException` and `NullPointerException`, thrown by `System::getProperty` via `System::checkKey`. This PR replaces the exceptional control flow with explicit checks that the system property name is non-null and non-empty before calling into `System::getProperty`.
> 
> As JDK-8178966 points out, there is a possibility that System.getProperty could throw one of NPE and IAE for other reasons than the name being null or empty. This risk is reduced now that custom security managers cannot interfere. Adding to that, if such exceptions are thrown today, they are masked by these methods catching and swallowing them by returning false or default values. It's better to expose such  bugs if they exist.
> 
> GHA results pending. Local tier2 ran successfully.

ok, I withdraw my concern.  
The spec for the methods is explicit about the null and empty checks; as is the suggested fix.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22183#pullrequestreview-2443607759

From eirbjo at openjdk.org  Mon Nov 18 20:08:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 20:08:53 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v2]
In-Reply-To: <ZOAGEXBITYbNrogsb7k6nqYjNMta5TEsZPrqV6v6aU0=.cd266be5-95bb-4aa0-b614-61152379dfb9@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <okJ2mkNbFajOLo5-sWw1E2DyfqrlgbPv0So4chqy2KE=.8acabafb-300a-488c-b52e-224057022ad6@github.com>
 <ZOAGEXBITYbNrogsb7k6nqYjNMta5TEsZPrqV6v6aU0=.cd266be5-95bb-4aa0-b614-61152379dfb9@github.com>
Message-ID: <uZCBF96heP3FE0NEWEDextGVoSRHGRLC5j01iFtA1Ik=.590accfa-1783-4c50-b3ce-030cb480b67d@github.com>

On Mon, 18 Nov 2024 19:30:08 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Revert caller-sensitive inlining of ReflectUtil.forName
>>  - SerialJavaObject::getFields is no longer @CallerSensitive, remove it from CheckCSM test
>
> Looks fine.

Hey @RogerRiggs, I needed to merge with master to resolve a conflict after the integration of your PR #22041.

Would you mind taking another look at the merge commit 3f1df59 and re-review this PR?

While looking at your change in #22041, I noticed you removed `ObjectStreamField#getType` from `CheckCSM.KNOWN_NON_FINAL_CSMS`, but that it remains in `CheckCSM.UNSUPPORTED_VIRTUAL_METHODS`.

CheckCSM runs fine with this method removed from `UNSUPPORTED_VIRTUAL_METHODS` which leads me to think it may have been a leftover?

If it was, I'm happy to remove it while I'm visiting this code anyhow, or you could clean it up via some other PR.

Thanks :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2484005783

From rriggs at openjdk.org  Mon Nov 18 20:29:52 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 20:29:52 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v3]
In-Reply-To: <TQ67ZZ2KeXEwTObDliMr7vYUvWWV81xy87eyLwbWjkc=.2294aaac-fbf2-46c2-9b76-540b1dcc8f7a@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <TQ67ZZ2KeXEwTObDliMr7vYUvWWV81xy87eyLwbWjkc=.2294aaac-fbf2-46c2-9b76-540b1dcc8f7a@github.com>
Message-ID: <Seef4XOrJum_WaOaWAo8OLnmmiVVt0dIXFlNM9xjteg=.5c3f8867-5e37-4ec9-8c45-ca0d7cc88e9d@github.com>

On Mon, 18 Nov 2024 19:47:25 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
>> 
>> There are quite a few changes to review, but all relatively straightforward:
>> 
>> `DriverManager`
>> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
>> * Remove two now-unused package private SQLPermission constants
>> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
>> 
>> `CachedRowSetImpl`
>> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
>> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
>> 
>> `CachedRowSetWriter`
>> * A call to `ReflectUtil::checkPackageAccess` is removed.
>> 
>> `SerialJavaObject`
>> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
>> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
>> 
>> `SyncFactory`
>> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
>> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
>> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
>> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
>> 
>> `RowsetProvider`
>> *  Static initializer is updated to call `System::getProperty` directly
>> * `newFactory` is updated to call `System::getProperty` directly
>> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
>> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getSystemProperty` is removed
>> 
>> 
>> `SQLInputImpl`
>> *  A call to `ReflectUtil::checkPackageAccess` is removed
>> 
>>  `TestPolicy.java` in `test/java/sql/testng/util`
>> * This  is now unused and removed
>> 
>> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 11 commits:
> 
>  - Merge branch 'master' into sm-cleanup-sql
>    
>    # Conflicts:
>    #	test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java
>  - Revert caller-sensitive inlining of ReflectUtil.forName
>  - SerialJavaObject::getFields is no longer @CallerSensitive, remove it from CheckCSM test
>  - Remove unused class TestPolicy from test/java/sql/testng/util
>  - Remove unused SQLPermission constants
>  - Update copyright
>  - Remove calls to ReflectUtil.checkPackageAccess
>  - Inline call to Class.forName
>  - Remove call to ReflectUtil::checkPackageAccess
>  - Remove @SuppressWarnings("removal")
>  - ... and 1 more: https://git.openjdk.org/jdk/compare/92271af6...3f1df59a

Yes, please cleanup the leftover mention, in CheckCSMs. of ObjectStreamField.getType().
And I'll re-review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2484061603

From bpb at openjdk.org  Mon Nov 18 20:32:58 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 20:32:58 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io
Message-ID: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>

Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

-------------

Commit messages:
 - 8344077: Remove security manager dependency in java.io

Changes: https://git.openjdk.org/jdk/pull/22219/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22219&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344077
  Stats: 261 lines in 9 files changed: 2 ins; 225 del; 34 mod
  Patch: https://git.openjdk.org/jdk/pull/22219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22219/head:pull/22219

PR: https://git.openjdk.org/jdk/pull/22219

From eirbjo at openjdk.org  Mon Nov 18 20:34:26 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 20:34:26 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v4]
In-Reply-To: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
Message-ID: <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>

> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
> 
> There are quite a few changes to review, but all relatively straightforward:
> 
> `DriverManager`
> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
> * Remove two now-unused package private SQLPermission constants
> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
> 
> `CachedRowSetImpl`
> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
> 
> `CachedRowSetWriter`
> * A call to `ReflectUtil::checkPackageAccess` is removed.
> 
> `SerialJavaObject`
> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
> 
> `SyncFactory`
> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
> 
> `RowsetProvider`
> *  Static initializer is updated to call `System::getProperty` directly
> * `newFactory` is updated to call `System::getProperty` directly
> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getSystemProperty` is removed
> 
> 
> `SQLInputImpl`
> *  A call to `ReflectUtil::checkPackageAccess` is removed
> 
>  `TestPolicy.java` in `test/java/sql/testng/util`
> * This  is now unused and removed
> 
> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.

Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:

  Remove ObjectStreamField#getType from UNSUPPORTED_VIRTUAL_METHODS, a leftover from JDK-8344034

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22185/files
  - new: https://git.openjdk.org/jdk/pull/22185/files/3f1df59a..0278c59e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22185&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22185&range=02-03

  Stats: 2 lines in 1 file changed: 0 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22185.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22185/head:pull/22185

PR: https://git.openjdk.org/jdk/pull/22185

From bpb at openjdk.org  Mon Nov 18 20:37:01 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 20:37:01 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <ugsKUlQARSKSlQs7Niddrb8NKkuwrg92WP2jF4p6pHg=.3ee08770-6ab6-4c82-98c3-2f15d600bc31@github.com>

On Mon, 18 Nov 2024 20:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

Preliminary testing: the `jdk_io` tests pass on Linux and Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22219#issuecomment-2484074311

From eirbjo at openjdk.org  Mon Nov 18 20:37:01 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 20:37:01 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v3]
In-Reply-To: <Seef4XOrJum_WaOaWAo8OLnmmiVVt0dIXFlNM9xjteg=.5c3f8867-5e37-4ec9-8c45-ca0d7cc88e9d@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <TQ67ZZ2KeXEwTObDliMr7vYUvWWV81xy87eyLwbWjkc=.2294aaac-fbf2-46c2-9b76-540b1dcc8f7a@github.com>
 <Seef4XOrJum_WaOaWAo8OLnmmiVVt0dIXFlNM9xjteg=.5c3f8867-5e37-4ec9-8c45-ca0d7cc88e9d@github.com>
Message-ID: <8LzQZhnaBhASwSr2-bzWIfLEPpYXvAZeZuq4HUAUl3E=.225bb0f7-612a-4788-a1f9-1aca429da5d4@github.com>

On Mon, 18 Nov 2024 20:27:20 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Yes, please cleanup the leftover mention, in CheckCSMs. of ObjectStreamField.getType(). And I'll re-review.

Thanks, see 0278c59. This leaves `UNSUPPORTED_VIRTUAL_METHODS` as an empty set. Should I remove this field and the code using this, or do you think leaving the set empty is enough for this PR? Is someone adding to this set later probable?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2484073711

From eirbjo at gmail.com  Mon Nov 18 20:38:40 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 21:38:40 +0100
Subject: Q: Why is java.lang.Runtime non-final?
Message-ID: <CA+pBWhsUL1yusWf3PtTXwGRsxXNroyFBo0F_i9=uLBYNnkZ4EQ@mail.gmail.com>

Hi,

Tried to find an answer to this question in JBS, but found nothing:

Since java.lang.Runtime has a single private constructor, it seems
effectively final. Why is it not declared final?

If Runtime was made final it seems we could remove the CheckCSMs test.

Are there compatibility concerns here that I don't see?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241118/05535257/attachment.htm>

From mullan at openjdk.org  Mon Nov 18 20:39:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 18 Nov 2024 20:39:48 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <OJ77_NqVsmnbAsB_LK4YaQPQzZT3zimNYgfjrIw1P50=.8efb9283-1db5-4139-8750-9c7a6958c594@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

What about `sun.misc.Unsafe`? There are a couple of `AccessController.doPrivileged` calls.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2484076615

From rriggs at openjdk.org  Mon Nov 18 20:43:44 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 20:43:44 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v4]
In-Reply-To: <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
Message-ID: <-TArLFnzVprwJm4x2AIA76bpmqC8eJyDeW0Hw0xg8ZU=.a4d4a91d-e851-40f7-a1a6-648b37219ac8@github.com>

On Mon, 18 Nov 2024 20:34:26 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
>> 
>> There are quite a few changes to review, but all relatively straightforward:
>> 
>> `DriverManager`
>> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
>> * Remove two now-unused package private SQLPermission constants
>> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
>> 
>> `CachedRowSetImpl`
>> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
>> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
>> 
>> `CachedRowSetWriter`
>> * A call to `ReflectUtil::checkPackageAccess` is removed.
>> 
>> `SerialJavaObject`
>> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
>> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
>> 
>> `SyncFactory`
>> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
>> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
>> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
>> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
>> 
>> `RowsetProvider`
>> *  Static initializer is updated to call `System::getProperty` directly
>> * `newFactory` is updated to call `System::getProperty` directly
>> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
>> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getSystemProperty` is removed
>> 
>> 
>> `SQLInputImpl`
>> *  A call to `ReflectUtil::checkPackageAccess` is removed
>> 
>>  `TestPolicy.java` in `test/java/sql/testng/util`
>> * This  is now unused and removed
>> 
>> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove ObjectStreamField#getType from UNSUPPORTED_VIRTUAL_METHODS, a leftover from JDK-8344034

Looks good, thanks for the update.

Leave the test with an empty set of methods for CallerSensistiveAdepter will make it clearer to check for matching test conditions.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22185#pullrequestreview-2443675070
PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2484084191

From rriggs at openjdk.org  Mon Nov 18 20:56:51 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 20:56:51 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <ZtDpNLBxGECGbwHkRONeUatWz3yz9A-Y5Vc58ZISnOY=.8b30c083-f150-4949-933f-6a246160e79e@github.com>

On Mon, 18 Nov 2024 20:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

Looks good

src/java.base/share/classes/java/io/FilePermission.java line 184:

> 182:         DefaultFileSystemProvider.theFileSystem();
> 183: 
> 184:     private static final Path here = builtInFS.getPath(System.getProperty("user.dir"));

Could be updated to use StaticProperty:
Suggestion:

    private static final Path here = builtInFS.getPath(jdk.internal.util.StaticProperty.userDir());

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2443700481
PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847254590

From naoto at openjdk.org  Mon Nov 18 20:56:52 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 20:56:52 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <d6ojzBFYCY99jAuzr3e1feDJevdn0zR3FjJ-hCaX2ik=.bf84b86b-2aab-471d-b641-73585426f1b1@github.com>

On Mon, 18 Nov 2024 20:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

`Console` changes look good to me, with a minor suggestion

src/java.base/share/classes/java/io/Console.java line 687:

> 685:             }
> 686:         } catch (ServiceConfigurationError _) {
> 687:             c = null;

This assignment can be removed

-------------

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2443712279
PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847262821

From rriggs at openjdk.org  Mon Nov 18 20:57:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 20:57:57 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <OJ77_NqVsmnbAsB_LK4YaQPQzZT3zimNYgfjrIw1P50=.8efb9283-1db5-4139-8750-9c7a6958c594@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
 <OJ77_NqVsmnbAsB_LK4YaQPQzZT3zimNYgfjrIw1P50=.8efb9283-1db5-4139-8750-9c7a6958c594@github.com>
Message-ID: <A5b86nah8vk65ybJ48MwiFIjcBUpRfllz-W6TTiPS7E=.d2f8ffa5-d33e-45bb-888e-bf3b8fd386d2@github.com>

On Mon, 18 Nov 2024 20:35:49 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> What about `sun.misc.Unsafe`? There are a couple of `AccessController.doPrivileged` calls.

I'll look at that in a separate PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2484111717

From naoto at openjdk.org  Mon Nov 18 20:59:42 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 20:59:42 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <EuREcJuyeCht54njOTqwmIHiBxjYRsjwiSDSa7KYHFA=.d0f6baa4-0283-4f72-8eaf-5b0370093681@github.com>

On Mon, 18 Nov 2024 20:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

src/java.base/share/classes/java/io/Console.java line 660:

> 658:     }
> 659: 
> 660:     @SuppressWarnings("removal")

This too

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847266553

From liach at openjdk.org  Mon Nov 18 21:06:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 21:06:00 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
In-Reply-To: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
Message-ID: <O57GqoLTBEtabzWDMOeoOAXR20htwuHtTBBHHxbKCYw=.0c083485-8426-4fb6-9957-9726594a7e43@github.com>

On Mon, 18 Nov 2024 07:41:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change. Alternatively the diffs can be viewed on the API diff link attached on the CSR.

Would be nice if you can render the APIDiff and javadoc and share on cr.openjdk.org :)

src/java.base/share/classes/java/util/Locale.java line 94:

> 92:  * <p> A {@code Locale} is composed of the bolded fields described below; note that a
> 93:  * {@code Locale} need not have all such fields. For example, {@link
> 94:  * Locale#ENGLISH Locale.ENGLISH} is only comprised of the <em>language</em> field.

Side remark: in the `Locale` class itself, you can just use `{@link #ENGLISH Locale.ENGLISH}` to generate the link.

src/java.base/share/classes/java/util/Locale.java line 95:

> 93:  * {@code Locale} need not have all such fields. For example, {@link
> 94:  * Locale#ENGLISH Locale.ENGLISH} is only comprised of the <em>language</em> field.
> 95:  * Contrarily, a {@code Locale} such as the one returned by {@code

"Contrarily" is fine, but I think we use "In contrast" more often.

src/java.base/share/classes/java/util/Locale.java line 100:

> 98:  * the United States using the Latin alphabet and numerics for use in POSIX
> 99:  * environments.
> 100:  * {@code Locale} implements IETF BCP 47 and any deviations should be observed

I recommend a paragraph break here with `<p>`

src/java.base/share/classes/java/util/Locale.java line 120:

> 118:  *
> 119:  *   <dd> <em>Syntax:</em> Well-formed {@code language} values have the form {@code [a-zA-Z]{2,8}}.
> 120:  *   BCP 47 deviation: this is not the full BCP 47 language production, since it excludes

Should we add `<br>` before these deviations for more straightforward rendering?

src/java.base/share/classes/java/util/Locale.java line 210:

> 208:  * only checks if an individual field satisfies the syntactic
> 209:  * requirement (is well-formed), but does not validate the value
> 210:  * itself. Conversely, {@link #of(String, String, String)} and its overloads do not

Suggestion:

 * itself. Conversely, {@link #of(String, String, String) Locale::of} and its overloads do not


I think javadoc tends to render those arguments as full-blown `of(java.lang.String, java.lang.String, java.lang.String)`, which is most likely not what you want.

src/java.base/share/classes/java/util/Locale.java line 333:

> 331:  *  {@link Locale#US Locale.US} is the {@code Locale} object for the United States.</dd>
> 332:  *  <dt><b>Factory Methods</b></dt>
> 333:  *  <dd>The method {@link #of(String, String, String)} and its overloads obtain a

Same link remarks.  Also for `forLanguageTag` below.

src/java.base/share/classes/java/util/Locale.java line 343:

> 341:  *
> 342:  * {@snippet lang=java :
> 343:  *     // The following are all equivalent

Suggestion:

 * <p>The following are all equivalent:
 * {@snippet lang=java :

src/java.base/share/classes/java/util/Locale.java line 376:

> 374:  * Locale.Category#FORMAT FORMAT} locale :
> 375:  * {@snippet lang=java :
> 376:  *     // The following are equivalent

Still recommend moving this comment to official javadoc, so the last sentence can be


The latter uses the default {@link Locale.Category#FORMAT FORMAT} locale, so
the following are equivalent:

src/java.base/share/classes/java/util/Locale.java line 399:

> 397:  * resources for multiple locales, it sometimes needs to find one or more
> 398:  * locales (or language tags) which meet each user's specific preferences. Note
> 399:  * that the term "language tag" is used interchangeably with "locale" in the following

Should we add an index to "language tag", like:
Suggestion:

 * that the term "<dfn>{@index "language tag"}</dfn>" is used interchangeably with "locale" in the following

src/java.base/share/classes/java/util/Locale.java line 476:

> 474:  *
> 475:  * <h2>Compatibility</h2>
> 476:  * @implNote

I believe `@implNote` is a higher-level tag than a `<h2>`; all following contents will be indented. Recommended moving the `<h2>` into the `@implNote`.

src/java.base/share/classes/java/util/Locale.java line 500:

> 498:  * <p>Because of these issues, it is recommended that apps migrate
> 499:  * away from constructing non-conforming locales and use the
> 500:  * {@link #forLanguageTag} and {@link Locale.Builder} APIs instead.

Same remarks for links, add a override render text to prevent javadoc from generating long parameter lists.

src/java.base/share/classes/java/util/Locale.java line 2106:

> 2104:      * is en_US, getDisplayCountry() will return "France"; if the locale is en_US and
> 2105:      * inLocale is fr_FR, getDisplayCountry() will return "Etats-Unis".
> 2106:      * If the name returned cannot be localized according to inLocale.

Suggestion:

     * If the name returned cannot be localized according to inLocale,

-------------

PR Review: https://git.openjdk.org/jdk/pull/22192#pullrequestreview-2443672580
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847236829
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847240545
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847243076
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847253411
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847259756
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847261730
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847263166
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847266745
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847267850
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847270260
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847271943
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847272982

From bpb at openjdk.org  Mon Nov 18 21:08:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 21:08:00 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v2]
In-Reply-To: <EuREcJuyeCht54njOTqwmIHiBxjYRsjwiSDSa7KYHFA=.d0f6baa4-0283-4f72-8eaf-5b0370093681@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <EuREcJuyeCht54njOTqwmIHiBxjYRsjwiSDSa7KYHFA=.d0f6baa4-0283-4f72-8eaf-5b0370093681@github.com>
Message-ID: <GoUYlHNPG5jGrTHI5LwFZTVX2msyCM9sKrfV04yWVvI=.cf471e6f-441b-4a0d-9fd1-660e2a1903ab@github.com>

On Mon, 18 Nov 2024 20:56:59 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8344446: Address review comments
>>  - 8344446: Remove security manager dependency from module jdk.sctp
>
> src/java.base/share/classes/java/io/Console.java line 660:
> 
>> 658:     }
>> 659: 
>> 660:     @SuppressWarnings("removal")
> 
> This too

Removed in c7ba335.

> src/java.base/share/classes/java/io/Console.java line 687:
> 
>> 685:             }
>> 686:         } catch (ServiceConfigurationError _) {
>> 687:             c = null;
> 
> This assignment can be removed

Removed in c7ba335.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847275215
PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847275162

From bpb at openjdk.org  Mon Nov 18 21:08:00 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 21:08:00 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v2]
In-Reply-To: <ZtDpNLBxGECGbwHkRONeUatWz3yz9A-Y5Vc58ZISnOY=.8b30c083-f150-4949-933f-6a246160e79e@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <ZtDpNLBxGECGbwHkRONeUatWz3yz9A-Y5Vc58ZISnOY=.8b30c083-f150-4949-933f-6a246160e79e@github.com>
Message-ID: <Bsri4i4o24M5yMQg0_gPY5H5QbeutcVzvvB92dPlH_Q=.afef4e4a-c053-45ab-940f-3e66a014b87d@github.com>

On Mon, 18 Nov 2024 20:46:24 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - 8344446: Address review comments
>>  - 8344446: Remove security manager dependency from module jdk.sctp
>
> src/java.base/share/classes/java/io/FilePermission.java line 184:
> 
>> 182:         DefaultFileSystemProvider.theFileSystem();
>> 183: 
>> 184:     private static final Path here = builtInFS.getPath(System.getProperty("user.dir"));
> 
> Could be updated to use StaticProperty:
> Suggestion:
> 
>     private static final Path here = builtInFS.getPath(jdk.internal.util.StaticProperty.userDir());

So changed in c7ba335.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847275036

From bpb at openjdk.org  Mon Nov 18 21:07:59 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 21:07:59 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v2]
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <tsE_umS_ITrV0uzkN8lOwxDIayFZ_V0ZfWx7Oov9sRU=.39215e1a-2e76-4836-8641-1fd8737aec8e@github.com>

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:

 - 8344446: Address review comments
 - 8344446: Remove security manager dependency from module jdk.sctp

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22219/files
  - new: https://git.openjdk.org/jdk/pull/22219/files/d31cec1b..c7ba3354

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22219&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22219&range=00-01

  Stats: 62 lines in 5 files changed: 0 ins; 56 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22219/head:pull/22219

PR: https://git.openjdk.org/jdk/pull/22219

From mullan at openjdk.org  Mon Nov 18 21:08:58 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Mon, 18 Nov 2024 21:08:58 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <q7HOZze-pOT-xhD2QnIAO7350rcQDMr87tjjXloqya4=.15a88427-6b11-4843-8141-474297b3781e@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

Marked as reviewed by mullan (Reviewer).

Is this worthy of a release note?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22158#pullrequestreview-2443731096
PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2484129989

From ihse at openjdk.org  Mon Nov 18 21:09:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 21:09:01 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <8bsRmYUMq4JicTqyl3RCDqgYvRyldEoh7772V9YI1Wk=.135e7a17-aed0-454f-a95d-49225352c51a@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <L6_P6PDTe3AKM5QS7iI4RBQNIm3-jHRRvUTMNRGtUAY=.8997bacb-6dc1-418e-bd13-abe5403ea0af@github.com>
 <A0B6qDEx6Ib2WKeIxBs-f9fIGTMedalFjvxCIvXQ74g=.2cb99e10-4e92-4225-bcb3-22273c1106a4@github.com>
 <zVIkkJgsKJjmTkMhdCALT9j40KNVz2ShIwX8HQCSBQE=.c73ba1fe-2bd4-4608-9382-f0796b31505f@github.com>
 <8bsRmYUMq4JicTqyl3RCDqgYvRyldEoh7772V9YI1Wk=.135e7a17-aed0-454f-a95d-49225352c51a@github.com>
Message-ID: <lopQZYstaXSMWmxj1H2YKkMwaZEusaje9GMfa_W_gwY=.6e44539f-c5b2-43de-9345-7125b5905d56@github.com>

On Mon, 18 Nov 2024 15:55:56 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> So, just to double-check: given the request is to make the helps consistent, and dropping the extensions from the concise help is not what was meant, I'll add the extensions both here and to the ordinary help. Correct?
>
> Done here:
> https://github.com/openjdk/jdk/pull/21411/commits/d4860961e2ff7e6218a16a2ed3990a0deba3ae1a

Thanks. Can you also post a snippet of `java -help` in the summary that shows how your change there looks?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1847274508

From liach at openjdk.org  Mon Nov 18 21:10:00 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 21:10:00 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
In-Reply-To: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
Message-ID: <UgDQ8ok59nT0ZzAXkElB5VlOVHrXFH09PSqUvp2HNXM=.3fd9b8dd-094f-40c1-ae43-4f311e7fa6cd@github.com>

On Mon, 18 Nov 2024 07:41:31 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change. Alternatively the diffs can be viewed on the API diff link attached on the CSR.

Update: Didn't notice you posted apidiff and javadoc beforehand:
APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22192#issuecomment-2484131045

From ihse at openjdk.org  Mon Nov 18 21:09:01 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Mon, 18 Nov 2024 21:09:01 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v9]
In-Reply-To: <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>
Message-ID: <GIwmq9CSUqLL1tOHEJcYkAS99mVf-u3ZCZGSsva3DxY=.b1a91fab-28f9-4dfe-b1dc-06a99c3743ba@github.com>

On Mon, 18 Nov 2024 15:50:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk version "24-internal" 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled main class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> Hopefully, this may be easier both for people trying to run something, and for people that are really looking for JShell.
>> 
>> What do you think?
>> 
>> Thanks!
>
> Jan Lahoda 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 'master' into JDK-8340133-2
>  - - suffixing <jarfile> and <sourcefile> with .jar and .java in both the concise and full help.
>    - using a stderr version instead of the stdout version.
>  - Reflecting review feedback:
>    - using "conciseVersionString" intead of "shortVersionString"
>    - using <jarfile>.jar <jarfile>
>  - Merge branch 'master' into JDK-8340133-2
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.
>  - Cleaning up the concise message:
>    - using 2 spaces instead of 4,
>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>  - Using an enum instead of booleans, as suggested.
>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/dfddbcaa...439fa40f

I think it makes sense to include the version. I have no strong opinions on the format. Is the extract in the PR description updated with the latest version changes?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2484129128

From chen.l.liang at oracle.com  Mon Nov 18 21:17:18 2024
From: chen.l.liang at oracle.com (Chen Liang)
Date: Mon, 18 Nov 2024 21:17:18 +0000
Subject: Q: Why is java.lang.Runtime non-final?
In-Reply-To: <CA+pBWhsUL1yusWf3PtTXwGRsxXNroyFBo0F_i9=uLBYNnkZ4EQ@mail.gmail.com>
References: <CA+pBWhsUL1yusWf3PtTXwGRsxXNroyFBo0F_i9=uLBYNnkZ4EQ@mail.gmail.com>
Message-ID: <SJ2PR10MB7669F596D77BE9ACB6C9D3C8A2272@SJ2PR10MB7669.namprd10.prod.outlook.com>

Hi Eirik,
I think it might have been a legacy oversight; note that even java.util.Arrays was just recently made final.

> If Runtime was made final it seems we could remove the CheckCSMs test.

I disagree; CheckCSMs test checks for missing CSM annotations when new caller sensitive methods are added, and to ensure other reflection changes do not tamper with the caller sensitive mechanism. The static/final requirements is just one minor aspect of that test.

Regards,
Chen Liang
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Eirik Bj?rsn?s <eirbjo at gmail.com>
Sent: Monday, November 18, 2024 2:38 PM
To: core-libs-dev <core-libs-dev at openjdk.org>
Subject: Q: Why is java.lang.Runtime non-final?


Hi,

Tried to find an answer to this question in JBS, but found nothing:

Since java.lang.Runtime has a single private constructor, it seems effectively final. Why is it not declared final?

If Runtime was made final it seems we could remove the CheckCSMs test.

Are there compatibility concerns here that I don't see?

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241118/6f072223/attachment.htm>

From naoto at openjdk.org  Mon Nov 18 21:19:48 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 21:19:48 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v2]
In-Reply-To: <tsE_umS_ITrV0uzkN8lOwxDIayFZ_V0ZfWx7Oov9sRU=.39215e1a-2e76-4836-8641-1fd8737aec8e@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <tsE_umS_ITrV0uzkN8lOwxDIayFZ_V0ZfWx7Oov9sRU=.39215e1a-2e76-4836-8641-1fd8737aec8e@github.com>
Message-ID: <khWdFb3UzNwDkUizJM9ZCcWlMr0gNANsanhDaOzsylk=.5709edfc-a003-4bfd-a461-8ebfb1485b50@github.com>

On Mon, 18 Nov 2024 21:07:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8344446: Address review comments
>  - 8344446: Remove security manager dependency from module jdk.sctp

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2443752647

From eirbjo at gmail.com  Mon Nov 18 21:23:55 2024
From: eirbjo at gmail.com (=?UTF-8?B?RWlyaWsgQmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 22:23:55 +0100
Subject: Q: Why is java.lang.Runtime non-final?
In-Reply-To: <SJ2PR10MB7669F596D77BE9ACB6C9D3C8A2272@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CA+pBWhsUL1yusWf3PtTXwGRsxXNroyFBo0F_i9=uLBYNnkZ4EQ@mail.gmail.com>
 <SJ2PR10MB7669F596D77BE9ACB6C9D3C8A2272@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <CA+pBWhuAfjK27DX7bJ_=YfpU3wDrB91jbLRAKJeJXGumFN9w9g@mail.gmail.com>

On Mon, Nov 18, 2024 at 10:17?PM Chen Liang <chen.l.liang at oracle.com> wrote:

> Hi Eirik,
> I think it might have been a legacy oversight; note that even
> java.util.Arrays was just recently made final.
>

Thanks, filed https://bugs.openjdk.org/browse/JDK-8344460 to track this
enhancement.


> > If Runtime was made final it seems we could remove the CheckCSMs test.
> I disagree; CheckCSMs test checks for missing CSM annotations when new
> caller sensitive methods are added, and to ensure other reflection changes
> do not tamper with the caller sensitive mechanism. The static/final
> requirements is just one minor aspect of that test.
>

Alright, sounds good. We can probably remove the Runtime methods registered
in this test though.

Eirik.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241118/c9583152/attachment-0001.htm>

From liach at openjdk.org  Mon Nov 18 21:23:47 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 21:23:47 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v4]
In-Reply-To: <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
Message-ID: <DVtJOBZzaYvL2nUldIso0Rbd4oQx4Vr7i2rkpNVY14Y=.cc25db53-937c-464e-bdad-aefc7d7bc09f@github.com>

On Mon, 18 Nov 2024 20:34:26 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
>> 
>> There are quite a few changes to review, but all relatively straightforward:
>> 
>> `DriverManager`
>> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
>> * Remove two now-unused package private SQLPermission constants
>> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
>> 
>> `CachedRowSetImpl`
>> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
>> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
>> 
>> `CachedRowSetWriter`
>> * A call to `ReflectUtil::checkPackageAccess` is removed.
>> 
>> `SerialJavaObject`
>> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
>> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
>> 
>> `SyncFactory`
>> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
>> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
>> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
>> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
>> 
>> `RowsetProvider`
>> *  Static initializer is updated to call `System::getProperty` directly
>> * `newFactory` is updated to call `System::getProperty` directly
>> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
>> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getSystemProperty` is removed
>> 
>> 
>> `SQLInputImpl`
>> *  A call to `ReflectUtil::checkPackageAccess` is removed
>> 
>>  `TestPolicy.java` in `test/java/sql/testng/util`
>> * This  is now unused and removed
>> 
>> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove ObjectStreamField#getType from UNSUPPORTED_VIRTUAL_METHODS, a leftover from JDK-8344034

test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java line 1:

> 1: /*

Your mailing list message recommends removal of this test. This test covers more than ensuring that CSMs are final or static; it actually scans all platform classes to ensure CSMs are present wherever they are needed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22185#discussion_r1847290956

From liach at openjdk.org  Mon Nov 18 21:27:46 2024
From: liach at openjdk.org (Chen Liang)
Date: Mon, 18 Nov 2024 21:27:46 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
Message-ID: <QyyoeIOR6DeE4r69uj7fDS198hGLVd_xYL2qeXv5NDU=.dbf09e43-abb0-4560-898d-37929c9615f9@github.com>

On Mon, 18 Nov 2024 15:22:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

A straightforward example.  Don't know which area this belongs to exactly, though.

-------------

Marked as reviewed by liach (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22208#pullrequestreview-2443764719

From eirbjo at openjdk.org  Mon Nov 18 21:28:49 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Mon, 18 Nov 2024 21:28:49 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v4]
In-Reply-To: <DVtJOBZzaYvL2nUldIso0Rbd4oQx4Vr7i2rkpNVY14Y=.cc25db53-937c-464e-bdad-aefc7d7bc09f@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
 <DVtJOBZzaYvL2nUldIso0Rbd4oQx4Vr7i2rkpNVY14Y=.cc25db53-937c-464e-bdad-aefc7d7bc09f@github.com>
Message-ID: <fCj60QlagZrFzcBkZVPPiZhkc3UZ58QUc4nCtCf5B6c=.a0ed929c-3634-41b6-b788-57cade9a1c8d@github.com>

On Mon, 18 Nov 2024 21:20:02 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Remove ObjectStreamField#getType from UNSUPPORTED_VIRTUAL_METHODS, a leftover from JDK-8344034
>
> test/jdk/jdk/internal/reflect/CallerSensitive/CheckCSMs.java line 1:
> 
>> 1: /*
> 
> Your mailing list message recommends removal of this test. This test covers more than ensuring that CSMs are final or static; it actually scans all platform classes to ensure CSMs are present wherever they are needed.

Sure, I'll leave the test with the empty set as suggested by Roger.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22185#discussion_r1847297571

From jlu at openjdk.org  Mon Nov 18 21:30:01 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Nov 2024 21:30:01 GMT
Subject: RFR: 8344331: SM cleanup in java.scripting [v2]
In-Reply-To: <O_tPgxSmIrPoewlOGjPkDH2qPUhXtc2GSXMLARR3mTw=.a88a42f7-2530-4696-af8a-f3bc9c7bd866@github.com>
References: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
 <O_tPgxSmIrPoewlOGjPkDH2qPUhXtc2GSXMLARR3mTw=.a88a42f7-2530-4696-af8a-f3bc9c7bd866@github.com>
Message-ID: <u49VUft_-uSF6xrrRSRalvlknFSx10ZBODLqc_TzpHY=.12c4b1ab-e7da-4ab8-bd2c-ea5a603a5bcc@github.com>

On Sat, 16 Nov 2024 00:03:23 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR which removes the lone `AccessController.doPrivileged` call from the _java.scripting_ module after JEP486 integration.
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   remove local var 'sl'

Thanks for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22170#issuecomment-2484165179

From jlu at openjdk.org  Mon Nov 18 21:30:01 2024
From: jlu at openjdk.org (Justin Lu)
Date: Mon, 18 Nov 2024 21:30:01 GMT
Subject: Integrated: 8344331: SM cleanup in java.scripting
In-Reply-To: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
References: <fTeqmEkL80MpfSAcyvlkRUNTwnPQCNHomiAWsQnq3qw=.fcb9ae3a-b50a-4e22-a356-5ad5b41a9ea2@github.com>
Message-ID: <UNijyDu0Ce4pzwMB6rBafQWpuGoWiirRXx6CGGseTZo=.e24ebcbe-cdec-469c-ae72-56e01a684766@github.com>

On Fri, 15 Nov 2024 23:23:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the lone `AccessController.doPrivileged` call from the _java.scripting_ module after JEP486 integration.

This pull request has now been integrated.

Changeset: 8d43e0d6
Author:    Justin Lu <jlu at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/8d43e0d664aca03f3e8f66812c184a85847fc105
Stats:     6 lines in 1 file changed: 0 ins; 4 del; 2 mod

8344331: SM cleanup in java.scripting

Reviewed-by: naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/22170

From bpb at openjdk.org  Mon Nov 18 21:41:54 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 21:41:54 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v2]
In-Reply-To: <tsE_umS_ITrV0uzkN8lOwxDIayFZ_V0ZfWx7Oov9sRU=.39215e1a-2e76-4836-8641-1fd8737aec8e@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <tsE_umS_ITrV0uzkN8lOwxDIayFZ_V0ZfWx7Oov9sRU=.39215e1a-2e76-4836-8641-1fd8737aec8e@github.com>
Message-ID: <j3zq6uAnwXTkuTeGrUM7KX9YS7hdcevfw3pywCKKsYk=.cd439da0-1745-443d-81aa-51f1156ddae5@github.com>

On Mon, 18 Nov 2024 21:07:59 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8344446: Address review comments
>  - 8344446: Remove security manager dependency from module jdk.sctp

The SCTP changes in db92e04 should not be in this PR. A Git error on my part; will remove.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22219#issuecomment-2484185132

From smarks at openjdk.org  Mon Nov 18 21:41:54 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 18 Nov 2024 21:41:54 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <GVm9b-jRlU3gfqbcdqFK7aB5MBtgVQL9OwLHs5V3RJ8=.379a701b-5e8c-409e-9907-c02cd72c89fc@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
 <GVm9b-jRlU3gfqbcdqFK7aB5MBtgVQL9OwLHs5V3RJ8=.379a701b-5e8c-409e-9907-c02cd72c89fc@github.com>
Message-ID: <05CxNHByh62Xh4PMpwQyqbWK6__a8Am0ndWionnCVJk=.8a8f23b4-9da6-4984-89f8-e018ba2a5659@github.com>

On Mon, 18 Nov 2024 17:39:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> First cut at removal of Security Manager stuff from RMI.
>> 
>> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
>> 
>> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff.
>
> src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java line 65:
> 
>> 63:     /**
>> 64:      * special child of the system thread group for running tasks that
>> 65:      * may execute user code, so that the security policy for threads in
> 
> Do we still want to mention `security policy` here?

Yeah, I should probably edit that. I don't want to change the thread group behavior, so the justification for the thread group might mention the (historical) effect on security policy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847310716

From smarks at openjdk.org  Mon Nov 18 21:41:55 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 18 Nov 2024 21:41:55 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <jk9xmu18wPuwd5Prr4yvxiwGeYOIpI_mnT6VJGKYpLk=.9c36ab89-1438-4357-b434-1d250a0d3041@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
 <GVm9b-jRlU3gfqbcdqFK7aB5MBtgVQL9OwLHs5V3RJ8=.379a701b-5e8c-409e-9907-c02cd72c89fc@github.com>
 <jk9xmu18wPuwd5Prr4yvxiwGeYOIpI_mnT6VJGKYpLk=.9c36ab89-1438-4357-b434-1d250a0d3041@github.com>
Message-ID: <gOpsC4eS6DGmbvVc4w2JMSZblYmfrcMwDWj_vo1q-Cw=.844a4e48-4f14-4c52-b806-f5114e3bfc88@github.com>

On Mon, 18 Nov 2024 18:05:12 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/java.rmi/share/classes/sun/rmi/server/MarshalInputStream.java line 69:
>> 
>>> 67: 
>>> 68:     /** table to hold sun classes to which access is explicitly permitted */
>>> 69:     protected static Map<String, Class<?>> permittedSunClasses
>> 
>> It looks like `permittedSunClasses` map can be removed alongside to `checkSunClass(String, AccessControlException)` method, since it is only called on [line 198](https://github.com/openjdk/jdk/pull/22129/files#diff-491ee160d740152081c000fc513091e00181c41fd3c423c466fd30448a2a47e6R198):
>> 
>> } catch (@SuppressWarnings("removal") AccessControlException e) {
>>      return checkSunClass(className, e);
>
> Sorry, missed your comment in a PR description - ignore the comment above

Right, this will be covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847311299

From smarks at openjdk.org  Mon Nov 18 21:46:43 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 18 Nov 2024 21:46:43 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <Px2jNqhg5Yt2V-AnbcYfvHrAguqB8nZKvX_3FYAb5fs=.451085a4-a353-4364-9a18-464fd2f226f3@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
 <Px2jNqhg5Yt2V-AnbcYfvHrAguqB8nZKvX_3FYAb5fs=.451085a4-a353-4364-9a18-464fd2f226f3@github.com>
Message-ID: <hzM8_fVva1IgflKe5M9unUN8S57AgaAZzR1-tRuxfZ4=.a9f6854e-35e0-4944-be26-4021a57f6fa4@github.com>

On Mon, 18 Nov 2024 18:49:57 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> First cut at removal of Security Manager stuff from RMI.
>> 
>> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
>> 
>> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff. EDIT: I've filed [JDK-8344461](https://bugs.openjdk.org/browse/JDK-8344461) to cover this additional cleanup work.
>
> src/java.rmi/share/classes/sun/rmi/runtime/NewThreadAction.java line 49:
> 
>> 47:  * @author      Peter Jones
>> 48:  **/
>> 49: public final class NewThreadAction {
> 
> Suggest inlining the methods and getting rid of the class, moving non-trivial methods to an existing Util class.
> Or at least renaming it to to drop the "Action" that is indicative of doPrivileged.

Yes, further cleanup should be done here. I had started on it but I backed away since it felt like a distraction from the initial pass of removing direct SecurityManager and AccessController calls. I've filed [JDK-8344461](https://bugs.openjdk.org/browse/JDK-8344461) to cover the followup work.

> src/java.rmi/share/classes/sun/rmi/transport/tcp/TCPChannel.java line 404:
> 
>> 402:      */
>> 403:     public void startNewAcceptor() {
>> 404:         Thread t =
> 
> Fold to previous line.

Can do.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847316436
PR Review Comment: https://git.openjdk.org/jdk/pull/22129#discussion_r1847316561

From cstein at openjdk.org  Mon Nov 18 21:52:51 2024
From: cstein at openjdk.org (Christian Stein)
Date: Mon, 18 Nov 2024 21:52:51 GMT
Subject: Integrated: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
Message-ID: <BU52JDpua88oByRbQfpCMfR6Pbgrdu9lgGKWncCNH18=.f1205158-83f2-4a85-8335-fd0e7261d0b7@github.com>

On Mon, 18 Nov 2024 15:22:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

This pull request has now been integrated.

Changeset: 5cb0d438
Author:    Christian Stein <cstein at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/5cb0d438231383d491b2fcca455d09af7f2ee016
Stats:     3 lines in 1 file changed: 2 ins; 0 del; 1 mod

8293040: Argfile documentation for java launcher tool is confusing regarding usage of wildcards

Reviewed-by: liach

-------------

PR: https://git.openjdk.org/jdk/pull/22208

From bpb at openjdk.org  Mon Nov 18 21:56:12 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Mon, 18 Nov 2024 21:56:12 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v3]
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8344446: Revert spurious inclusion of SCTP changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22219/files
  - new: https://git.openjdk.org/jdk/pull/22219/files/c7ba3354..a15574a3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22219&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22219&range=01-02

  Stats: 59 lines in 3 files changed: 54 ins; 0 del; 5 mod
  Patch: https://git.openjdk.org/jdk/pull/22219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22219/head:pull/22219

PR: https://git.openjdk.org/jdk/pull/22219

From smarks at openjdk.org  Mon Nov 18 21:57:04 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Mon, 18 Nov 2024 21:57:04 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi [v2]
In-Reply-To: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
Message-ID: <YTTCLTKq-OuCmjvJuyGGcLPdzBEvfxe9ejh83I3NUXU=.1bcdf947-3ecf-41da-bf30-d24de99528bb@github.com>

> First cut at removal of Security Manager stuff from RMI.
> 
> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
> 
> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff. EDIT: I've filed [JDK-8344461](https://bugs.openjdk.org/browse/JDK-8344461) to cover this additional cleanup work.

Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:

  Update with changes from code review.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22129/files
  - new: https://git.openjdk.org/jdk/pull/22129/files/1e7e88a7..f8e63868

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22129&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22129&range=00-01

  Stats: 8 lines in 2 files changed: 1 ins; 1 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22129.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22129/head:pull/22129

PR: https://git.openjdk.org/jdk/pull/22129

From almatvee at openjdk.org  Mon Nov 18 22:45:53 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 18 Nov 2024 22:45:53 GMT
Subject: RFR: 8336087: Doccheck: the jpackage command page doesn't show the
 correct command-line options
In-Reply-To: <EMqlFQpnM8EVIutihC6dZ-ZR8ReMDtpQKBUCplV-BEU=.39cdcc24-ff7c-4cf4-83c6-e63071b79f32@github.com>
References: <EMqlFQpnM8EVIutihC6dZ-ZR8ReMDtpQKBUCplV-BEU=.39cdcc24-ff7c-4cf4-83c6-e63071b79f32@github.com>
Message-ID: <11J7khGxbSUAuUH_ajfHVJPjDFzrPeGvCqSabjVrqnw=.f2ca2d9a-9a53-47f2-8aef-388551e01ba1@github.com>

On Mon, 18 Nov 2024 13:21:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Simple typo fix.
> 
> Old view: https://github.com/openjdk/jdk/blob/dfddbcaab886b9baa731cd748bb7f547e1903b64/src/jdk.jpackage/share/man/jpackage.md
> 
> New view: https://github.com/alexeysemenyukoracle/jdk/blob/JDK-8336087/src/jdk.jpackage/share/man/jpackage.md
> 
> Navigate to "Group value of the RPM" text to see the diff

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22206#pullrequestreview-2443900362

From bchristi at openjdk.org  Mon Nov 18 22:48:47 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Mon, 18 Nov 2024 22:48:47 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v4]
In-Reply-To: <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
Message-ID: <h4NxvoCtrkjpp0rfI4wuOvK5wfdw-45Xi8EzdfQvjJY=.310e8881-8392-4d1d-8da0-9b30888fe4b1@github.com>

On Mon, 18 Nov 2024 20:34:26 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
>> 
>> There are quite a few changes to review, but all relatively straightforward:
>> 
>> `DriverManager`
>> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
>> * Remove two now-unused package private SQLPermission constants
>> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
>> 
>> `CachedRowSetImpl`
>> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
>> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
>> 
>> `CachedRowSetWriter`
>> * A call to `ReflectUtil::checkPackageAccess` is removed.
>> 
>> `SerialJavaObject`
>> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
>> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
>> 
>> `SyncFactory`
>> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
>> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
>> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
>> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
>> 
>> `RowsetProvider`
>> *  Static initializer is updated to call `System::getProperty` directly
>> * `newFactory` is updated to call `System::getProperty` directly
>> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
>> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getSystemProperty` is removed
>> 
>> 
>> `SQLInputImpl`
>> *  A call to `ReflectUtil::checkPackageAccess` is removed
>> 
>>  `TestPolicy.java` in `test/java/sql/testng/util`
>> * This  is now unused and removed
>> 
>> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove ObjectStreamField#getType from UNSUPPORTED_VIRTUAL_METHODS, a leftover from JDK-8344034

I think the changes look fine.

-------------

Marked as reviewed by bchristi (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22185#pullrequestreview-2443910045

From almatvee at openjdk.org  Mon Nov 18 22:53:53 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 18 Nov 2024 22:53:53 GMT
Subject: RFR: 8342299: Document that jpackage includes (possibly old) VC
 Redistributable MSVCP140.dll from JDK
In-Reply-To: <n7qPzuZYqFKRPTrTsndU-0g3rCDM44gd4Ywm33Rax5A=.147dd696-e7b9-4f10-b494-27b60c9fb30c@github.com>
References: <n7qPzuZYqFKRPTrTsndU-0g3rCDM44gd4Ywm33Rax5A=.147dd696-e7b9-4f10-b494-27b60c9fb30c@github.com>
Message-ID: <ES_DkS5BRyKFKJQxuQxF6aEDdcb2EQVjwrlUeUnRw5E=.12f80e46-d4fe-48b5-9775-8aee368e49f3@github.com>

On Mon, 18 Nov 2024 15:45:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage man page update

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22209#pullrequestreview-2443917267

From rriggs at openjdk.org  Mon Nov 18 22:55:43 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Mon, 18 Nov 2024 22:55:43 GMT
Subject: RFR: 8344149: Remove usage of Security Manager from java.rmi [v2]
In-Reply-To: <YTTCLTKq-OuCmjvJuyGGcLPdzBEvfxe9ejh83I3NUXU=.1bcdf947-3ecf-41da-bf30-d24de99528bb@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
 <YTTCLTKq-OuCmjvJuyGGcLPdzBEvfxe9ejh83I3NUXU=.1bcdf947-3ecf-41da-bf30-d24de99528bb@github.com>
Message-ID: <EgO9WzVIN3wKFK46cZ0-g6Mu6i3-MLkq9QDMvfSJcmw=.8c08208e-21a5-4828-9a61-62e65227e0ec@github.com>

On Mon, 18 Nov 2024 21:57:04 GMT, Stuart Marks <smarks at openjdk.org> wrote:

>> First cut at removal of Security Manager stuff from RMI.
>> 
>> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
>> 
>> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff. EDIT: I've filed [JDK-8344461](https://bugs.openjdk.org/browse/JDK-8344461) to cover this additional cleanup work.
>
> Stuart Marks has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update with changes from code review.

looks fine.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22129#pullrequestreview-2443918436

From mbalao at openjdk.org  Mon Nov 18 23:01:41 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Mon, 18 Nov 2024 23:01:41 GMT
Subject: RFR: 8328119: SunPKCS#11 implementation of HKDF [v2]
In-Reply-To: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com>
References: <9y6jX-3xptrETdeCxivQylFXGFH07lwbtBwDlsNLw54=.8cb0fc4c-8ff8-4b6d-9394-f26060916399@github.com>
Message-ID: <cAb8O2u0X7Pb3HQhg2Ch2oVutXGAhvVBONioJOKSmrk=.52fb6e7c-8cce-4459-b228-3fcb1e69e2b8@github.com>

> We would like to propose an implementation of the HKDF algorithms for SunPKCS11, aligned with the KDF API proposed for JDK 24 (see [JEP 478: Key Derivation Function API (Preview)](https://bugs.openjdk.org/browse/JDK-8189808)).
> 
> This implementation will be under the _Preview_ umbrella until the KDF API becomes stable in a future JDK release. The benefit of this early proposal is to gather more feedback about the KDF API for future improvements.
> 
> The `P11KDF` class has the core implementation and Java calls to the PKCS 11 API. Different native mechanism were used to merge key material: CKM_CONCATENATE_BASE_AND_DATA (key and data), CKM_CONCATENATE_BASE_AND_KEY (key and key) and CKM_CONCATENATE_DATA_AND_BASE (data and key). The implementation also supports merging data with data, at the Java level. List of HKDF algorithms supported: HKDF-SHA1, HKDF-SHA224, HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512.
> 
> Derivation modes supported: extract, expand, and, extract-expand.
> 
> We further advanced the consolidation of algorithm and key info in the P11SecretKeyFactory map ?this effort started with the PBE support enhancement and has helped to avoid duplication?. The map has now information about HMAC (`HMACKeyInfo` class) and HKDF (`HKDFKeyInfo` class) algorithms. P11Mac is now aligned to take the information from the map.
> 
> Generic keys now supported in SecretKeyFactory. Derived keys could be Generic.
> 
> Testing
> 
>  * [TestHKDF.java](https://github.com/openjdk/jdk/blob/e87ec99b90ff742f531a5031fdeeb9f2e039856d/test/jdk/sun/security/pkcs11/KDF/TestHKDF.java) test added
>    * All RFC 5869 test vectors checked (7 tests)
>    * Cross-checking against SunJCE's HKDF implementation for every algorithm possible
>       * Static assertion data for resilience if SunJCE were not available
>    * Use of derived key for encryption check
>    * Concatenation of input key material and salt checked (multiple combinations)
>    * Multiple derivation types checked (extract only, expand only, and, extract-expand)
>    * Derive key and derive data checked
>    * All supported HKDF algorithms tested (HKDF-SHA1, HKDF-SHA224, HKDF-SHA256, HKDF-SHA384, and, HKDF-SHA512)
>    * DH and ECDH key derivation for TLS checked
>    * Informative output for debugging purposes (shown automatically if there is a test failure)
>      * Note: test failures do not prevent all tests for running
>    * Test integrated to the SunPKCS11 tests framework
> 
>  * No regressions observed in jdk/sun/security/pkcs11 (114 tests passed, 0 failed)
> 
> A CSR...

Martin Balao has updated the pull request incrementally with one additional commit since the last revision:

  Algorithms renamed for alignment with SunJCE.
  
  Co-authored-by: Martin Balao Alonso <mbalao at redhat.com>
  Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22215/files
  - new: https://git.openjdk.org/jdk/pull/22215/files/e87ec99b..0c13f2cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22215&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22215&range=00-01

  Stats: 31 lines in 3 files changed: 0 ins; 0 del; 31 mod
  Patch: https://git.openjdk.org/jdk/pull/22215.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22215/head:pull/22215

PR: https://git.openjdk.org/jdk/pull/22215

From almatvee at openjdk.org  Mon Nov 18 23:41:53 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Mon, 18 Nov 2024 23:41:53 GMT
Subject: RFR: 8344322: Improve capabilities of jpackage test lib to
 validate error output of jpackage
In-Reply-To: <Z8rT9yMl4LFbpTnDKffpBhu9J4xiuVRsze4KxrYHnSY=.a507cdb8-8ddd-4e70-b5a9-4d6ccd67abaf@github.com>
References: <Z8rT9yMl4LFbpTnDKffpBhu9J4xiuVRsze4KxrYHnSY=.a507cdb8-8ddd-4e70-b5a9-4d6ccd67abaf@github.com>
Message-ID: <5OsOzveDdeK-7Am3k6BR7YuWQirKRNlIQjmhNkBrDLE=.ad843556-eb05-4fa2-aa06-fdfe49d41189@github.com>

On Mon, 18 Nov 2024 13:41:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Support using jpackage l10n keys instead of string values when examining jpackage error output.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22207#pullrequestreview-2444002472

From naoto at openjdk.org  Mon Nov 18 23:47:43 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Mon, 18 Nov 2024 23:47:43 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v3]
In-Reply-To: <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>
Message-ID: <yPGyJVnMiRTDFRuJu8_YEHl2yBK-JZ28HX7iF07yEvM=.1c00c839-5b29-476c-b4f3-237d0de5b6fa@github.com>

On Mon, 18 Nov 2024 21:56:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344446: Revert spurious inclusion of SCTP changes

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2444007298

From almatvee at openjdk.org  Tue Nov 19 00:00:48 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Tue, 19 Nov 2024 00:00:48 GMT
Subject: RFR: 8344415: Restruct jpackage utility classes
In-Reply-To: <XWlQEer4GtF9Vz28SoF7dPJ74WghnRxZc05pPfkI8AQ=.1e607c0a-e6cf-4dd1-983f-f486a94b13cd@github.com>
References: <XWlQEer4GtF9Vz28SoF7dPJ74WghnRxZc05pPfkI8AQ=.1e607c0a-e6cf-4dd1-983f-f486a94b13cd@github.com>
Message-ID: <_HvBm5rfWqpAseXAJcj536D_B-mYIFODob02FIAe-Sk=.aaea410e-3c01-4af8-88c8-46b283c3d8ed@github.com>

On Mon, 18 Nov 2024 18:31:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move child classes of "jdk.jpackage.test.Functional" class to "jdk.jpackage.internal.util.function" package.
> Split "jdk.jpackage.internal.IOUtils" class in "PathUtils", "FileUtils", "XmlUtils" classes in "jdk.jpackage.internal.util" package.
> 
> Implmenetation didnt change except of `FileUtils.deleteRecursive()` that was cleared from the dependency on "AtomicReference".
> 
> Applied `bin/blessed-modifier-order.sh` script to the modified files.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22216#pullrequestreview-2444019214

From lancea at openjdk.org  Tue Nov 19 00:19:44 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 19 Nov 2024 00:19:44 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v3]
In-Reply-To: <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>
Message-ID: <i1q-rYiqF3vHbEcIKrpz2fQF6ivLaxQmdCitG9w4K7c=.488715ec-600c-4d48-8e84-4a86620b4c5d@github.com>

On Mon, 18 Nov 2024 21:56:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344446: Revert spurious inclusion of SCTP changes

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2444036092

From bchristi at openjdk.org  Tue Nov 19 00:51:49 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 00:51:49 GMT
Subject: RFR: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules [v4]
In-Reply-To: <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
 <py0lWPLjUU_lK7llYEgea0nh49pGR6AkXmVRBuuTLjU=.e5d23c70-bb39-418b-8461-29df6cf773fa@github.com>
Message-ID: <ZXOOn7QDeDkvwfV9Wha_dDafYTbmERsKGA0f4BLPcdg=.b2b9af19-86e0-47fa-9451-db9b8d0553c5@github.com>

On Mon, 18 Nov 2024 20:34:26 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
>> 
>> There are quite a few changes to review, but all relatively straightforward:
>> 
>> `DriverManager`
>> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
>> * Remove two now-unused package private SQLPermission constants
>> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
>> 
>> `CachedRowSetImpl`
>> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
>> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
>> 
>> `CachedRowSetWriter`
>> * A call to `ReflectUtil::checkPackageAccess` is removed.
>> 
>> `SerialJavaObject`
>> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
>> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
>> 
>> `SyncFactory`
>> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
>> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
>> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
>> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
>> 
>> `RowsetProvider`
>> *  Static initializer is updated to call `System::getProperty` directly
>> * `newFactory` is updated to call `System::getProperty` directly
>> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
>> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
>> * `getSystemProperty` is removed
>> 
>> 
>> `SQLInputImpl`
>> *  A call to `ReflectUtil::checkPackageAccess` is removed
>> 
>>  `TestPolicy.java` in `test/java/sql/testng/util`
>> * This  is now unused and removed
>> 
>> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.
>
> Eirik Bj?rsn?s has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove ObjectStreamField#getType from UNSUPPORTED_VIRTUAL_METHODS, a leftover from JDK-8344034

I submitted an internal automated test run and it passes cleanly.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22185#issuecomment-2484477494

From aefimov at openjdk.org  Tue Nov 19 00:53:22 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 19 Nov 2024 00:53:22 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v2]
In-Reply-To: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
Message-ID: <nUmdm2qAkhj91dOAKYssC1lVpahjlNC1UaNlo1i5eaU=.5d93a2c9-09af-4e22-b196-02a841f28ab0@github.com>

> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
> - The following two properties are removed:
>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>     - `com.sun.jndi.rmi.object.trustURLCodebase`
> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
> 
> These changes require a CSR that will be submitted soon.
> 
> ### Testing
> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  Implement Daniel suggestions, add missing new lines to test files

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22154/files
  - new: https://git.openjdk.org/jdk/pull/22154/files/6784ea1b..7b3edb84

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=00-01

  Stats: 23 lines in 5 files changed: 0 ins; 10 del; 13 mod
  Patch: https://git.openjdk.org/jdk/pull/22154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22154/head:pull/22154

PR: https://git.openjdk.org/jdk/pull/22154

From bchristi at openjdk.org  Tue Nov 19 01:00:52 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 01:00:52 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v11]
In-Reply-To: <yTGlChV6gSyRFN_7Vm2FNVWGcomGXSv5r7_vnPOqzM0=.c966918e-d540-4329-a492-c4713080f172@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <yTGlChV6gSyRFN_7Vm2FNVWGcomGXSv5r7_vnPOqzM0=.c966918e-d540-4329-a492-c4713080f172@github.com>
Message-ID: <Z2ZULt-MrJnxmK9XUChd9f6DPB7VPCh774ZyovFsEf0=.ad8c3454-a40f-4583-9eea-508e7261e570@github.com>

On Mon, 18 Nov 2024 09:46:50 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Drop --add-exports from the test

Changes requested by bchristi (Reviewer).

test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 46:

> 44: public class CleanableListTest {
> 45: 
> 46:     static final int SINGLE_NODE_CAPACITY = CleanableListTestHelper.NODE_CAPACITY - 1;

If `CleanableListTestHelper` uses a list without the `CleanerCleanable`, shouldn't we be able to test the full `NODE_CAPACITY` ?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22043#pullrequestreview-2439985994
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1847495395

From bchristi at openjdk.org  Tue Nov 19 01:00:53 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 01:00:53 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
Message-ID: <YJbWdEKTS6y489KhGS9G-ORDSbQjahR93KNb4kedNv0=.8fd500fe-d6e8-4e2a-bbd4-455562757fd2@github.com>

On Fri, 15 Nov 2024 19:30:06 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   prev is not needed

src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 239:

> 237:         /**
> 238:          * Head node. This is the only node with variable size.
> 239:          * All nodes linked from the head are always at full capacity.

Also, "This is the only node where PhantomCleanables are added" ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1844710141

From jpai at openjdk.org  Tue Nov 19 04:49:59 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 04:49:59 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
Message-ID: <3-vpqX4p4KfrCbJPKg2PCsloscNJ5uJ9xW7Ho0fxSwE=.77381ea5-47d8-4bb1-9609-4a83fda39370@github.com>

On Mon, 18 Nov 2024 15:22:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

Hello Christian, one part of the confusion noted in that linked issue https://bugs.openjdk.org/browse/JDK-8293040 is:

>  Wildcards (*) aren't allowed in these lists (such as specifying *.java).

is noted in the section which describes the contents of the argument files for `java`. As noted in the issue, this sentence doesn't appear to be conveying the right meaning because wildcard literal like `-Xlog:gc*=info,heap*=info` I believe is allowed in those files.

I see that the changes in this PR didn't address that sentence. Was that intentional?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22208#issuecomment-2484700075

From jpai at openjdk.org  Tue Nov 19 05:31:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 05:31:47 GMT
Subject: RFR: 8331735: UpcallLinker::on_exit races with GC when copying
 frame anchor
In-Reply-To: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>
References: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>
Message-ID: <qzzOTbp1mTaIJ6fMbxiLad18xEyKddQsc1yZ7RUruJs=.cd5571c6-28b2-416c-a5a6-4ebe21536357@github.com>

On Mon, 28 Oct 2024 13:53:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> There is a subtle race in `UpcallLinker::on_exit` between copying of the old frame anchor back into place, and the GC. Since this copy is not atomic, it may briefly appear as if a thread has no last Java frame, while still in the `_thread_in_native` state, which leads to the GC skipping processing of any active Java frames.
> 
> This code was originally adapted from `JavaCallWrapper::!JavaCallWrapper` - the JNI mechanism for upcalls - but in that case the frame anchor copy happens in the `_thread_in_vm` state, which means the GC will wait for the thread to get to a safepoint.
> 
> The solution proposed here is to do the frame anchor copy in the java thread state, before transitioning  back to the native state. The java thread state, like the vm thread state, is also 'safe' i.e. the GC will wait for the thread to get to a safepoint, so we can safely do our non-atomic copy of the frame anchor.
> 
> Additionally, this PR resolves a similar issue in `on_entry`, by moving the clearing of the pending exception (in case native code use a JNI API and didn't handle the exception afterwards). We now also skip checking for async exceptions when transitioning from native to java, so we don't immediately clear them. Any async exceptions will be picked up at the next safepoint instead.
> 
> Special thanks to @stefank and @fisk for finding the root cause, and @jaikiran for testing and debugging.
> 
> Testing: tier 1-4, 20k runs of the failing test on linux-aarch64.

Happy to see this addressed and as Jorn noted, thanks to Stefan and Erik for finding the root cause of this issue which was hard to reproduce and debug.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21742#issuecomment-2484739822

From eirbjo at openjdk.org  Tue Nov 19 05:46:06 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 05:46:06 GMT
Subject: Integrated: 8344365: SecurityManager cleanups in java.sql and
 java.sql.rowset modules
In-Reply-To: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
References: <9a0NcNL_g55OCfibeAXQG_dTfSbitIHG99_M6cFyAIA=.925b1475-2a92-4046-8f88-bfd37d2326ea@github.com>
Message-ID: <A4I9bubU5RZR7E7YmLKkTtlqRZYbWjyJTQQEEucHhbg=.ad70a404-cdc2-42d5-874f-83a0e55171e3@github.com>

On Sun, 17 Nov 2024 19:01:24 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which cleans up SecurityManager-related code in `java.sql` and `java.sql.rowset` modules post JEP-486
> 
> There are quite a few changes to review, but all relatively straightforward:
> 
> `DriverManager`
> * Remove `SecurityManager::checkPermission` calls in the `setLogWriter`, `setLogStream` and `deregisterDriver` methods
> * Remove two now-unused package private SQLPermission constants
> * `ensureDriversInitialized` is updated to remove `AccessController::doPrivileged` when reading a system property and when initializing drivers
> 
> `CachedRowSetImpl`
> *  Remove `AccessController::doPrivileged` when getting a `SyncFactory` instance
> * `getObject` is update to remove a call to `ReflectUtil::checkPackageAccess`
> 
> `CachedRowSetWriter`
> * A call to `ReflectUtil::checkPackageAccess` is removed.
> 
> `SerialJavaObject`
> *  `getFields` is updated to remove call to `ReflectUtil::checkPackageAccess`. `@CallerSensitive` is no longer needed for this method.
> * The test `CheckCSMs.java` is updated to remove references to `SerialJavaObject:getFields`
> 
> `SyncFactory`
> * `initMapIfNecessary` is updated to remove call to `AccessController::doPrivileged` when reading system properties and when reading properties from an input stream
> * `getInstance` is updated to remove calls to `ReflectUtil::checkPackageAccess`
> * `setLogger` method is updated to remove call to `SecurityManager::checkPermission`
> * `setJNDIContext` methods are updated to remove call to `SecurityManager::checkPermission`
> 
> `RowsetProvider`
> *  Static initializer is updated to call `System::getProperty` directly
> * `newFactory` is updated to call `System::getProperty` directly
> * `newFactory` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getContextClassLoader` is updated to not call `AccessController::doPrivileged`
> * `getFactoryClass` is updated to not call `ReflectUtil.checkPackageAccess`
> * `getSystemProperty` is removed
> 
> 
> `SQLInputImpl`
> *  A call to `ReflectUtil::checkPackageAccess` is removed
> 
>  `TestPolicy.java` in `test/java/sql/testng/util`
> * This  is now unused and removed
> 
> Ran `test/jdk/java/sql` and `test/jdk/javax/sql` tests locally. GHA results pending.

This pull request has now been integrated.

Changeset: d85dd77e
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/d85dd77edf18c6efd3a7438c0595cd729af2f863
Stats:     407 lines in 9 files changed: 10 ins; 353 del; 44 mod

8344365: SecurityManager cleanups in java.sql and java.sql.rowset modules

Reviewed-by: rriggs, bchristi

-------------

PR: https://git.openjdk.org/jdk/pull/22185

From jpai at openjdk.org  Tue Nov 19 05:46:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 05:46:46 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v7]
In-Reply-To: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
Message-ID: <i6lCEFyiV2yFLiWBxf-eTxAzedlbP-iZ3lBbDxjGaP8=.dca0445d-077a-4f5d-97a7-a90fb65951b3@github.com>

> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
> 
> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
> 
> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains seven additional commits since the last revision:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - 8341184: Clean up the interaction between the launcher native code and the LauncherHelper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21256/files
  - new: https://git.openjdk.org/jdk/pull/21256/files/47e3c33a..042b76ca

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=06
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=05-06

  Stats: 81618 lines in 1244 files changed: 38768 ins; 36912 del; 5938 mod
  Patch: https://git.openjdk.org/jdk/pull/21256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256

PR: https://git.openjdk.org/jdk/pull/21256

From cstein at openjdk.org  Tue Nov 19 06:11:52 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 19 Nov 2024 06:11:52 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
Message-ID: <FNMGmyux6a3V1XCEO6BZgqyEkWQV3dgCmSRLca7j314=.6bc8d902-ef11-41f1-b21f-d91e6269dd90@github.com>

On Mon, 18 Nov 2024 15:22:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

No, that was an oversight. Good catch!

I will remove that sentence (second last bullet point) in favor of the augmented one (third bullet point) of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22208#issuecomment-2484783967

From dholmes at openjdk.org  Tue Nov 19 06:15:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Nov 2024 06:15:48 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
Message-ID: <0J03VRAGirYpzQNQEHVJdDx7paVtxmvFYL3pQxs4Ijs=.e7d75f97-3f1e-47e6-8f0a-6b469291b834@github.com>

On Mon, 18 Nov 2024 15:22:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

src/java.base/share/man/java.md line 3079:

> 3077:     For example `*.java` stays `*.java` and is not expanded to `Foo.java`,
> 3078:     `Bar.java`, etc. like on some command line shell.
> 3079: 

This expansion now seems to be in conflict with the later statement:

Wildcards (*) aren't allowed in these lists (such as specifying *.java).

?? To be honest I'm not sure what that later statement is actually trying to say.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22208#discussion_r1847697791

From dholmes at openjdk.org  Tue Nov 19 06:15:48 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Nov 2024 06:15:48 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <0J03VRAGirYpzQNQEHVJdDx7paVtxmvFYL3pQxs4Ijs=.e7d75f97-3f1e-47e6-8f0a-6b469291b834@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
 <0J03VRAGirYpzQNQEHVJdDx7paVtxmvFYL3pQxs4Ijs=.e7d75f97-3f1e-47e6-8f0a-6b469291b834@github.com>
Message-ID: <fFPOzrU9HCkOzkrQHn6JumXIna3AyjSYe2F9n7A8prI=.c605a3d9-a4c5-4b1a-a6db-b2eb3b030ba6@github.com>

On Tue, 19 Nov 2024 06:12:21 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.
>
> src/java.base/share/man/java.md line 3079:
> 
>> 3077:     For example `*.java` stays `*.java` and is not expanded to `Foo.java`,
>> 3078:     `Bar.java`, etc. like on some command line shell.
>> 3079: 
> 
> This expansion now seems to be in conflict with the later statement:
> 
> Wildcards (*) aren't allowed in these lists (such as specifying *.java).
> 
> ?? To be honest I'm not sure what that later statement is actually trying to say.

Never mind I see now this was already flagged.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22208#discussion_r1847698402

From jpai at openjdk.org  Tue Nov 19 06:28:47 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 06:28:47 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <fFPOzrU9HCkOzkrQHn6JumXIna3AyjSYe2F9n7A8prI=.c605a3d9-a4c5-4b1a-a6db-b2eb3b030ba6@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
 <0J03VRAGirYpzQNQEHVJdDx7paVtxmvFYL3pQxs4Ijs=.e7d75f97-3f1e-47e6-8f0a-6b469291b834@github.com>
 <fFPOzrU9HCkOzkrQHn6JumXIna3AyjSYe2F9n7A8prI=.c605a3d9-a4c5-4b1a-a6db-b2eb3b030ba6@github.com>
Message-ID: <BwKWXenGbtz9naSimsLqp259Vl-doC7ui3Y8QUXKqBQ=.9c5315f2-9d5e-4299-a1d6-3717dad0d4d7@github.com>

On Tue, 19 Nov 2024 06:13:04 GMT, David Holmes <dholmes at openjdk.org> wrote:

>> src/java.base/share/man/java.md line 3079:
>> 
>>> 3077:     For example `*.java` stays `*.java` and is not expanded to `Foo.java`,
>>> 3078:     `Bar.java`, etc. like on some command line shell.
>>> 3079: 
>> 
>> This expansion now seems to be in conflict with the later statement:
>> 
>> Wildcards (*) aren't allowed in these lists (such as specifying *.java).
>> 
>> ?? To be honest I'm not sure what that later statement is actually trying to say.
>
> Never mind I see now this was already flagged.

I think that sentence was trying to convey that the "wildcard literal `*` will be treated literally and the launcher will not attempt to expand it". I think this sentence can be removed altogether, given that this semantic is already explained a few sentences above by the change in this PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22208#discussion_r1847709737

From dholmes at openjdk.org  Tue Nov 19 06:49:46 2024
From: dholmes at openjdk.org (David Holmes)
Date: Tue, 19 Nov 2024 06:49:46 GMT
Subject: RFR: 8331735: UpcallLinker::on_exit races with GC when copying
 frame anchor
In-Reply-To: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>
References: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>
Message-ID: <hi1S3ZzHdg6zZjg72DUYqqmvgWaLWUwGQkxvMtzdOFw=.455120d6-adc9-4216-aa0d-7eac182362a8@github.com>

On Mon, 28 Oct 2024 13:53:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> There is a subtle race in `UpcallLinker::on_exit` between copying of the old frame anchor back into place, and the GC. Since this copy is not atomic, it may briefly appear as if a thread has no last Java frame, while still in the `_thread_in_native` state, which leads to the GC skipping processing of any active Java frames.
> 
> This code was originally adapted from `JavaCallWrapper::!JavaCallWrapper` - the JNI mechanism for upcalls - but in that case the frame anchor copy happens in the `_thread_in_vm` state, which means the GC will wait for the thread to get to a safepoint.
> 
> The solution proposed here is to do the frame anchor copy in the java thread state, before transitioning  back to the native state. The java thread state, like the vm thread state, is also 'safe' i.e. the GC will wait for the thread to get to a safepoint, so we can safely do our non-atomic copy of the frame anchor.
> 
> Additionally, this PR resolves a similar issue in `on_entry`, by moving the clearing of the pending exception (in case native code use a JNI API and didn't handle the exception afterwards). We now also skip checking for async exceptions when transitioning from native to java, so we don't immediately clear them. Any async exceptions will be picked up at the next safepoint instead.
> 
> Special thanks to @stefank and @fisk for finding the root cause, and @jaikiran for testing and debugging.
> 
> Testing: tier 1-4, 20k runs of the failing test on linux-aarch64.

This seems quite reasonable. Ensuring the correct state for things like updating the frame_anchor is critical, so I wonder if we can assert we are in a safepoint-safe state when doing so?

I had to think long about the async exception deferral ... probably okay.

Thanks

-------------

Marked as reviewed by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21742#pullrequestreview-2444413977

From alanb at openjdk.org  Tue Nov 19 07:21:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 07:21:20 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <nbVDTH7g35D7RJWQcdmS5BXXEZ7WRVQFFhqqZTr0ha0=.b837c0d9-a578-4c30-ac40-b00782d18e89@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22158#pullrequestreview-2444463102

From alanb at openjdk.org  Tue Nov 19 07:21:20 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 07:21:20 GMT
Subject: RFR: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <q7HOZze-pOT-xhD2QnIAO7350rcQDMr87tjjXloqya4=.15a88427-6b11-4843-8141-474297b3781e@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
 <q7HOZze-pOT-xhD2QnIAO7350rcQDMr87tjjXloqya4=.15a88427-6b11-4843-8141-474297b3781e@github.com>
Message-ID: <Z57cSZcEr68u3dQO96Qy_b4if6Zxa3yEODA_Bj5alBI=.9d4cd699-1ba0-4ec0-9e96-7a6dd80e52a2@github.com>

On Mon, 18 Nov 2024 21:06:11 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Is this worthy of a release note?

There are hundreds of methods changed to no longer do permission checks, remaining permission checks do nothing anyway.  I would think the big release note for JEP 486 will provide an overall summary of the change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22158#issuecomment-2484870636

From alan.bateman at oracle.com  Tue Nov 19 07:44:54 2024
From: alan.bateman at oracle.com (Alan Bateman)
Date: Tue, 19 Nov 2024 07:44:54 +0000
Subject: Q: Why is java.lang.Runtime non-final?
In-Reply-To: <SJ2PR10MB7669F596D77BE9ACB6C9D3C8A2272@SJ2PR10MB7669.namprd10.prod.outlook.com>
References: <CA+pBWhsUL1yusWf3PtTXwGRsxXNroyFBo0F_i9=uLBYNnkZ4EQ@mail.gmail.com>
 <SJ2PR10MB7669F596D77BE9ACB6C9D3C8A2272@SJ2PR10MB7669.namprd10.prod.outlook.com>
Message-ID: <581268ba-2d9b-479d-b48d-4c2834ac4c45@oracle.com>



On 18/11/2024 21:17, Chen Liang wrote:
> Hi Eirik,
> I think it might have been a legacy oversight; note that even 
> java.util.Arrays was just recently made final.
>
> > If Runtime was made final it seems we could remove the CheckCSMs test.
>
> I disagree; CheckCSMs test checks for missing CSM annotations when new 
> caller sensitive methods are added, and to ensure other reflection 
> changes do not tamper with the caller sensitive mechanism. The 
> static/final requirements is just one minor aspect of that test.
>
Right, CheckCSMs is an important test. One of the good things about the 
SM removal is that many methods were @CS because of permission checks 
are no longer @CS. Better still is some @CS methods in non-final classes 
that could be overridden are no longer @CS, hence the need to update 
this test as part of several PRs.

-Alan
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241119/984f76a7/attachment.htm>

From jlu at openjdk.org  Tue Nov 19 07:58:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Nov 2024 07:58:22 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v2]
In-Reply-To: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
Message-ID: <8W7-Y64Rn1pVLuPfLoAktG-ekfebPelcoWQbxxiEMjE=.f07e118b-99ea-4ef0-909d-6141b08e4a55@github.com>

> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change.
> 
> APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
> Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  address Chen's review; make other similar changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22192/files
  - new: https://git.openjdk.org/jdk/pull/22192/files/6b2eff66..6b5b5cd0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22192&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22192&range=00-01

  Stats: 53 lines in 1 file changed: 5 ins; 6 del; 42 mod
  Patch: https://git.openjdk.org/jdk/pull/22192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22192/head:pull/22192

PR: https://git.openjdk.org/jdk/pull/22192

From jlu at openjdk.org  Tue Nov 19 07:58:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Tue, 19 Nov 2024 07:58:22 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v2]
In-Reply-To: <O57GqoLTBEtabzWDMOeoOAXR20htwuHtTBBHHxbKCYw=.0c083485-8426-4fb6-9957-9726594a7e43@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <O57GqoLTBEtabzWDMOeoOAXR20htwuHtTBBHHxbKCYw=.0c083485-8426-4fb6-9957-9726594a7e43@github.com>
Message-ID: <o5taAJFCDkIFk262TZHm12HSfYy3uPQ8k1bI3oShnBo=.3cde8c0f-33cc-44fd-973d-9accc57a39e6@github.com>

On Mon, 18 Nov 2024 20:37:27 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address Chen's review; make other similar changes
>
> src/java.base/share/classes/java/util/Locale.java line 94:
> 
>> 92:  * <p> A {@code Locale} is composed of the bolded fields described below; note that a
>> 93:  * {@code Locale} need not have all such fields. For example, {@link
>> 94:  * Locale#ENGLISH Locale.ENGLISH} is only comprised of the <em>language</em> field.
> 
> Side remark: in the `Locale` class itself, you can just use `{@link #ENGLISH Locale.ENGLISH}` to generate the link.

Thanks for taking a look Chen.

https://github.com/openjdk/jdk/pull/22192/commits/6b5b5cd067a42dbb98033314851255841e0d91fb should address your comments, and includes other changes that are in line with your suggestions. The apidiff and javadoc links have also been refreshed.

> Update: Didn't notice you posted apidiff and javadoc beforehand:
> APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
> Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html

(Sorry, I should have linked these directly on this PR).

> src/java.base/share/classes/java/util/Locale.java line 120:
> 
>> 118:  *
>> 119:  *   <dd> <em>Syntax:</em> Well-formed {@code language} values have the form {@code [a-zA-Z]{2,8}}.
>> 120:  *   BCP 47 deviation: this is not the full BCP 47 language production, since it excludes
> 
> Should we add `<br>` before these deviations for more straightforward rendering?

Good point. Went ahead and just prefixed with a `<dd>` instead (for consistency).

> src/java.base/share/classes/java/util/Locale.java line 500:
> 
>> 498:  * <p>Because of these issues, it is recommended that apps migrate
>> 499:  * away from constructing non-conforming locales and use the
>> 500:  * {@link #forLanguageTag} and {@link Locale.Builder} APIs instead.
> 
> Same remarks for links, add a override render text to prevent javadoc from generating long parameter lists.

I gave the `Locale.of` links an explicit render. I think the `forLanguageTag` links were fine w/o an explicit render, as long as `{@link #forLanguageTag(String)}` was used, not `{@link #forLanguageTag}` (so that the fully qualified class name is omitted).

On a side note, the default render was pretty nasty for the `Locale.LanguageRange` see tags.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847824296
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847826300
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1847831453

From alanb at openjdk.org  Tue Nov 19 08:01:53 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 08:01:53 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v3]
In-Reply-To: <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>
Message-ID: <gBg11daChj4EjyUkoClLcNSIn7Z5aPKXN-RGMM4Wlzg=.68d03bfa-bf38-45df-8751-ec2a3a595b20@github.com>

On Mon, 18 Nov 2024 21:56:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344446: Revert spurious inclusion of SCTP changes

Looks fine, just re-check the FIS/FOS constructors as original check file==null was for the SM usage.

src/java.base/share/classes/java/io/FileInputStream.java line 136:

> 134:         if (name == null) {
> 135:             throw new NullPointerException();
> 136:         }

I assume (old) L133-139 can be replaced with `String name = file.getPath()`, the explicit check that name is null goes away with the SM check.

src/java.base/share/classes/java/io/FileOutputStream.java line 205:

> 203:         if (name == null) {
> 204:             throw new NullPointerException();
> 205:         }

Same comment as the FOS constructor.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2444622317
PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847840569
PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1847840985

From davidalayachew at gmail.com  Tue Nov 19 08:02:02 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 19 Nov 2024 03:02:02 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
 <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
Message-ID: <CAA9v-_OZthghej7ud+TM_FSQ1gZsWS=5j22Xvy_24uYrEipz2A@mail.gmail.com>

Poking the thread in case you are able to answer my previous question
Viktor.

Also, another question -- I posted this thread to Reddit, and some good
discussion has already started. Can you or someone else answer some of the
questions that have popped up there?

https://old.reddit.com/r/java/comments/1gukzhb/a_surprising_pain_point_regarding_parallel_java/

Ty vm!

On Thu, Nov 14, 2024 at 5:45?PM David Alayachew <davidalayachew at gmail.com>
wrote:

> Oh ok. So it truly is a toss-up depending on each implementation when and
> where this occurs.
>
> Ok, then as my final request, I think even informing the user that this
> CAN occur is worth doing. If nothing else, the user scouring the
> documentation for documentation of this behaviour will know that it is
> simply something that can occur. They don't need to know all the details.
> Simply give it a official term, describe the behaviour, tell that it is
> implementation specific on when this happens, but that it is only possible
> during parallelism. Even just knowing the verbiage to describe the problem
> will enable them to better communicate with each other on what they want vs
> what they get. That helps searchability, if nothing else.
>
> On Thu, Nov 14, 2024, 8:45?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
>> I see what you're saying, the problem is that it depends on the Stream
>> implementation (given that Stream is an interface).
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Thursday, 14 November 2024 12:36
>> *To:* Viktor Klang <viktor.klang at oracle.com>
>> *Cc:* Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <
>> core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Then let me correct myself again, while simplifying -- I just want that
>> detail, that certain combinations might lead to pre-fetching everything, to
>> be documented on the stream api. Package level, or on the Stream interface
>> itself, seems like a good spot.
>>
>> On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>>
>> The issue here is that the operation cannot advertise this, as it depends
>> on the combination of operations.
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
>> David Alayachew <davidalayachew at gmail.com>
>> *Sent:* Wednesday, 13 November 2024 14:07
>> *To:* Rob Spoor <openjdk at icemanx.nl>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> That is a good point Rob.
>>
>> Then let me correct myself -- I think the terminal operations don't do a
>> great job of advertising whether or not they pre-fetch everything when
>> parallelism is activated. Collector fetches as needed. FindAny pre-fetches
>> everything. I understand that later releases might change their behaviour,
>> but I still want to document the current behaviour in the official javadocs
>> so that we can limit undocumented tripping hazards.
>>
>>
>> On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl> wrote:
>>
>> distinct() doesn't require everything to be pulled. It can push elements
>> to the downstream as they come along for the first time. When
>> downstream.push returns false the gatherer is done.
>>
>> As part of some experimentation I've implemented all intermediary
>> operations using gatherers. Most of them are pretty straightforward and
>> will stop integrating once the downstream starts rejecting elements
>> (although some use Gatherer.ofSequential to keep it easy). I only found
>> two exceptions that don't return the result of downstream.push:
>>
>> * mapMulti. The downstream.push is passed as the mapper which is a
>> Consumer - the return value is ignored. With some more effort it's
>> probably possible to capture any false return value and return that from
>> the integrator, but I haven't tried that yet.
>>
>> * sorted. Obviously every element needs to be inspected.
>>
>>
>> On 13/11/2024 00:37, David Alayachew wrote:
>> > Oh sure, I expect something like distinct() to pull everything. In
>> order to
>> > know if something is distinct, you have to do some variant of "check
>> > against everyone else". Whether that is holding all instances in memory
>> or
>> > their hashes, it's clear from a glance that you will need to look at
>> > everything, and therefore, pre-fetching makes intuitive sense to me.
>> >
>> > I 100% did not expect terminal operations like findAny() or reduce() to
>> > pull the whole data set. That was a complete whiplash for me. The method
>> > findAny() advertises itself as a short-circuiting operation, so to find
>> out
>> > that it actually pulls the whole data set anyways was shocking.
>> >
>> > And that was my biggest pain point -- looking at the documentation, it
>> is
>> > not clear to me at all that methods like findAny() would pull in all
>> data
>> > upon becoming parallel().
>> >
>> > Do you think it would make sense to add documentation about this to the
>> > javadocs for Stream/java.util.stream? Or maybe it is already there and I
>> > misunderstood it (even after reading through it thoroughly over 5
>> times).
>> >
>> >
>> > On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
>> wrote:
>> >
>> >>> We are told how Streams can process unbounded data sets, but when it
>> >> tries to do a findAny() with parallel(), it runs into an OOME because
>> it
>> >> fetched all the data ahead of time. In fact, almost of the terminal
>> >> operations will hit an OOME in the exact same way if they are parallel
>> and
>> >> have a big enough data set. It's definitely not the end of the world,
>> but
>> >> it seems that I have to fit everything into a Collector and/or a
>> Gatherer
>> >> if I want to avoid pre-fetching everything.
>> >>
>> >> Yeah, I think it is important to distinguish "can process unbounded
>> data
>> >> sets" from "always able to process unbounded data sets".
>> >>
>> >> Some operations inherently need the end of the stream, so even
>> something
>> >> somple like: stream.distinct() or stream.sorted() can end up pulling
>> in all
>> >> data (which of course won't terminate).
>> >>
>> >> Fortunately, I think Gatherers can unlock much more situations where
>> >> unbounded streams can be processed.
>> >>
>> >> Cheers,
>> >> ?
>> >>
>> >>
>> >> *Viktor Klang*
>> >> Software Architect, Java Platform Group
>> >> Oracle
>> >> ------------------------------
>> >> *From:* David Alayachew <davidalayachew at gmail.com>
>> >> *Sent:* Tuesday, 12 November 2024 15:08
>> >> *To:* Viktor Klang <viktor.klang at oracle.com>
>> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> >> fetching too many elements
>> >>
>> >>
>> >> Oh woah. I certainly did not. Or rather, I had dismissed the idea as
>> soon
>> >> as I thought of it.
>> >>
>> >>
>> >> I hand-waved away the idea because I thought that the method would turn
>> >> the stream pipeline parallel, thus, recreating the same problem I
>> currently
>> >> have of parallelism causing all of the elements to be fetched ahead of
>> >> time, causing an OOME.
>> >>
>> >>
>> >> It did NOT occur to me that the pipeline would stay sequential, and
>> just
>> >> kick these off sequentially, but have them executing in parallel. I
>> can't
>> >> see why I came to that incorrect conclusion. I have read the javadocs
>> of
>> >> this method several times. Though, to be fair, I came to the same,
>> >> incorrect conclusion about Collectors.groupingByConcurrent(), and it
>> wasn't
>> >> until someone pointed out what the documentation was actually saying
>> that I
>> >> realized it's true properties.
>> >>
>> >> Thanks. That definitely solves at least part of my problem. Obviously,
>> I
>> >> would prefer to write to S3 in parallel too, but at the very least, the
>> >> calculation part is being done in parallel. And worst case scenario, I
>> can
>> >> be really bad and just do the write to S3 in the mapConcurrent, and
>> then
>> >> just return the metadata of each write, and just bundle that up with
>> >> collect.
>> >>
>> >>
>> >> And that's ignoring the fact that I can just use the workaround too.
>> >>
>> >>
>> >> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to
>> me
>> >> from a performance perspective, but is rather unintuitive to me from a
>> >> usability perspective. We are told how Streams can process unbounded
>> data
>> >> sets, but when it tries to do a findAny() with parallel(), it runs
>> into an
>> >> OOME because it fetched all the data ahead of time. In fact, almost of
>> the
>> >> terminal operations will hit an OOME in the exact same way if they are
>> >> parallel and have a big enough data set. It's definitely not the end
>> of the
>> >> world, but it seems that I have to fit everything into a Collector
>> and/or a
>> >> Gatherer if I want to avoid pre-fetching everything.
>> >>
>> >> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
>> >> wrote:
>> >>
>> >> Have you considered Gatherers.mapConcurrent(?)?
>> >>
>> >>
>> >> Cheers,
>> >> ?
>> >>
>> >>
>> >> *Viktor Klang*
>> >> Software Architect, Java Platform Group
>> >> Oracle
>> >> ------------------------------
>> >> *From:* David Alayachew <davidalayachew at gmail.com>
>> >> *Sent:* Tuesday, 12 November 2024 01:53
>> >> *To:* Viktor Klang <viktor.klang at oracle.com>
>> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> >> fetching too many elements
>> >>
>> >> Good to know, ty vm.
>> >>
>> >> At the very least, I have this workaround. This will meet my needs for
>> now.
>> >>
>> >> I guess my final question would be -- is this type of problem better
>> >> suited to something besides parallel streams? Maybe an ExecutorService?
>> >>
>> >> Really, all I am doing is taking a jumbo file, splitting it into
>> batches,
>> >> and then doing some work on those batches. My IO speeds are pretty
>> fast,
>> >> and the compute work is non-trivial, so there is performance being
>> left on
>> >> the table if I give up parallelism. And I am in a position where
>> completion
>> >> time is very important to us.
>> >>
>> >> I just naturally assumed parallel streams were the right choice because
>> >> the compute work is simple. A pure function that I can break out, and
>> then
>> >> call in a map. Once I do that, I just call forEach to write the batches
>> >> back out to S3. Maybe I should look into a different part of the std
>> lib
>> >> instead because I am using the wrong tool for the job? My nose says
>> >> ExecutorService, but I figure I should ask before I dive too deep in.
>> >>
>> >>
>> >> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
>> >> wrote:
>> >>
>> >> You're most welcome!
>> >>
>> >> In a potential future where all intermediate operations are
>> >> Gatherer-based, and all terminal operations are Collector-based, it
>> would
>> >> just work as expected. But with that said, I'm not sure it is
>> practically
>> >> achievable because some operations might not have the same
>> >> performance-characteristics as before.
>> >>
>> >> Cheers,
>> >> ?
>> >>
>> >>
>> >> *Viktor Klang*
>> >> Software Architect, Java Platform Group
>> >> Oracle
>> >> ------------------------------
>> >> *From:* David Alayachew <davidalayachew at gmail.com>
>> >> *Sent:* Monday, 11 November 2024 18:32
>> >> *To:* Viktor Klang <viktor.klang at oracle.com>
>> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
>> >> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> >> fetching too many elements
>> >>
>> >>
>> >> Thanks for the workaround. It's running beautifully.
>> >>
>> >> Is there a future where this island concept is extended to the rest of
>> >> streams? Tbh, I don't fully understand it.
>> >>
>> >> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
>> >> wrote:
>> >>
>> >> Hi David,
>> >>
>> >> This is the effect of how parallel streams are implemented, where
>> >> different stages, which are not representible as a join-less
>> Spliterator
>> >> are executed as a series of "islands" where the next isn't started
>> until
>> >> the former has completed.
>> >>
>> >> If you think about it, parallelization of a Stream works best when the
>> >> entire data set can be split amongst a set of worker threads, and that
>> sort
>> >> of implies that you want eager pre-fetch of data, so if your dataset
>> does
>> >> not fit in memory, that is likely to lead to less desirable outcomes.
>> >>
>> >> What I was able to do for Gatherers is to implement "gather(?) +
>> >> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> >> immediately followed by a collect(?) is run in the same "island".
>> >>
>> >> So with that said, you could try something like the following:
>> >>
>> >> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T>
>> *each*) {
>> >>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e),
>> (*l*,
>> >> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> >> }
>> >>
>> >>
>> >> stream
>> >> .parallel()
>> >> .unordered()
>> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> >> .collect(forEach(eachList -> println(eachList.getFirst())));
>> >>
>> >>
>> >> Cheers,
>> >> ?
>> >>
>> >>
>> >> *Viktor Klang*
>> >> Software Architect, Java Platform Group
>> >> Oracle
>> >> ------------------------------
>> >> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
>> David
>> >> Alayachew <davidalayachew at gmail.com>
>> >> *Sent:* Monday, 11 November 2024 14:52
>> >> *To:* core-libs-dev <core-libs-dev at openjdk.org>
>> >> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> >> elements
>> >>
>> >> And just to avoid the obvious question, I can hold about 30 batches in
>> >> memory before the Out of Memory error occurs. So this is not an issue
>> of my
>> >> batch size being too high.
>> >>
>> >> But just to confirm, I set the batch size to 1, and it still ran into
>> an
>> >> out of memory error. So I feel fairly confident saying that the
>> Gatherer is
>> >> trying to grab all available data before sending any of it downstream.
>> >>
>> >> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <
>> davidalayachew at gmail.com>
>> >> wrote:
>> >>
>> >> Hello Core Libs Dev Team,
>> >>
>> >> I was trying out Gatherers for a project at work, and ran into a rather
>> >> sad scenario.
>> >>
>> >> I need to process a large file in batches. Each batch is small enough
>> that
>> >> I can hold it in memory, but I cannot hold the entire file (and thus,
>> all
>> >> of the batches) in memory at once.
>> >>
>> >> Looking at the Gatherers API, I saw windowFixed and thought that it
>> would
>> >> be a great match for my use case.
>> >>
>> >> However, when trying it out, I was disappointed to see that it ran out
>> of
>> >> memory very quickly. Here is my attempt at using it.
>> >>
>> >> stream
>> >> .parallel()
>> >> .unordered()
>> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> >> .forEach(eachList -> println(eachList.getFirst()))
>> >> ;
>> >>
>> >> As you can see, I am just splitting the file into batches, and printing
>> >> out the first of each batch. This is purely for example's sake, of
>> course.
>> >> I had planned on building even more functionality on top of this, but I
>> >> couldn't even get past this example.
>> >>
>> >> But anyways, not even a single one of them printed out. Which leads me
>> to
>> >> believe that it's pulling all of them in the Gatherer.
>> >>
>> >> I can get it to run successfully if I go sequentially, but not
>> parallel.
>> >> Parallel gives me that out of memory error.
>> >>
>> >> Is there any way for me to be able to have the Gatherer NOT pull in
>> >> everything while still remaining parallel and unordered?
>> >>
>> >> Thank you for your time and help.
>> >> David Alayachew
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241119/752fb3f9/attachment-0001.htm>

From shade at openjdk.org  Tue Nov 19 08:09:40 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Nov 2024 08:09:40 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v10]
In-Reply-To: <YJbWdEKTS6y489KhGS9G-ORDSbQjahR93KNb4kedNv0=.8fd500fe-d6e8-4e2a-bbd4-455562757fd2@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <8rPgnekVBsEDOF2nV_AgHmvGPlJKiKte9Eis6VxDOBU=.fe4d09c2-8017-4607-ba98-547a1b853dec@github.com>
 <YJbWdEKTS6y489KhGS9G-ORDSbQjahR93KNb4kedNv0=.8fd500fe-d6e8-4e2a-bbd4-455562757fd2@github.com>
Message-ID: <RzpWpsxer0hUIcjHsSIUUZXYFnP6AdLkyECVKyaW-IM=.60e96459-67cf-407a-8484-961d04087e8e@github.com>

On Sat, 16 Nov 2024 00:03:18 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   prev is not needed
>
> src/java.base/share/classes/jdk/internal/ref/CleanerImpl.java line 239:
> 
>> 237:         /**
>> 238:          * Head node. This is the only node with variable size.
>> 239:          * All nodes linked from the head are always at full capacity.
> 
> Also, "This is the only node where PhantomCleanables are added" ?

Done, massaged it a bit further.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1847851599

From shade at openjdk.org  Tue Nov 19 08:09:38 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Nov 2024 08:09:38 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v12]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:

 - Touchups
 - Merge branch 'master' into JDK-8343704-cleaner-gc
 - Drop --add-exports from the test
 - prev is not needed
 - Do not need -ea -esa in tests, our testing infra adds them already
 - Add the node cache
 - Avoid NPE on empty list, add tests, touchups
 - Reimplement with segmented linked list of arrays
 - Review feedback: make sure trimming actually works, stylistic changes
 - Merge branch 'master' into JDK-8343704-cleaner-gc
 - ... and 3 more: https://git.openjdk.org/jdk/compare/64337bbf...dc55597d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/de1a1b70..dc55597d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=11
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=10-11

  Stats: 79748 lines in 1142 files changed: 38479 ins; 35650 del; 5619 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Tue Nov 19 08:09:42 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Nov 2024 08:09:42 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v11]
In-Reply-To: <Z2ZULt-MrJnxmK9XUChd9f6DPB7VPCh774ZyovFsEf0=.ad8c3454-a40f-4583-9eea-508e7261e570@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <yTGlChV6gSyRFN_7Vm2FNVWGcomGXSv5r7_vnPOqzM0=.c966918e-d540-4329-a492-c4713080f172@github.com>
 <Z2ZULt-MrJnxmK9XUChd9f6DPB7VPCh774ZyovFsEf0=.ad8c3454-a40f-4583-9eea-508e7261e570@github.com>
Message-ID: <AUReYRe_9qcLxkpQ_MhZIfpEaZ1XFQ95TYGix33v8Vg=.2565b48d-11be-4f1e-8699-7492cfb0e578@github.com>

On Tue, 19 Nov 2024 00:58:18 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Drop --add-exports from the test
>
> test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 46:
> 
>> 44: public class CleanableListTest {
>> 45: 
>> 46:     static final int SINGLE_NODE_CAPACITY = CleanableListTestHelper.NODE_CAPACITY - 1;
> 
> If `CleanableListTestHelper` uses a list without the `CleanerCleanable`, shouldn't we be able to test the full `NODE_CAPACITY` ?

Done.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1847851778

From jlahoda at openjdk.org  Tue Nov 19 08:48:57 2024
From: jlahoda at openjdk.org (Jan Lahoda)
Date: Tue, 19 Nov 2024 08:48:57 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v9]
In-Reply-To: <GIwmq9CSUqLL1tOHEJcYkAS99mVf-u3ZCZGSsva3DxY=.b1a91fab-28f9-4dfe-b1dc-06a99c3743ba@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>
 <GIwmq9CSUqLL1tOHEJcYkAS99mVf-u3ZCZGSsva3DxY=.b1a91fab-28f9-4dfe-b1dc-06a99c3743ba@github.com>
Message-ID: <tG7HhQTCUoDxkIsCej7NEEFODOboanZUe8B8-BplRkQ=.20a7e9f7-a386-4ff3-ad79-8493778fd325@github.com>

On Mon, 18 Nov 2024 21:05:41 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

> I think it makes sense to include the version. I have no strong opinions on the format. Is the extract in the PR description updated with the latest version changes?

Yes, the description is updated with the output, and I've also added the full `java -help` output.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21411#issuecomment-2485055240

From jpai at openjdk.org  Tue Nov 19 09:08:58 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 09:08:58 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v7]
In-Reply-To: <xF1reLD_7FI3-zeEKrYPzUM9gm5BcV8VeyTLddyPdnU=.1c9af84a-3b8e-4727-9bc7-5e53c9aec7f3@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <gAxhAQJRPMcCbJvVHVcbYWvVos1BSuqbd3IWhKGiAqI=.380b0d6b-eb80-4b6d-86a9-68dcc5a6696e@github.com>
 <vuzTesVqSBmTN3Vlx4fwBFLrCsVUd3CXESzvJ70T3QA=.8609d69e-70fa-4ab7-8bba-446f1615f7e3@github.com>
 <_wL5ioaJSVkua-Tt7hgek_mgkW3ZQYYqITkCLJunUaM=.9ebf630c-6d5b-408f-9c9c-7cb22fff1818@github.com>
 <X3eBPJicNF2jf_bWT-H2vJIG7LO9dFQtjq8KyB_Uqms=.3ceffefd-2e6f-4add-a776-595c08d04fd6@github.com>
 <5WLImJZVliyCfPwtyv65k7gGHlMrw2D85MjTvY2erKQ=.f7b61835-fe85-4d7a-8362-405ef09209fd@github.com>
 <xF1reLD_7FI3-zeEKrYPzUM9gm5BcV8VeyTLddyPdnU=.1c9af84a-3b8e-4727-9bc7-5e53c9aec7f3@github.com>
Message-ID: <WPRiqN1uQ63lBOVmIxZ2CCprFUp-gDoohYSGUl3mN8U=.c61c2fc7-2ab1-4f82-bfe0-3349b457d8d4@github.com>

On Tue, 12 Nov 2024 15:30:23 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> `shortVersionString` changed to `conciseVersionString` in:
>> https://github.com/openjdk/jdk/pull/21411/commits/e9e9ad4bdd0a11244cb1ef84fdeea036e94718c7
>
>> The idea behind printing the short version is to identify what tool is speaking. It can be removed, if desired.
> 
> It may be helpful to some but may be confusing in other cases, esp. because it may include "LTS" in the output. So I think maybe drop this for now, or get wider input on print the version string as the first line, it can always be added later if needed.

I hadn't paid attention to the version string in the output for `java` (without args). I agree with Alan that it might be better to remove that from the output so that it matches with `java -help` which doesn't print it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21411#discussion_r1847941376

From rgiulietti at openjdk.org  Tue Nov 19 09:23:58 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Nov 2024 09:23:58 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v17]
In-Reply-To: <wrIrBVSNEeOc4aMpWPmb_Z8whdxn40geeFn_JUhrl5g=.e2d75a9c-12a9-4409-bdd1-2badb392bdff@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <KW-U-91MyntIMaUwjtxY0h21c3ZiDU0MvBZHGHplZe0=.65fcb40d-7f42-4278-acfa-a84377c81757@github.com>
 <zd-vraoffPK17e27kdpujyHNmPP4NFKRcJrzV7nUj9U=.952beef0-84ed-4176-a160-01b631f5a277@github.com>
 <wrIrBVSNEeOc4aMpWPmb_Z8whdxn40geeFn_JUhrl5g=.e2d75a9c-12a9-4409-bdd1-2badb392bdff@github.com>
Message-ID: <rYiFVw3VNx2ZxCLCD6q9xE0R8ZQMyf8KU9legnXaC-g=.d77ab481-09b0-4b77-8642-b5dbbf7f73d5@github.com>

On Mon, 18 Nov 2024 14:21:29 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 2248:
>> 
>>> 2246:                             }
>>> 2247:                         }
>>> 2248:                     } else { // mc.roundingMode == RoundingMode.UP || mc.roundingMode == RoundingMode.CEILING
>> 
>> It would be more robust to make all enum constant explicit, and reserve the `else` to throw a `RuntimeException` of some sort, e.g., `MatchException`. Should an additional enum constant be added to `RoundingMode` in the future, this code will then throw instead of silently producing a wrong result.
>> 
>> If possible at all, it would be preferable to use a `switch` rather than `if`s.
>
> Also, please merge master into this.

While you are at it, it would be useful to add one test for each of the paths in the new algorithm (including the exception cases) in the existing [SquareRootTests](https://github.com/openjdk/jdk/blob/master/test/jdk/java/math/BigDecimal/SquareRootTests.java) This helps to identify future regressions when the code is later modified for any reason.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1847964055

From asotona at openjdk.org  Tue Nov 19 09:42:48 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 19 Nov 2024 09:42:48 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v3]
In-Reply-To: <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
Message-ID: <a-AwMSzRkwTtZKSs8JspUoj5jfVH2OzgZXTE2VP22Z0=.6c43801d-d04e-4a1f-8cf8-c0ad6b1f08a0@github.com>

On Mon, 18 Nov 2024 02:58:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Further facelift
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Typos, long lines
>  - Labels
>  - Wip instr

src/java.base/share/classes/java/lang/classfile/instruction/CharacterRange.java line 62:

> 60:  * <p>
> 61:  * Physically, a character range has the same structure; it is modeled by a
> 62:  * {@link CharacterRangeInfo}.

I'm not sure how to explain "Physically" and "it is modeled by".
If "Physically" means specific byte serialization, then it is an entry in a CRT attribute with BCIs instead of labels.

"it is modeled by a CharacterRangeInfo" seems to me very confusing as this class (CharacterRange) is the primary model class. 

Maybe we should explain the duplicity of some classfile structures accessible as attributes internal raw structures (CharacterRangeInfo) versus preferred primary models as labeled pseudo instructions (CharacterRange).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1847995378

From asotona at openjdk.org  Tue Nov 19 09:48:58 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 19 Nov 2024 09:48:58 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v3]
In-Reply-To: <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
Message-ID: <OvpEyOPTAytkuWpvfp6hmjNVIC1ZsibDkHFuaARpP7I=.4e0e655d-bfb1-43fb-b42e-a0b06b148f68@github.com>

On Mon, 18 Nov 2024 02:58:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Further facelift
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Typos, long lines
>  - Labels
>  - Wip instr

src/java.base/share/classes/java/lang/classfile/instruction/ConstantInstruction.java line 58:

> 56:  * <p>
> 57:  * Physically, a constant-load instruction is polymorphic; nested interfaces in
> 58:  * this interface model different constant instructions as records.

I'm not sure what the sentence "nested interfaces in this interface model different constant instructions as records" gives to users and on the other side what obligation does it mean from the JCK perspective?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1848005273

From asotona at openjdk.org  Tue Nov 19 10:11:44 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Tue, 19 Nov 2024 10:11:44 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v3]
In-Reply-To: <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
Message-ID: <HbOTyM_cIuzZQ8awre_1pqAC7BRB5NmRrL0svyVrz2E=.3488927b-3695-4376-bde5-78c92140012c@github.com>

On Mon, 18 Nov 2024 02:58:31 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Further facelift
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>  - Typos, long lines
>  - Labels
>  - Wip instr

My personal feeling is that sentences like "Conceptually, Xy is a record..." and "Physically,  Xy is a record..." are more confusing than explaining. My understanding of "Conceptually" is that the particular sealed interface xyInstruction represents the model concept. My understanding of "Physically" is that the particular chapter 6. paragraph of the JVMS describes the mechanics. And I don't see there any records (in particular Java meaning) .

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21625#issuecomment-2485248411

From jpai at openjdk.org  Tue Nov 19 10:44:15 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 10:44:15 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration
Message-ID: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>

Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.

The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.

I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.

No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

-------------

Commit messages:
 - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

Changes: https://git.openjdk.org/jdk/pull/22233/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22233&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344223
  Stats: 423 lines in 3 files changed: 26 ins; 311 del; 86 mod
  Patch: https://git.openjdk.org/jdk/pull/22233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22233/head:pull/22233

PR: https://git.openjdk.org/jdk/pull/22233

From jpai at openjdk.org  Tue Nov 19 10:48:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 10:48:25 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v2]
In-Reply-To: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
Message-ID: <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>

> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
> 
> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
> 
> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:

 - merge latest from master branch
 - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22233/files
  - new: https://git.openjdk.org/jdk/pull/22233/files/d4dff489..5a82b729

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22233&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22233&range=00-01

  Stats: 964 lines in 29 files changed: 466 ins; 419 del; 79 mod
  Patch: https://git.openjdk.org/jdk/pull/22233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22233/head:pull/22233

PR: https://git.openjdk.org/jdk/pull/22233

From eirbjo at openjdk.org  Tue Nov 19 10:54:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 10:54:03 GMT
Subject: RFR: 8344534: Remove leftover import of
 java.security.AccessControlContext in JavaLangAccess
Message-ID: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>

Please review this trivial cleanup of an unused import of `AccessControlContext ` in `JavaLangAccess`. 

This was left over after #22035 removed `JavaLangAccess::newThreadWithAcc(Runnable, AccessControlContext)`.

Verification: `make images` succeeds.

-------------

Commit messages:
 - Remove leftover import of JavaLangAccess

Changes: https://git.openjdk.org/jdk/pull/22234/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22234&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344534
  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22234.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22234/head:pull/22234

PR: https://git.openjdk.org/jdk/pull/22234

From eirbjo at openjdk.org  Tue Nov 19 10:54:03 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 10:54:03 GMT
Subject: RFR: 8344534: Remove leftover import of
 java.security.AccessControlContext in JavaLangAccess
In-Reply-To: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>
References: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>
Message-ID: <ZmLIw18LnYbQGtWmLX8hyC9sftIFdo3IM-W72swX8Tc=.14ea01b5-ad7c-4968-a8d9-523ac735bbc0@github.com>

On Tue, 19 Nov 2024 10:48:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this trivial cleanup of an unused import of `AccessControlContext ` in `JavaLangAccess`. 
> 
> This was left over after #22035 removed `JavaLangAccess::newThreadWithAcc(Runnable, AccessControlContext)`.
> 
> Verification: `make images` succeeds.

Channeling @AlanBateman to have a look.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22234#issuecomment-2485349252

From cstein at openjdk.org  Tue Nov 19 11:19:53 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 19 Nov 2024 11:19:53 GMT
Subject: RFR: 8293040: Argfile documentation for java launcher tool is
 confusing regarding usage of wildcards
In-Reply-To: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
References: <oLnfFtFviq5d__q4AFF7AOz2nSC2KJip1qegHM0LXi8=.840fca76-fadf-46ab-8d7b-5bdd87e784fb@github.com>
Message-ID: <I9yEMwgXbncm3g214tUEw_JrmMliHGhcx7iGkYrCe14=.147619e8-e1d2-47e2-a4fb-045e81465924@github.com>

On Mon, 18 Nov 2024 15:22:59 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this improvement to the manual page covering the usage of wildcards in `java`'s argfiles.

> [...] I think this sentence can be removed altogether, given that this semantic is already explained a few sentences above by the change in this PR.

Filed https://github.com/openjdk/jdk/pull/22236 to removed the sentence.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22208#issuecomment-2485431601

From eirbjo at openjdk.org  Tue Nov 19 11:24:46 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 11:24:46 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v2]
In-Reply-To: <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
Message-ID: <FHcLuF3iuCDE3XCTftREqS7uf30Lgr39wB2h_IWa2Ps=.68862a14-dad8-42d0-aedb-222f53b222d1@github.com>

On Tue, 19 Nov 2024 10:48:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>> 
>> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
>> 
>> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
>> 
>> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - merge latest from master branch
>  - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 387:

> 385:         Enumeration<URL> e = findResourcesOnClassPath(name);
> 386: 
> 387:         // concat the resources from the modules and the class path

Observation: This is now essentially `ClassLoader.CompoundEnumeration`, which could be reused if moved to `jdk.internal.loader`. Probably not for this PR though.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22233#discussion_r1848165627

From alanb at openjdk.org  Tue Nov 19 11:39:44 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 11:39:44 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v2]
In-Reply-To: <FHcLuF3iuCDE3XCTftREqS7uf30Lgr39wB2h_IWa2Ps=.68862a14-dad8-42d0-aedb-222f53b222d1@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
 <FHcLuF3iuCDE3XCTftREqS7uf30Lgr39wB2h_IWa2Ps=.68862a14-dad8-42d0-aedb-222f53b222d1@github.com>
Message-ID: <mtju6mXlaphTNQGK-QhX436Is1CDqWaQ3ZvGY-ezWb4=.d1087e25-c7ce-482c-9fbf-01a4e32dd4a5@github.com>

On Tue, 19 Nov 2024 11:21:38 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
>> 
>>  - merge latest from master branch
>>  - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration
>
> src/java.base/share/classes/jdk/internal/loader/BuiltinClassLoader.java line 387:
> 
>> 385:         Enumeration<URL> e = findResourcesOnClassPath(name);
>> 386: 
>> 387:         // concat the resources from the modules and the class path
> 
> Observation: This is now essentially `ClassLoader.CompoundEnumeration`, which could be reused if moved to `jdk.internal.loader`. Probably not for this PR though.

The new comment isn't quite right, it should say "concat the URLs to the resource in the modules and the class path".

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22233#discussion_r1848178162

From alanb at openjdk.org  Tue Nov 19 11:43:43 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 11:43:43 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v2]
In-Reply-To: <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
Message-ID: <jOjRbH1aBocBV6XFeHfbmxzutmu0YzT6SMczIPjaSp4=.d5b1dc2a-d73a-489c-9428-d1f08aec4e45@github.com>

On Tue, 19 Nov 2024 10:48:25 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>> 
>> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
>> 
>> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
>> 
>> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains two additional commits since the last revision:
> 
>  - merge latest from master branch
>  - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

I did a pass over this, good cleanup.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22233#pullrequestreview-2445192516

From alanb at openjdk.org  Tue Nov 19 11:57:52 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 11:57:52 GMT
Subject: RFR: 8344534: Remove leftover import of
 java.security.AccessControlContext in JavaLangAccess
In-Reply-To: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>
References: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>
Message-ID: <L6BVzaXLKysoQBGDBBkCdVESBDqCDmlFeXWJWAs2EY4=.263aca31-a6ba-49ea-bb11-0fef1757925d@github.com>

On Tue, 19 Nov 2024 10:48:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this trivial cleanup of an unused import of `AccessControlContext ` in `JavaLangAccess`. 
> 
> This was left over after #22035 removed `JavaLangAccess::newThreadWithAcc(Runnable, AccessControlContext)`.
> 
> Verification: `make images` succeeds.

Okay but hardly worth doing as JLA is changed very frequently so any unused imports will be quickly removed.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22234#pullrequestreview-2445236624

From cstein at openjdk.org  Tue Nov 19 12:05:53 2024
From: cstein at openjdk.org (Christian Stein)
Date: Tue, 19 Nov 2024 12:05:53 GMT
Subject: RFR: 8344540: Remove superseded wildcard description from java manpage
Message-ID: <IX-jo6P0nLWkVZJrUcDwyuo3T8VVmRYoG0C-hkM439k=.c6e06daa-7aed-4c56-a92e-43642147e9b6@github.com>

Please review this follow-up PR to improve `java`'s manpage section about wildcards in argument files: the confusing sentence is now removed.

This is a cleanup of commit https://github.com/openjdk/jdk/commit/5cb0d438231383d491b2fcca455d09af7f2ee016

-------------

Commit messages:
 - 8344540: Remove superseded wildcard description from java manpage

Changes: https://git.openjdk.org/jdk/pull/22236/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22236&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344540
  Stats: 2 lines in 1 file changed: 0 ins; 2 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22236.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22236/head:pull/22236

PR: https://git.openjdk.org/jdk/pull/22236

From eirbjo at openjdk.org  Tue Nov 19 12:06:52 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 12:06:52 GMT
Subject: RFR: 8344534: Remove leftover import of
 java.security.AccessControlContext in JavaLangAccess
In-Reply-To: <L6BVzaXLKysoQBGDBBkCdVESBDqCDmlFeXWJWAs2EY4=.263aca31-a6ba-49ea-bb11-0fef1757925d@github.com>
References: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>
 <L6BVzaXLKysoQBGDBBkCdVESBDqCDmlFeXWJWAs2EY4=.263aca31-a6ba-49ea-bb11-0fef1757925d@github.com>
Message-ID: <WnOlSi_aKXPacseE4iLirXH1-SY-gpkqSsFQijDYmBg=.e0b30723-53b3-49e0-a52f-6aab55bac38d@github.com>

On Tue, 19 Nov 2024 11:54:41 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Okay but hardly worth doing as JLA is changed very frequently so any unused imports will be quickly removed.

Thanks Alan. I'll go ahead and integrate this now, but I'm taking note of your point for any future changes in similar contexts.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22234#issuecomment-2485531214

From eirbjo at openjdk.org  Tue Nov 19 12:06:53 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 12:06:53 GMT
Subject: Integrated: 8344534: Remove leftover import of
 java.security.AccessControlContext in JavaLangAccess
In-Reply-To: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>
References: <6JOEtHaNVeFOZB9Aucu4DQ3iyIcXau27zNpr6syegVg=.ddcfc720-2273-4ee6-a1b7-22b15a9b8a77@github.com>
Message-ID: <vk5kulaIJm7dZ19mPG6ShbTL0kydW754IG5TMMVQxEU=.e41a2356-dbb7-42c6-a181-b8e18cd433f9@github.com>

On Tue, 19 Nov 2024 10:48:37 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this trivial cleanup of an unused import of `AccessControlContext ` in `JavaLangAccess`. 
> 
> This was left over after #22035 removed `JavaLangAccess::newThreadWithAcc(Runnable, AccessControlContext)`.
> 
> Verification: `make images` succeeds.

This pull request has now been integrated.

Changeset: 23597361
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/235973615fbad7073df67167ab1cb4d40b6f1ab5
Stats:     1 line in 1 file changed: 0 ins; 1 del; 0 mod

8344534: Remove leftover import of java.security.AccessControlContext in JavaLangAccess

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22234

From viktor.klang at oracle.com  Tue Nov 19 12:19:02 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 19 Nov 2024 12:19:02 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
 <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
Message-ID: <MW4PR10MB577405D464DA1241736F8AF6FF202@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David,

I've been thinking about this topic for a few days and haven't arrived at a satisfactory solution. Keep in mind that this "situation" has been in place ever since Streams were released, and perhaps Gatherers may be a catalyst to have it be more noticeable?I'll keep thinking about what could be done to make it more predictable (besides thinking about what rearrangements might make the situation go away).

In general though?short-circuiting in combination with parallelization requires a lot of tuning to make sure that the cost of processing more data doesn't overtake the benefit of "exiting early".


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Thursday, 14 November 2024 23:45
To: Viktor Klang <viktor.klang at oracle.com>
Cc: Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Oh ok. So it truly is a toss-up depending on each implementation when and where this occurs.

Ok, then as my final request, I think even informing the user that this CAN occur is worth doing. If nothing else, the user scouring the documentation for documentation of this behaviour will know that it is simply something that can occur. They don't need to know all the details. Simply give it a official term, describe the behaviour, tell that it is implementation specific on when this happens, but that it is only possible during parallelism. Even just knowing the verbiage to describe the problem will enable them to better communicate with each other on what they want vs what they get. That helps searchability, if nothing else.

On Thu, Nov 14, 2024, 8:45?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
I see what you're saying, the problem is that it depends on the Stream implementation (given that Stream is an interface).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Thursday, 14 November 2024 12:36
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>; core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Then let me correct myself again, while simplifying -- I just want that detail, that certain combinations might lead to pre-fetching everything, to be documented on the stream api. Package level, or on the Stream interface itself, seems like a good spot.

On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
The issue here is that the operation cannot advertise this, as it depends on the combination of operations.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Wednesday, 13 November 2024 14:07
To: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

That is a good point Rob.

Then let me correct myself -- I think the terminal operations don't do a great job of advertising whether or not they pre-fetch everything when parallelism is activated. Collector fetches as needed. FindAny pre-fetches everything. I understand that later releases might change their behaviour, but I still want to document the current behaviour in the official javadocs so that we can limit undocumented tripping hazards.


On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>> wrote:
distinct() doesn't require everything to be pulled. It can push elements
to the downstream as they come along for the first time. When
downstream.push returns false the gatherer is done.

As part of some experimentation I've implemented all intermediary
operations using gatherers. Most of them are pretty straightforward and
will stop integrating once the downstream starts rejecting elements
(although some use Gatherer.ofSequential to keep it easy). I only found
two exceptions that don't return the result of downstream.push:

* mapMulti. The downstream.push is passed as the mapper which is a
Consumer - the return value is ignored. With some more effort it's
probably possible to capture any false return value and return that from
the integrator, but I haven't tried that yet.

* sorted. Obviously every element needs to be inspected.


On 13/11/2024 00:37, David Alayachew wrote:
> Oh sure, I expect something like distinct() to pull everything. In order to
> know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
>
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
>
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
>
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
>
>
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>
>>> We are told how Streams can process unbounded data sets, but when it
>> tries to do a findAny() with parallel(), it runs into an OOME because it
>> fetched all the data ahead of time. In fact, almost of the terminal
>> operations will hit an OOME in the exact same way if they are parallel and
>> have a big enough data set. It's definitely not the end of the world, but
>> it seems that I have to fit everything into a Collector and/or a Gatherer
>> if I want to avoid pre-fetching everything.
>>
>> Yeah, I think it is important to distinguish "can process unbounded data
>> sets" from "always able to process unbounded data sets".
>>
>> Some operations inherently need the end of the stream, so even something
>> somple like: stream.distinct() or stream.sorted() can end up pulling in all
>> data (which of course won't terminate).
>>
>> Fortunately, I think Gatherers can unlock much more situations where
>> unbounded streams can be processed.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 15:08
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
>> as I thought of it.
>>
>>
>> I hand-waved away the idea because I thought that the method would turn
>> the stream pipeline parallel, thus, recreating the same problem I currently
>> have of parallelism causing all of the elements to be fetched ahead of
>> time, causing an OOME.
>>
>>
>> It did NOT occur to me that the pipeline would stay sequential, and just
>> kick these off sequentially, but have them executing in parallel. I can't
>> see why I came to that incorrect conclusion. I have read the javadocs of
>> this method several times. Though, to be fair, I came to the same,
>> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
>> until someone pointed out what the documentation was actually saying that I
>> realized it's true properties.
>>
>> Thanks. That definitely solves at least part of my problem. Obviously, I
>> would prefer to write to S3 in parallel too, but at the very least, the
>> calculation part is being done in parallel. And worst case scenario, I can
>> be really bad and just do the write to S3 in the mapConcurrent, and then
>> just return the metadata of each write, and just bundle that up with
>> collect.
>>
>>
>> And that's ignoring the fact that I can just use the workaround too.
>>
>>
>> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
>> from a performance perspective, but is rather unintuitive to me from a
>> usability perspective. We are told how Streams can process unbounded data
>> sets, but when it tries to do a findAny() with parallel(), it runs into an
>> OOME because it fetched all the data ahead of time. In fact, almost of the
>> terminal operations will hit an OOME in the exact same way if they are
>> parallel and have a big enough data set. It's definitely not the end of the
>> world, but it seems that I have to fit everything into a Collector and/or a
>> Gatherer if I want to avoid pre-fetching everything.
>>
>> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Have you considered Gatherers.mapConcurrent(?)?
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 01:53
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> Good to know, ty vm.
>>
>> At the very least, I have this workaround. This will meet my needs for now.
>>
>> I guess my final question would be -- is this type of problem better
>> suited to something besides parallel streams? Maybe an ExecutorService?
>>
>> Really, all I am doing is taking a jumbo file, splitting it into batches,
>> and then doing some work on those batches. My IO speeds are pretty fast,
>> and the compute work is non-trivial, so there is performance being left on
>> the table if I give up parallelism. And I am in a position where completion
>> time is very important to us.
>>
>> I just naturally assumed parallel streams were the right choice because
>> the compute work is simple. A pure function that I can break out, and then
>> call in a map. Once I do that, I just call forEach to write the batches
>> back out to S3. Maybe I should look into a different part of the std lib
>> instead because I am using the wrong tool for the job? My nose says
>> ExecutorService, but I figure I should ask before I dive too deep in.
>>
>>
>> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> You're most welcome!
>>
>> In a potential future where all intermediate operations are
>> Gatherer-based, and all terminal operations are Collector-based, it would
>> just work as expected. But with that said, I'm not sure it is practically
>> achievable because some operations might not have the same
>> performance-characteristics as before.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 18:32
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Thanks for the workaround. It's running beautifully.
>>
>> Is there a future where this island concept is extended to the rest of
>> streams? Tbh, I don't fully understand it.
>>
>> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Hi David,
>>
>> This is the effect of how parallel streams are implemented, where
>> different stages, which are not representible as a join-less Spliterator
>> are executed as a series of "islands" where the next isn't started until
>> the former has completed.
>>
>> If you think about it, parallelization of a Stream works best when the
>> entire data set can be split amongst a set of worker threads, and that sort
>> of implies that you want eager pre-fetch of data, so if your dataset does
>> not fit in memory, that is likely to lead to less desirable outcomes.
>>
>> What I was able to do for Gatherers is to implement "gather(?) +
>> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> immediately followed by a collect(?) is run in the same "island".
>>
>> So with that said, you could try something like the following:
>>
>> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
>> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> }
>>
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .collect(forEach(eachList -> println(eachList.getFirst())));
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David
>> Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 14:52
>> *To:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> elements
>>
>> And just to avoid the obvious question, I can hold about 30 batches in
>> memory before the Out of Memory error occurs. So this is not an issue of my
>> batch size being too high.
>>
>> But just to confirm, I set the batch size to 1, and it still ran into an
>> out of memory error. So I feel fairly confident saying that the Gatherer is
>> trying to grab all available data before sending any of it downstream.
>>
>> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> wrote:
>>
>> Hello Core Libs Dev Team,
>>
>> I was trying out Gatherers for a project at work, and ran into a rather
>> sad scenario.
>>
>> I need to process a large file in batches. Each batch is small enough that
>> I can hold it in memory, but I cannot hold the entire file (and thus, all
>> of the batches) in memory at once.
>>
>> Looking at the Gatherers API, I saw windowFixed and thought that it would
>> be a great match for my use case.
>>
>> However, when trying it out, I was disappointed to see that it ran out of
>> memory very quickly. Here is my attempt at using it.
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .forEach(eachList -> println(eachList.getFirst()))
>> ;
>>
>> As you can see, I am just splitting the file into batches, and printing
>> out the first of each batch. This is purely for example's sake, of course.
>> I had planned on building even more functionality on top of this, but I
>> couldn't even get past this example.
>>
>> But anyways, not even a single one of them printed out. Which leads me to
>> believe that it's pulling all of them in the Gatherer.
>>
>> I can get it to run successfully if I go sequentially, but not parallel.
>> Parallel gives me that out of memory error.
>>
>> Is there any way for me to be able to have the Gatherer NOT pull in
>> everything while still remaining parallel and unordered?
>>
>> Thank you for your time and help.
>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241119/89a5109c/attachment-0001.htm>

From davidalayachew at gmail.com  Tue Nov 19 12:26:27 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Tue, 19 Nov 2024 07:26:27 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB577405D464DA1241736F8AF6FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
 <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
 <MW4PR10MB577405D464DA1241736F8AF6FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_OxN39TmA=aeXPmeyjvAeWxmjPCYr6V=+1xR9cHvjvbtw@mail.gmail.com>

Ty vm, I appreciate you digging into this.

On Tue, Nov 19, 2024, 7:19?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Hi David,
>
> I've been thinking about this topic for a few days and haven't arrived at
> a satisfactory solution. Keep in mind that this "situation" has been in
> place ever since Streams were released, and perhaps Gatherers may be a
> catalyst to have it be more noticeable?I'll keep thinking about what could
> be done to make it more predictable (besides thinking about what
> rearrangements might make the situation go away).
>
> In general though?short-circuiting in combination with parallelization
> requires a lot of tuning to make sure that the cost of processing more data
> doesn't overtake the benefit of "exiting early".
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Thursday, 14 November 2024 23:45
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> Oh ok. So it truly is a toss-up depending on each implementation when and
> where this occurs.
>
> Ok, then as my final request, I think even informing the user that this
> CAN occur is worth doing. If nothing else, the user scouring the
> documentation for documentation of this behaviour will know that it is
> simply something that can occur. They don't need to know all the details.
> Simply give it a official term, describe the behaviour, tell that it is
> implementation specific on when this happens, but that it is only possible
> during parallelism. Even just knowing the verbiage to describe the problem
> will enable them to better communicate with each other on what they want vs
> what they get. That helps searchability, if nothing else.
>
> On Thu, Nov 14, 2024, 8:45?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> I see what you're saying, the problem is that it depends on the Stream
> implementation (given that Stream is an interface).
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Thursday, 14 November 2024 12:36
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Then let me correct myself again, while simplifying -- I just want that
> detail, that certain combinations might lead to pre-fetching everything, to
> be documented on the stream api. Package level, or on the Stream interface
> itself, seems like a good spot.
>
> On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> The issue here is that the operation cannot advertise this, as it depends
> on the combination of operations.
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Wednesday, 13 November 2024 14:07
> *To:* Rob Spoor <openjdk at icemanx.nl>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> That is a good point Rob.
>
> Then let me correct myself -- I think the terminal operations don't do a
> great job of advertising whether or not they pre-fetch everything when
> parallelism is activated. Collector fetches as needed. FindAny pre-fetches
> everything. I understand that later releases might change their behaviour,
> but I still want to document the current behaviour in the official javadocs
> so that we can limit undocumented tripping hazards.
>
>
> On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl> wrote:
>
> distinct() doesn't require everything to be pulled. It can push elements
> to the downstream as they come along for the first time. When
> downstream.push returns false the gatherer is done.
>
> As part of some experimentation I've implemented all intermediary
> operations using gatherers. Most of them are pretty straightforward and
> will stop integrating once the downstream starts rejecting elements
> (although some use Gatherer.ofSequential to keep it easy). I only found
> two exceptions that don't return the result of downstream.push:
>
> * mapMulti. The downstream.push is passed as the mapper which is a
> Consumer - the return value is ignored. With some more effort it's
> probably possible to capture any false return value and return that from
> the integrator, but I haven't tried that yet.
>
> * sorted. Obviously every element needs to be inspected.
>
>
> On 13/11/2024 00:37, David Alayachew wrote:
> > Oh sure, I expect something like distinct() to pull everything. In order
> to
> > know if something is distinct, you have to do some variant of "check
> > against everyone else". Whether that is holding all instances in memory
> or
> > their hashes, it's clear from a glance that you will need to look at
> > everything, and therefore, pre-fetching makes intuitive sense to me.
> >
> > I 100% did not expect terminal operations like findAny() or reduce() to
> > pull the whole data set. That was a complete whiplash for me. The method
> > findAny() advertises itself as a short-circuiting operation, so to find
> out
> > that it actually pulls the whole data set anyways was shocking.
> >
> > And that was my biggest pain point -- looking at the documentation, it is
> > not clear to me at all that methods like findAny() would pull in all data
> > upon becoming parallel().
> >
> > Do you think it would make sense to add documentation about this to the
> > javadocs for Stream/java.util.stream? Or maybe it is already there and I
> > misunderstood it (even after reading through it thoroughly over 5 times).
> >
> >
> > On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
> >
> >>> We are told how Streams can process unbounded data sets, but when it
> >> tries to do a findAny() with parallel(), it runs into an OOME because it
> >> fetched all the data ahead of time. In fact, almost of the terminal
> >> operations will hit an OOME in the exact same way if they are parallel
> and
> >> have a big enough data set. It's definitely not the end of the world,
> but
> >> it seems that I have to fit everything into a Collector and/or a
> Gatherer
> >> if I want to avoid pre-fetching everything.
> >>
> >> Yeah, I think it is important to distinguish "can process unbounded data
> >> sets" from "always able to process unbounded data sets".
> >>
> >> Some operations inherently need the end of the stream, so even something
> >> somple like: stream.distinct() or stream.sorted() can end up pulling in
> all
> >> data (which of course won't terminate).
> >>
> >> Fortunately, I think Gatherers can unlock much more situations where
> >> unbounded streams can be processed.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 15:08
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Oh woah. I certainly did not. Or rather, I had dismissed the idea as
> soon
> >> as I thought of it.
> >>
> >>
> >> I hand-waved away the idea because I thought that the method would turn
> >> the stream pipeline parallel, thus, recreating the same problem I
> currently
> >> have of parallelism causing all of the elements to be fetched ahead of
> >> time, causing an OOME.
> >>
> >>
> >> It did NOT occur to me that the pipeline would stay sequential, and just
> >> kick these off sequentially, but have them executing in parallel. I
> can't
> >> see why I came to that incorrect conclusion. I have read the javadocs of
> >> this method several times. Though, to be fair, I came to the same,
> >> incorrect conclusion about Collectors.groupingByConcurrent(), and it
> wasn't
> >> until someone pointed out what the documentation was actually saying
> that I
> >> realized it's true properties.
> >>
> >> Thanks. That definitely solves at least part of my problem. Obviously, I
> >> would prefer to write to S3 in parallel too, but at the very least, the
> >> calculation part is being done in parallel. And worst case scenario, I
> can
> >> be really bad and just do the write to S3 in the mapConcurrent, and then
> >> just return the metadata of each write, and just bundle that up with
> >> collect.
> >>
> >>
> >> And that's ignoring the fact that I can just use the workaround too.
> >>
> >>
> >> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
> >> from a performance perspective, but is rather unintuitive to me from a
> >> usability perspective. We are told how Streams can process unbounded
> data
> >> sets, but when it tries to do a findAny() with parallel(), it runs into
> an
> >> OOME because it fetched all the data ahead of time. In fact, almost of
> the
> >> terminal operations will hit an OOME in the exact same way if they are
> >> parallel and have a big enough data set. It's definitely not the end of
> the
> >> world, but it seems that I have to fit everything into a Collector
> and/or a
> >> Gatherer if I want to avoid pre-fetching everything.
> >>
> >> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Have you considered Gatherers.mapConcurrent(?)?
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 01:53
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >> Good to know, ty vm.
> >>
> >> At the very least, I have this workaround. This will meet my needs for
> now.
> >>
> >> I guess my final question would be -- is this type of problem better
> >> suited to something besides parallel streams? Maybe an ExecutorService?
> >>
> >> Really, all I am doing is taking a jumbo file, splitting it into
> batches,
> >> and then doing some work on those batches. My IO speeds are pretty fast,
> >> and the compute work is non-trivial, so there is performance being left
> on
> >> the table if I give up parallelism. And I am in a position where
> completion
> >> time is very important to us.
> >>
> >> I just naturally assumed parallel streams were the right choice because
> >> the compute work is simple. A pure function that I can break out, and
> then
> >> call in a map. Once I do that, I just call forEach to write the batches
> >> back out to S3. Maybe I should look into a different part of the std lib
> >> instead because I am using the wrong tool for the job? My nose says
> >> ExecutorService, but I figure I should ask before I dive too deep in.
> >>
> >>
> >> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> You're most welcome!
> >>
> >> In a potential future where all intermediate operations are
> >> Gatherer-based, and all terminal operations are Collector-based, it
> would
> >> just work as expected. But with that said, I'm not sure it is
> practically
> >> achievable because some operations might not have the same
> >> performance-characteristics as before.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 18:32
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Thanks for the workaround. It's running beautifully.
> >>
> >> Is there a future where this island concept is extended to the rest of
> >> streams? Tbh, I don't fully understand it.
> >>
> >> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Hi David,
> >>
> >> This is the effect of how parallel streams are implemented, where
> >> different stages, which are not representible as a join-less Spliterator
> >> are executed as a series of "islands" where the next isn't started until
> >> the former has completed.
> >>
> >> If you think about it, parallelization of a Stream works best when the
> >> entire data set can be split amongst a set of worker threads, and that
> sort
> >> of implies that you want eager pre-fetch of data, so if your dataset
> does
> >> not fit in memory, that is likely to lead to less desirable outcomes.
> >>
> >> What I was able to do for Gatherers is to implement "gather(?) +
> >> collect(?)"-fusion so any number of consecutive gather(?)-operations
> >> immediately followed by a collect(?) is run in the same "island".
> >>
> >> So with that said, you could try something like the following:
> >>
> >> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T>
> *each*) {
> >>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e),
> (*l*,
> >> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> >> }
> >>
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .collect(forEach(eachList -> println(eachList.getFirst())));
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> David
> >> Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 14:52
> >> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> >> elements
> >>
> >> And just to avoid the obvious question, I can hold about 30 batches in
> >> memory before the Out of Memory error occurs. So this is not an issue
> of my
> >> batch size being too high.
> >>
> >> But just to confirm, I set the batch size to 1, and it still ran into an
> >> out of memory error. So I feel fairly confident saying that the
> Gatherer is
> >> trying to grab all available data before sending any of it downstream.
> >>
> >> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com
> >
> >> wrote:
> >>
> >> Hello Core Libs Dev Team,
> >>
> >> I was trying out Gatherers for a project at work, and ran into a rather
> >> sad scenario.
> >>
> >> I need to process a large file in batches. Each batch is small enough
> that
> >> I can hold it in memory, but I cannot hold the entire file (and thus,
> all
> >> of the batches) in memory at once.
> >>
> >> Looking at the Gatherers API, I saw windowFixed and thought that it
> would
> >> be a great match for my use case.
> >>
> >> However, when trying it out, I was disappointed to see that it ran out
> of
> >> memory very quickly. Here is my attempt at using it.
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .forEach(eachList -> println(eachList.getFirst()))
> >> ;
> >>
> >> As you can see, I am just splitting the file into batches, and printing
> >> out the first of each batch. This is purely for example's sake, of
> course.
> >> I had planned on building even more functionality on top of this, but I
> >> couldn't even get past this example.
> >>
> >> But anyways, not even a single one of them printed out. Which leads me
> to
> >> believe that it's pulling all of them in the Gatherer.
> >>
> >> I can get it to run successfully if I go sequentially, but not parallel.
> >> Parallel gives me that out of memory error.
> >>
> >> Is there any way for me to be able to have the Gatherer NOT pull in
> >> everything while still remaining parallel and unordered?
> >>
> >> Thank you for your time and help.
> >> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241119/9083ce63/attachment-0001.htm>

From viktor.klang at oracle.com  Tue Nov 19 12:42:09 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Tue, 19 Nov 2024 12:42:09 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB577405D464DA1241736F8AF6FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
 <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
 <MW4PR10MB577405D464DA1241736F8AF6FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <MW4PR10MB57745275F5926E35597C6812FF202@MW4PR10MB5774.namprd10.prod.outlook.com>

Another thing which might add some detail:

This isn't really about short-circuiting under parallelization but rather a trade-off between depth-first vs breadth-first processing.

For sequential evaluation you typically want to perform depth-first processing since that means that you occupy ~constant space.

For parallel evaluation you need to perform [some level of] breadth-first processing (since otherwise there is no parallelism). So you need to decide what the evaluation strategy will be and where the join/merge-points are. For some operations which are inherently encounter-ordered you can "place a bet" (think: findFirst() where if you have multiple candidates each found in different chunks, you only keep the one which has the "earliest" encounter order), but for others, like foldLeft each subsequent value depends on the previous.

In the foldLeft case what Gatherers provide is ofSequential, which essentially instructs the processing that there's no use trying to parallelize this at all, so under parallel evaluation this stage needs to run sequentially?and that means that it must run to completion before downstream operations can continue, and by implication this also means that the output needs intermittent storage, so you are now in a breadth-first scenario.

In my experience, parallel streams are better suited for CPU-bound workloads where operations are trivially parallelizable (i.e. no encounter-order dependencies). Importantly, it's common to need to have a rather large set of elements in the stream to have the overhead of parallelization win over sequential evaluation. The only way to know what makes sense is to benchmark using realistic workloads.

Personally, I wouldn't be surprised if sequential streams plus the occasional Gatherers.mapConcurrent() covers > 90% of all Stream use-cases.

As a side-note, it is important to remember that Java Streams are push-style streams. (Push-style vs Pull-style vs Push-Pull-style is a longer conversation, but all of these strategies come with trade-offs)

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of Viktor Klang <viktor.klang at oracle.com>
Sent: Tuesday, 19 November 2024 13:19
To: David Alayachew <davidalayachew at gmail.com>
Cc: Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Hi David,

I've been thinking about this topic for a few days and haven't arrived at a satisfactory solution. Keep in mind that this "situation" has been in place ever since Streams were released, and perhaps Gatherers may be a catalyst to have it be more noticeable?I'll keep thinking about what could be done to make it more predictable (besides thinking about what rearrangements might make the situation go away).

In general though?short-circuiting in combination with parallelization requires a lot of tuning to make sure that the cost of processing more data doesn't overtake the benefit of "exiting early".


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Thursday, 14 November 2024 23:45
To: Viktor Klang <viktor.klang at oracle.com>
Cc: Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Oh ok. So it truly is a toss-up depending on each implementation when and where this occurs.

Ok, then as my final request, I think even informing the user that this CAN occur is worth doing. If nothing else, the user scouring the documentation for documentation of this behaviour will know that it is simply something that can occur. They don't need to know all the details. Simply give it a official term, describe the behaviour, tell that it is implementation specific on when this happens, but that it is only possible during parallelism. Even just knowing the verbiage to describe the problem will enable them to better communicate with each other on what they want vs what they get. That helps searchability, if nothing else.

On Thu, Nov 14, 2024, 8:45?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
I see what you're saying, the problem is that it depends on the Stream implementation (given that Stream is an interface).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Thursday, 14 November 2024 12:36
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>; core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Then let me correct myself again, while simplifying -- I just want that detail, that certain combinations might lead to pre-fetching everything, to be documented on the stream api. Package level, or on the Stream interface itself, seems like a good spot.

On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
The issue here is that the operation cannot advertise this, as it depends on the combination of operations.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Wednesday, 13 November 2024 14:07
To: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

That is a good point Rob.

Then let me correct myself -- I think the terminal operations don't do a great job of advertising whether or not they pre-fetch everything when parallelism is activated. Collector fetches as needed. FindAny pre-fetches everything. I understand that later releases might change their behaviour, but I still want to document the current behaviour in the official javadocs so that we can limit undocumented tripping hazards.


On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>> wrote:
distinct() doesn't require everything to be pulled. It can push elements
to the downstream as they come along for the first time. When
downstream.push returns false the gatherer is done.

As part of some experimentation I've implemented all intermediary
operations using gatherers. Most of them are pretty straightforward and
will stop integrating once the downstream starts rejecting elements
(although some use Gatherer.ofSequential to keep it easy). I only found
two exceptions that don't return the result of downstream.push:

* mapMulti. The downstream.push is passed as the mapper which is a
Consumer - the return value is ignored. With some more effort it's
probably possible to capture any false return value and return that from
the integrator, but I haven't tried that yet.

* sorted. Obviously every element needs to be inspected.


On 13/11/2024 00:37, David Alayachew wrote:
> Oh sure, I expect something like distinct() to pull everything. In order to
> know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
>
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
>
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
>
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
>
>
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>
>>> We are told how Streams can process unbounded data sets, but when it
>> tries to do a findAny() with parallel(), it runs into an OOME because it
>> fetched all the data ahead of time. In fact, almost of the terminal
>> operations will hit an OOME in the exact same way if they are parallel and
>> have a big enough data set. It's definitely not the end of the world, but
>> it seems that I have to fit everything into a Collector and/or a Gatherer
>> if I want to avoid pre-fetching everything.
>>
>> Yeah, I think it is important to distinguish "can process unbounded data
>> sets" from "always able to process unbounded data sets".
>>
>> Some operations inherently need the end of the stream, so even something
>> somple like: stream.distinct() or stream.sorted() can end up pulling in all
>> data (which of course won't terminate).
>>
>> Fortunately, I think Gatherers can unlock much more situations where
>> unbounded streams can be processed.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 15:08
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
>> as I thought of it.
>>
>>
>> I hand-waved away the idea because I thought that the method would turn
>> the stream pipeline parallel, thus, recreating the same problem I currently
>> have of parallelism causing all of the elements to be fetched ahead of
>> time, causing an OOME.
>>
>>
>> It did NOT occur to me that the pipeline would stay sequential, and just
>> kick these off sequentially, but have them executing in parallel. I can't
>> see why I came to that incorrect conclusion. I have read the javadocs of
>> this method several times. Though, to be fair, I came to the same,
>> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
>> until someone pointed out what the documentation was actually saying that I
>> realized it's true properties.
>>
>> Thanks. That definitely solves at least part of my problem. Obviously, I
>> would prefer to write to S3 in parallel too, but at the very least, the
>> calculation part is being done in parallel. And worst case scenario, I can
>> be really bad and just do the write to S3 in the mapConcurrent, and then
>> just return the metadata of each write, and just bundle that up with
>> collect.
>>
>>
>> And that's ignoring the fact that I can just use the workaround too.
>>
>>
>> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
>> from a performance perspective, but is rather unintuitive to me from a
>> usability perspective. We are told how Streams can process unbounded data
>> sets, but when it tries to do a findAny() with parallel(), it runs into an
>> OOME because it fetched all the data ahead of time. In fact, almost of the
>> terminal operations will hit an OOME in the exact same way if they are
>> parallel and have a big enough data set. It's definitely not the end of the
>> world, but it seems that I have to fit everything into a Collector and/or a
>> Gatherer if I want to avoid pre-fetching everything.
>>
>> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Have you considered Gatherers.mapConcurrent(?)?
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 01:53
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> Good to know, ty vm.
>>
>> At the very least, I have this workaround. This will meet my needs for now.
>>
>> I guess my final question would be -- is this type of problem better
>> suited to something besides parallel streams? Maybe an ExecutorService?
>>
>> Really, all I am doing is taking a jumbo file, splitting it into batches,
>> and then doing some work on those batches. My IO speeds are pretty fast,
>> and the compute work is non-trivial, so there is performance being left on
>> the table if I give up parallelism. And I am in a position where completion
>> time is very important to us.
>>
>> I just naturally assumed parallel streams were the right choice because
>> the compute work is simple. A pure function that I can break out, and then
>> call in a map. Once I do that, I just call forEach to write the batches
>> back out to S3. Maybe I should look into a different part of the std lib
>> instead because I am using the wrong tool for the job? My nose says
>> ExecutorService, but I figure I should ask before I dive too deep in.
>>
>>
>> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> You're most welcome!
>>
>> In a potential future where all intermediate operations are
>> Gatherer-based, and all terminal operations are Collector-based, it would
>> just work as expected. But with that said, I'm not sure it is practically
>> achievable because some operations might not have the same
>> performance-characteristics as before.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 18:32
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Thanks for the workaround. It's running beautifully.
>>
>> Is there a future where this island concept is extended to the rest of
>> streams? Tbh, I don't fully understand it.
>>
>> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Hi David,
>>
>> This is the effect of how parallel streams are implemented, where
>> different stages, which are not representible as a join-less Spliterator
>> are executed as a series of "islands" where the next isn't started until
>> the former has completed.
>>
>> If you think about it, parallelization of a Stream works best when the
>> entire data set can be split amongst a set of worker threads, and that sort
>> of implies that you want eager pre-fetch of data, so if your dataset does
>> not fit in memory, that is likely to lead to less desirable outcomes.
>>
>> What I was able to do for Gatherers is to implement "gather(?) +
>> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> immediately followed by a collect(?) is run in the same "island".
>>
>> So with that said, you could try something like the following:
>>
>> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
>> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> }
>>
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .collect(forEach(eachList -> println(eachList.getFirst())));
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David
>> Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 14:52
>> *To:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> elements
>>
>> And just to avoid the obvious question, I can hold about 30 batches in
>> memory before the Out of Memory error occurs. So this is not an issue of my
>> batch size being too high.
>>
>> But just to confirm, I set the batch size to 1, and it still ran into an
>> out of memory error. So I feel fairly confident saying that the Gatherer is
>> trying to grab all available data before sending any of it downstream.
>>
>> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> wrote:
>>
>> Hello Core Libs Dev Team,
>>
>> I was trying out Gatherers for a project at work, and ran into a rather
>> sad scenario.
>>
>> I need to process a large file in batches. Each batch is small enough that
>> I can hold it in memory, but I cannot hold the entire file (and thus, all
>> of the batches) in memory at once.
>>
>> Looking at the Gatherers API, I saw windowFixed and thought that it would
>> be a great match for my use case.
>>
>> However, when trying it out, I was disappointed to see that it ran out of
>> memory very quickly. Here is my attempt at using it.
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .forEach(eachList -> println(eachList.getFirst()))
>> ;
>>
>> As you can see, I am just splitting the file into batches, and printing
>> out the first of each batch. This is purely for example's sake, of course.
>> I had planned on building even more functionality on top of this, but I
>> couldn't even get past this example.
>>
>> But anyways, not even a single one of them printed out. Which leads me to
>> believe that it's pulling all of them in the Gatherer.
>>
>> I can get it to run successfully if I go sequentially, but not parallel.
>> Parallel gives me that out of memory error.
>>
>> Is there any way for me to be able to have the Gatherer NOT pull in
>> everything while still remaining parallel and unordered?
>>
>> Thank you for your time and help.
>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241119/2ef242eb/attachment-0001.htm>

From jpai at openjdk.org  Tue Nov 19 12:46:49 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 12:46:49 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v2]
In-Reply-To: <mtju6mXlaphTNQGK-QhX436Is1CDqWaQ3ZvGY-ezWb4=.d1087e25-c7ce-482c-9fbf-01a4e32dd4a5@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
 <FHcLuF3iuCDE3XCTftREqS7uf30Lgr39wB2h_IWa2Ps=.68862a14-dad8-42d0-aedb-222f53b222d1@github.com>
 <mtju6mXlaphTNQGK-QhX436Is1CDqWaQ3ZvGY-ezWb4=.d1087e25-c7ce-482c-9fbf-01a4e32dd4a5@github.com>
Message-ID: <zful00i-HPsy5d6qfM9idOWs--dvdJKSquvdxX2dNNU=.ec8428e5-f06b-4b73-acba-4c829f3b1fb7@github.com>

On Tue, 19 Nov 2024 11:31:27 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> concat the URLs to the resource in the modules and the class path

Did you mean "concat the URLs of the ...." ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22233#discussion_r1848291598

From alanb at openjdk.org  Tue Nov 19 12:46:49 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 12:46:49 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v2]
In-Reply-To: <zful00i-HPsy5d6qfM9idOWs--dvdJKSquvdxX2dNNU=.ec8428e5-f06b-4b73-acba-4c829f3b1fb7@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
 <FHcLuF3iuCDE3XCTftREqS7uf30Lgr39wB2h_IWa2Ps=.68862a14-dad8-42d0-aedb-222f53b222d1@github.com>
 <mtju6mXlaphTNQGK-QhX436Is1CDqWaQ3ZvGY-ezWb4=.d1087e25-c7ce-482c-9fbf-01a4e32dd4a5@github.com>
 <zful00i-HPsy5d6qfM9idOWs--dvdJKSquvdxX2dNNU=.ec8428e5-f06b-4b73-acba-4c829f3b1fb7@github.com>
Message-ID: <e6n_Kz6m90qBTz63uRJLxgUDjx4O7dS-Lt-3nrFPtZo=.17a0efe8-6898-41b4-b692-ba3964cbb58f@github.com>

On Tue, 19 Nov 2024 12:42:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> The new comment isn't quite right, it should say "concat the URLs to the resource in the modules and the class path".
>
>> concat the URLs to the resource in the modules and the class path
> 
> Did you mean "concat the URLs of the ...." ?

"of" or "to" will work here.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22233#discussion_r1848293564

From jpai at openjdk.org  Tue Nov 19 12:54:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 12:54:18 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v3]
In-Reply-To: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
Message-ID: <0vLDna2xJ3urJPGq2vPhglcjH8tEfnFtnx2-0ji2_to=.c270f275-753c-4934-ad74-f6dfc694b266@github.com>

> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
> 
> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
> 
> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:

  Alan's review - fix code comment

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22233/files
  - new: https://git.openjdk.org/jdk/pull/22233/files/5a82b729..1c26dbf2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22233&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22233&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22233/head:pull/22233

PR: https://git.openjdk.org/jdk/pull/22233

From jpai at openjdk.org  Tue Nov 19 12:54:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 12:54:18 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v2]
In-Reply-To: <e6n_Kz6m90qBTz63uRJLxgUDjx4O7dS-Lt-3nrFPtZo=.17a0efe8-6898-41b4-b692-ba3964cbb58f@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <qcu2xQUBuaKxHiP5KBvMhbQKHeBgSK7bqnh6gVeaLOM=.e0bfc48e-a91a-415a-9988-1e3c799d82ec@github.com>
 <FHcLuF3iuCDE3XCTftREqS7uf30Lgr39wB2h_IWa2Ps=.68862a14-dad8-42d0-aedb-222f53b222d1@github.com>
 <mtju6mXlaphTNQGK-QhX436Is1CDqWaQ3ZvGY-ezWb4=.d1087e25-c7ce-482c-9fbf-01a4e32dd4a5@github.com>
 <zful00i-HPsy5d6qfM9idOWs--dvdJKSquvdxX2dNNU=.ec8428e5-f06b-4b73-acba-4c829f3b1fb7@github.com>
 <e6n_Kz6m90qBTz63uRJLxgUDjx4O7dS-Lt-3nrFPtZo=.17a0efe8-6898-41b4-b692-ba3964cbb58f@github.com>
Message-ID: <smfH-NkT1PXA9mKrveUtkhADuHYhj7oCL_g8a7BG6mc=.504586a6-423c-426b-bb06-bc5c0e7c4162@github.com>

On Tue, 19 Nov 2024 12:43:48 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>>> concat the URLs to the resource in the modules and the class path
>> 
>> Did you mean "concat the URLs of the ...." ?
>
> "of" or "to" will work here.

Done - I've now updated this comment.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22233#discussion_r1848301570

From alanb at openjdk.org  Tue Nov 19 12:55:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 12:55:16 GMT
Subject: RFR: 8344143: Test
 jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out
 on  macosx-x64
Message-ID: <PGEjkYY9ag93OHGxfDBfWCBFVYTAP2u8CQ6x4bou0k8=.d8488269-c1f9-4ef8-b0d7-72cb4d29ebca@github.com>

Dial down GetStackTraceALotWhenBlocking and GetStackTraceALotWhenPinned as they make slow progress when executed concurrently on under power systems. GetStackTraceALotWhenBlocking has 3 busy threads, GetStackTraceALotWhenPinned has two spinning threads. When they run concurrently in jdk/:tier1_part1 then they compete for CPU cycles on systems with a small number of cores, specifically the macOS systems in CIs and GHA that have only 4 cores, and make slow progress.

Both tests are also changed to fail eagerly if the main thread is interrupted by jtreg. Also the progress output of both tests is adjusted to print a progress message every second if possible.

-------------

Commit messages:
 - Initial commit

Changes: https://git.openjdk.org/jdk/pull/22193/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22193&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344143
  Stats: 28 lines in 2 files changed: 17 ins; 4 del; 7 mod
  Patch: https://git.openjdk.org/jdk/pull/22193.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22193/head:pull/22193

PR: https://git.openjdk.org/jdk/pull/22193

From jpai at openjdk.org  Tue Nov 19 13:25:48 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Tue, 19 Nov 2024 13:25:48 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v3]
In-Reply-To: <0vLDna2xJ3urJPGq2vPhglcjH8tEfnFtnx2-0ji2_to=.c270f275-753c-4934-ad74-f6dfc694b266@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <0vLDna2xJ3urJPGq2vPhglcjH8tEfnFtnx2-0ji2_to=.c270f275-753c-4934-ad74-f6dfc694b266@github.com>
Message-ID: <X8GGJkWoJczKjSPhYted4MPrvkaQC1teLwKrG37mRVY=.5853080f-154d-4416-87dc-fe2a9b0579b1@github.com>

On Tue, 19 Nov 2024 12:54:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>> 
>> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
>> 
>> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
>> 
>> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - fix code comment

The CSR for this change is now ready for review https://bugs.openjdk.org/browse/JDK-8344543

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22233#issuecomment-2485703580

From sgehwolf at openjdk.org  Tue Nov 19 13:37:25 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Tue, 19 Nov 2024 13:37:25 GMT
Subject: RFR: 8336881: [Linux] Support for hierarchical limits for Metrics
 [v13]
In-Reply-To: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
References: <RviepgHrgldaZlfU8aUJXOBcbA19QVgXNAHrZvAoGRg=.c79db073-0b7e-4ae4-9ceb-80a400473e02@github.com>
Message-ID: <iQlyCOZvt_8gceL8zoCP0H54cnJfbvpMetxyqD2RIOs=.ad4e245b-fd17-444d-abaf-3a449b5590a7@github.com>

> Please review this fix for cgroups-based metrics reporting in the `jdk.internal.platform` package. This fix is supposed to address wrong reporting of certain limits if the limits aren't set at the leaf nodes.
> 
> For example, on cg v2, the memory limit interface file is `memory.max`. Consider a cgroup path of  `/a/b/c/d`. The current code only reports the limits (via Metrics) correctly if it's set at `/a/b/c/d/memory.max`. However, some systems - like a systemd slice - sets those limits further up the hierarchy. For example at `/a/b/c/memory.max`. `/a/b/c/d/memory.max` might be set to the value `max` (for unlimited), yet `/a/b/c/memory.max` would report the actual limit value (e.g. `1048576000`).
> 
> This patch addresses this issue by:
> 
> 1. Refactoring the interface lookup code to relevant controllers for cpu/memory. The CgroupSubsystem classes then delegate to those for the lookup. This facilitates having an API for the lookup of an updated limit in step 2.
> 2. Walking the full hierarchy of the cgroup path (if any), looking for a lower limit than at the leaf. Note that it's not possible to raise the limit set at a path closer to the root via the interface file at a further-to-the-leaf-level. The odd case out seems to be `max` values on some systems (which seems to be the default value).
> 
> As an optimization this hierarchy walk is skipped on containerized systems (like K8S), where the limits are set in interface files at the leaf nodes of the hierarchy. Therefore there should be no change on those systems.
> 
> This patch depends on the Hotspot change implementing the same for the JVM so that `Metrics.isContainerized()` works correctly on affected systems where `-XshowSettings:system` currently reports `System not containerized` due to the missing JVM fix. A test framework for such hierarchical systems has been added in [JDK-8333446](https://bugs.openjdk.org/browse/JDK-8333446). This patch adds a test using that framework among some simpler unit tests.
> 
> Thoughts?
> 
> Testing:
> 
> - [x] GHA
> - [x] Container tests on Linux x86_64 on cg v1 and cg v2 systems
> - [x] Some manual testing using systemd slices

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 38 commits:

 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Add exclusive access dirs directive for systemd tests
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Merge branch 'master' into jdk-8336881-metrics-systemd-slice
 - Improve systemd slice test for non-root on cg v2
 - Fix unit tests
 - Add JVM_HostActiveProcessorCount using JVM api
 - ... and 28 more: https://git.openjdk.org/jdk/compare/23597361...b56fc7b7

-------------

Changes: https://git.openjdk.org/jdk/pull/20280/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20280&range=12
  Stats: 1595 lines in 27 files changed: 1344 ins; 152 del; 99 mod
  Patch: https://git.openjdk.org/jdk/pull/20280.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20280/head:pull/20280

PR: https://git.openjdk.org/jdk/pull/20280

From mbaesken at openjdk.org  Tue Nov 19 13:46:51 2024
From: mbaesken at openjdk.org (Matthias Baesken)
Date: Tue, 19 Nov 2024 13:46:51 GMT
Subject: Integrated: 8344036: Tests tools/jlink/runtimeImage fail on AIX after
 JDK-8311302
In-Reply-To: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
References: <Zyw6l8Kp68X6Ms5T7TnFUztM-wWu1ZSsArRipXeKiZU=.59ea43d1-264e-4f9e-83f9-3f76112a6bf3@github.com>
Message-ID: <dcb2PZnDoCbC_zUulyYeny4f0PWaWU5vG70wTqH_hyk=.7f6ef087-71da-4190-a69d-4fc5663db542@github.com>

On Fri, 15 Nov 2024 09:18:27 GMT, Matthias Baesken <mbaesken at openjdk.org> wrote:

> On AIX we run into errors below, for example in test tools/jlink/runtimeImage/AddOptionsTest.java , this happened with fastdebug binaries, opt worked :
> 
> jlink options: --output java-base-with-opts-jlink-tmp --add-modules jdk.jlink,java.base --generate-linkable-runtime --keep-packaged-modules=java-base-with-opts-jlink-tmp/jmods
> Error: Java heap space
> java.lang.OutOfMemoryError: Java heap space
> at java.base/java.io.InputStream.readNBytes(InputStream.java:447)
> at java.base/java.io.InputStream.readAllBytes(InputStream.java:348)
> at jdk.jlink/jdk.tools.jlink.plugin.ResourcePoolEntry.contentBytes(ResourcePoolEntry.java:127)
> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.ResourcePoolReader.getResourceBytes(ResourcePoolReader.java:54)
> at jdk.jlink/jdk.tools.jlink.internal.runtimelink.JimageDiffGenerator.generateDiff(JimageDiffGenerator.java:89)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.addResourceDiffFiles(ImageFileCreator.java:357)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.generateJImage(ImageFileCreator.java:264)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.writeImage(ImageFileCreator.java:202)
> at jdk.jlink/jdk.tools.jlink.internal.ImageFileCreator.create(ImageFileCreator.java:131)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask$ImageHelper.retrieve(JlinkTask.java:1041)
> at jdk.jlink/jdk.tools.jlink.internal.ImagePluginStack.operate(ImagePluginStack.java:194)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.createImage(JlinkTask.java:501)
> at jdk.jlink/jdk.tools.jlink.internal.JlinkTask.run(JlinkTask.java:294)
> at jdk.jlink/jdk.tools.jlink.internal.Main.run(Main.java:56)
> at jdk.jlink/jdk.tools.jlink.internal.Main$JlinkToolProvider.run(Main.java:73)
> at tests.JImageGenerator$JLinkTask.call(JImageGenerator.java:713)
> at AbstractLinkableRuntimeTest.createRuntimeLinkImage(AbstractLinkableRuntimeTest.java:273)
> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:126)
> at AbstractLinkableRuntimeTest.createJavaImageRuntimeLink(AbstractLinkableRuntimeTest.java:121)
> at AddOptionsTest.runTest(AddOptionsTest.java:64)
> at AbstractLinkableRuntimeTest.run(AbstractLinkableRuntimeTest.java:62)
> at AddOptionsTest.main(AddOptionsTest.java:49)
> at java.base/java.lang.invoke.LambdaForm$DMH/0x0a0001009070c3e0.invokeStatic(LambdaForm$DMH)
> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090710c10.invoke(LambdaForm$MH)
> at java.base/java.lang.invoke.LambdaForm$MH/0x0a00010090711408.invokeExact_MT(LambdaForm$MH)
> at ja...

This pull request has now been integrated.

Changeset: cc8bd637
Author:    Matthias Baesken <mbaesken at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/cc8bd63741ce5745c144bf21b737c287d9b53817
Stats:     15 lines in 14 files changed: 1 ins; 0 del; 14 mod

8344036: Tests tools/jlink/runtimeImage fail on AIX after JDK-8311302

Reviewed-by: sgehwolf

-------------

PR: https://git.openjdk.org/jdk/pull/22140

From asemenyuk at openjdk.org  Tue Nov 19 13:56:05 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 13:56:05 GMT
Subject: Integrated: 8336087: Doccheck: the jpackage command page doesn't show
 the correct command-line options
In-Reply-To: <EMqlFQpnM8EVIutihC6dZ-ZR8ReMDtpQKBUCplV-BEU=.39cdcc24-ff7c-4cf4-83c6-e63071b79f32@github.com>
References: <EMqlFQpnM8EVIutihC6dZ-ZR8ReMDtpQKBUCplV-BEU=.39cdcc24-ff7c-4cf4-83c6-e63071b79f32@github.com>
Message-ID: <s61-foQqJ8cmXsHyvwd1NnPifi0XCD_zA1wKuduB3pY=.1324b9a2-02ff-49ab-94da-e178d6f893a5@github.com>

On Mon, 18 Nov 2024 13:21:25 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Simple typo fix.
> 
> Old view: https://github.com/openjdk/jdk/blob/dfddbcaab886b9baa731cd748bb7f547e1903b64/src/jdk.jpackage/share/man/jpackage.md
> 
> New view: https://github.com/alexeysemenyukoracle/jdk/blob/JDK-8336087/src/jdk.jpackage/share/man/jpackage.md
> 
> Navigate to "Group value of the RPM" text to see the diff

This pull request has now been integrated.

Changeset: 41436bb0
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/41436bb0e81ddf08fea189d9e1d020fb0ce8979b
Stats:     1 line in 1 file changed: 0 ins; 0 del; 1 mod

8336087: Doccheck: the jpackage command page doesn't show the correct command-line options

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/22206

From asemenyuk at openjdk.org  Tue Nov 19 13:57:55 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 13:57:55 GMT
Subject: Integrated: 8342299: Document that jpackage includes (possibly old) VC
 Redistributable MSVCP140.dll from JDK
In-Reply-To: <n7qPzuZYqFKRPTrTsndU-0g3rCDM44gd4Ywm33Rax5A=.147dd696-e7b9-4f10-b494-27b60c9fb30c@github.com>
References: <n7qPzuZYqFKRPTrTsndU-0g3rCDM44gd4Ywm33Rax5A=.147dd696-e7b9-4f10-b494-27b60c9fb30c@github.com>
Message-ID: <V4GuDuDFhHAznUit26jAybiliSEgNPQJeFV_gM_eGN8=.7760fc48-dd81-4d23-aaec-52492ae22991@github.com>

On Mon, 18 Nov 2024 15:45:22 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> jpackage man page update

This pull request has now been integrated.

Changeset: a28e4d83
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a28e4d839c9220655d78116be89c3c26b3d17a0e
Stats:     8 lines in 1 file changed: 8 ins; 0 del; 0 mod

8342299: Document that jpackage includes (possibly old) VC Redistributable MSVCP140.dll from JDK

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/22209

From asemenyuk at openjdk.org  Tue Nov 19 13:58:00 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 13:58:00 GMT
Subject: Integrated: 8344322: Improve capabilities of jpackage test lib to
 validate error output of jpackage
In-Reply-To: <Z8rT9yMl4LFbpTnDKffpBhu9J4xiuVRsze4KxrYHnSY=.a507cdb8-8ddd-4e70-b5a9-4d6ccd67abaf@github.com>
References: <Z8rT9yMl4LFbpTnDKffpBhu9J4xiuVRsze4KxrYHnSY=.a507cdb8-8ddd-4e70-b5a9-4d6ccd67abaf@github.com>
Message-ID: <_wWbVYH7ItZR-cptOP9n9612bDwLx_l32BRAws-nsgk=.74a5f3de-6fd7-48eb-977a-63c9715778f6@github.com>

On Mon, 18 Nov 2024 13:41:49 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Support using jpackage l10n keys instead of string values when examining jpackage error output.

This pull request has now been integrated.

Changeset: 0714114f
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/0714114fe3e0ac01657053164c61cbb702c0f9a0
Stats:     229 lines in 5 files changed: 192 ins; 12 del; 25 mod

8344322: Improve capabilities of jpackage test lib to validate error output of jpackage

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/22207

From asemenyuk at openjdk.org  Tue Nov 19 13:58:08 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 13:58:08 GMT
Subject: Integrated: 8344415: Restruct jpackage utility classes
In-Reply-To: <XWlQEer4GtF9Vz28SoF7dPJ74WghnRxZc05pPfkI8AQ=.1e607c0a-e6cf-4dd1-983f-f486a94b13cd@github.com>
References: <XWlQEer4GtF9Vz28SoF7dPJ74WghnRxZc05pPfkI8AQ=.1e607c0a-e6cf-4dd1-983f-f486a94b13cd@github.com>
Message-ID: <ul91SBOMRX44hzhHlgH_FJZMhetBbhPNEIAl68kNLCM=.ee2215fc-035f-4b19-915c-6d6b921deea3@github.com>

On Mon, 18 Nov 2024 18:31:09 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Move child classes of "jdk.jpackage.test.Functional" class to "jdk.jpackage.internal.util.function" package.
> Split "jdk.jpackage.internal.IOUtils" class in "PathUtils", "FileUtils", "XmlUtils" classes in "jdk.jpackage.internal.util" package.
> 
> Implmenetation didnt change except of `FileUtils.deleteRecursive()` that was cleared from the dependency on "AtomicReference".
> 
> Applied `bin/blessed-modifier-order.sh` script to the modified files.

This pull request has now been integrated.

Changeset: fea5f2b1
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/fea5f2b1458cdd53f437e59caaffaa6e22fb59a7
Stats:     1431 lines in 67 files changed: 860 ins; 417 del; 154 mod

8344415: Restruct jpackage utility classes

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/22216

From vklang at openjdk.org  Tue Nov 19 14:03:57 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 19 Nov 2024 14:03:57 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
Message-ID: <cw28XOFcODKPTKq5JlFIHM1iA8t0xsqjmdn9zJmWf54=.7f02df8e-b79b-44a6-a5f3-e2462a8a7e16@github.com>

On Fri, 15 Nov 2024 22:17:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
> 
> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
> 
> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
> 
> Testing: tier 1-5 green

@liach Out of curiosity, what kind of bench result different are you seeing with this change?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2485803584

From duke at openjdk.org  Tue Nov 19 14:14:12 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 19 Nov 2024 14:14:12 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v18]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <b0bX4TPuVf4-1KJy605YlepDeKFsvzMXUb8ba4BKT6k=.613cde42-3dc5-4cdc-8ca2-fd06d3ba39c8@github.com>

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
> 
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
> 
> x = y * 10 ^ exp
> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
> 
> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
> 
> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.

fabioromano1 has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 22 additional commits since the last revision:

 - Merge branch 'openjdk:master' into patchBigDecimalSqrt
 - Merge branch 'patchBigDecimalSqrt' of https://github.com/fabioromano1/jdk into patchBigDecimalSqrt
 - Optimize sqrt branch for exact results
 - Code simplification
 - Refine documentation
 - Refine documentation
 - Applying suggested changes
 - Avoid overflow
 - adjust to preferred scale in each branch for speed
 - Increment the unscaled sqrt for speed and round the result
 - ... and 12 more: https://git.openjdk.org/jdk/compare/9703530e...ae649247

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/2ca5eac9..ae649247

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=16-17

  Stats: 403675 lines in 5443 files changed: 191625 ins; 177454 del; 34596 mod
  Patch: https://git.openjdk.org/jdk/pull/21301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21301/head:pull/21301

PR: https://git.openjdk.org/jdk/pull/21301

From liach at openjdk.org  Tue Nov 19 14:19:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Nov 2024 14:19:54 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
Message-ID: <GQc-KfnD4fOl-uvjkvpXX91667JVPbNQNuwHmF4Jqss=.e0952e63-82ab-4a32-9868-5eb18bab8e1e@github.com>

On Fri, 15 Nov 2024 22:17:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
> 
> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
> 
> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
> 
> Testing: tier 1-5 green

I tested with the particular test case given in the original test, which is not a strict benchmark; still with the virtual method switched to MH accessor, average time is about 1/10 of before.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2485842041

From duke at openjdk.org  Tue Nov 19 14:26:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 19 Nov 2024 14:26:36 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v19]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <t8-mEBk_LZdCj_oCtuznfp3moghDeIdgSPXXcpbJu1g=.111e6831-3a58-4a7d-b31e-e7c7019b976c@github.com>

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
> 
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
> 
> x = y * 10 ^ exp
> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
> 
> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
> 
> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Optimization for non-zero remainder checking

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/ae649247..907de358

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=18
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=17-18

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/21301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21301/head:pull/21301

PR: https://git.openjdk.org/jdk/pull/21301

From pchilanomate at openjdk.org  Tue Nov 19 14:26:58 2024
From: pchilanomate at openjdk.org (Patricio Chilano Mateo)
Date: Tue, 19 Nov 2024 14:26:58 GMT
Subject: RFR: 8344143: Test
 jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out
 on  macosx-x64
In-Reply-To: <PGEjkYY9ag93OHGxfDBfWCBFVYTAP2u8CQ6x4bou0k8=.d8488269-c1f9-4ef8-b0d7-72cb4d29ebca@github.com>
References: <PGEjkYY9ag93OHGxfDBfWCBFVYTAP2u8CQ6x4bou0k8=.d8488269-c1f9-4ef8-b0d7-72cb4d29ebca@github.com>
Message-ID: <GogOtvqWwfaZ8kIAcideJeHEfExn9PXo5Gmx3bvQS6s=.217c4006-021c-4040-a5ed-10b6fd2e5f3d@github.com>

On Mon, 18 Nov 2024 09:28:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Dial down GetStackTraceALotWhenBlocking and GetStackTraceALotWhenPinned as they make slow progress when executed concurrently on under power systems. GetStackTraceALotWhenBlocking has 3 busy threads, GetStackTraceALotWhenPinned has two spinning threads. When they run concurrently in jdk/:tier1_part1 then they compete for CPU cycles on systems with a small number of cores, specifically the macOS systems in CIs and GHA that have only 4 cores, and make slow progress.
> 
> Both tests are also changed to fail eagerly if the main thread is interrupted by jtreg. Also the progress output of both tests is adjusted to print a progress message every second if possible.

Thanks for investigating this issue.

-------------

Marked as reviewed by pchilanomate (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22193#pullrequestreview-2445633719

From duke at openjdk.org  Tue Nov 19 14:29:47 2024
From: duke at openjdk.org (Francesco Nigro)
Date: Tue, 19 Nov 2024 14:29:47 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
Message-ID: <RKZVg7EQ0K6pQbE0jmD0_z3Ts-Lz7Z-MOt8f5bmp0M0=.60d07e01-d810-4d98-b7f9-e47d59fc0342@github.com>

On Fri, 15 Nov 2024 22:17:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
> 
> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
> 
> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
> 
> Testing: tier 1-5 green

Sorry I didn't shared this before, but https://gist.github.com/franz1981/4234195ca0168f3833023b610d91ddff
it should be the same issue (with a reproducer and a bit of analysis of profiling data)

FYI @viktorklang-ora

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2485859907

From pminborg at openjdk.org  Tue Nov 19 14:36:09 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Tue, 19 Nov 2024 14:36:09 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
In-Reply-To: <247YUHnpQpNcVDhb1Pf2vjrGd4bXDf6sBKT3bzSEcFA=.e4243266-6967-4fa1-b62b-6e680b66c2d7@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
 <247YUHnpQpNcVDhb1Pf2vjrGd4bXDf6sBKT3bzSEcFA=.e4243266-6967-4fa1-b62b-6e680b66c2d7@github.com>
Message-ID: <hiys3-zkdwaCk2HO01ix6BrVgYcN68f05IYfvcq2ADA=.3211f6fa-5cd5-49dd-94a8-f6891c9e52cc@github.com>

On Mon, 18 Nov 2024 19:30:35 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> The CSR for this change has been approved. I plan to integrate this tomorrow pending a final tier2 run.

Is this comment aimed at another PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22205#issuecomment-2485884259

From duke at openjdk.org  Tue Nov 19 14:44:40 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 19 Nov 2024 14:44:40 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v20]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <_fJUaRv1a31e9yfp1cnd1qSfko_CHTgf4f9Tp3-kWTQ=.65808a89-1f55-4af2-9b5f-bfdafd1ad997@github.com>

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
> 
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
> 
> x = y * 10 ^ exp
> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
> 
> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
> 
> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Correct remainder checking

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/907de358..2834b49e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=19
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=18-19

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21301/head:pull/21301

PR: https://git.openjdk.org/jdk/pull/21301

From eirbjo at openjdk.org  Tue Nov 19 14:54:57 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 14:54:57 GMT
Subject: RFR: 8344134: Use static property in SystemLookup
In-Reply-To: <hiys3-zkdwaCk2HO01ix6BrVgYcN68f05IYfvcq2ADA=.3211f6fa-5cd5-49dd-94a8-f6891c9e52cc@github.com>
References: <LQ5xzGZGmppukbU0GSoqZS9gr3R8obDJKPY_O1NqIuo=.387e738b-297a-4158-92e8-60f643bcb89b@github.com>
 <247YUHnpQpNcVDhb1Pf2vjrGd4bXDf6sBKT3bzSEcFA=.e4243266-6967-4fa1-b62b-6e680b66c2d7@github.com>
 <hiys3-zkdwaCk2HO01ix6BrVgYcN68f05IYfvcq2ADA=.3211f6fa-5cd5-49dd-94a8-f6891c9e52cc@github.com>
Message-ID: <Vxo9gDpq3hOvND47FN1DHfDVfZynk_jCp7sXwpFcBc8=.c156bf23-0778-42cc-92f1-6e1756b4ccb2@github.com>

On Tue, 19 Nov 2024 14:33:12 GMT, Per Minborg <pminborg at openjdk.org> wrote:

> > The CSR for this change has been approved. I plan to integrate this tomorrow pending a final tier2 run.
> 
> Is this comment aimed at another PR?

Haha, indeeed. This was for #22177 which is now integrated. Too many tabs :-)

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22205#issuecomment-2485934739

From rriggs at openjdk.org  Tue Nov 19 15:24:08 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 15:24:08 GMT
Subject: Integrated: 8344327: SM cleanup in jdk.unsupported ReflectionFactory
In-Reply-To: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
References: <fDxlXRDAncQLrgwBHndH5FLX6Upe44GknfjQrqtVoGA=.a35055b1-0bc0-4a92-a82d-220e729d8096@github.com>
Message-ID: <oHtZXwV336YFWMwsTBW6vxPkv4IzvMRV0wJPd0ouOPc=.d9f8d1d5-87c2-4c9c-9ef9-ebee3b06081f@github.com>

On Fri, 15 Nov 2024 18:32:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> This cleanup of the use of SecurityManager is in the jdk.unsupported module.
> Removed the permission check to call getReflectionFactory().

This pull request has now been integrated.

Changeset: ded01e43
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/ded01e4316a46d4c4a74d494db61d03f8591fd67
Stats:     31 lines in 1 file changed: 0 ins; 28 del; 3 mod

8344327: SM cleanup in jdk.unsupported ReflectionFactory

Reviewed-by: liach, mullan, alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22158

From vklang at openjdk.org  Tue Nov 19 15:25:52 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 19 Nov 2024 15:25:52 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <RKZVg7EQ0K6pQbE0jmD0_z3Ts-Lz7Z-MOt8f5bmp0M0=.60d07e01-d810-4d98-b7f9-e47d59fc0342@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <RKZVg7EQ0K6pQbE0jmD0_z3Ts-Lz7Z-MOt8f5bmp0M0=.60d07e01-d810-4d98-b7f9-e47d59fc0342@github.com>
Message-ID: <cgEjVEYZJOdzJcYwkHNpHPXcNAS8GF5HRgO2w6LS1sU=.c873d738-9384-4b7f-b86d-7604e7d33cac@github.com>

On Tue, 19 Nov 2024 14:23:58 GMT, Francesco Nigro <duke at openjdk.org> wrote:

>> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
>> 
>> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
>> 
>> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
>> 
>> Testing: tier 1-5 green
>
> Sorry I didn't shared this before, but https://gist.github.com/franz1981/4234195ca0168f3833023b610d91ddff
> it should be the same issue (with a reproducer and a bit of analysis of profiling data)
> 
> FYI @viktorklang-ora

@franz1981 Thanks?I was just curious as to the impact. ? /cc @liach

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2486018937

From asemenyuk at openjdk.org  Tue Nov 19 15:56:25 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 15:56:25 GMT
Subject: RFR: 8344550: Compilation error of jpackage test
 JPackageStringBundle.java source
Message-ID: <8MUJDHEDRcJZt3ap9KRJE8vSY5n8W8azsQ3SQblujiQ=.6da3b36f-59b5-40e0-9aa7-1750fddbe233@github.com>

Bad merge fix

-------------

Commit messages:
 - 8344550: Compilation error of jpackage test JPackageStringBundle.java source

Changes: https://git.openjdk.org/jdk/pull/22241/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22241&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344550
  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22241.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22241/head:pull/22241

PR: https://git.openjdk.org/jdk/pull/22241

From asemenyuk at openjdk.org  Tue Nov 19 15:56:25 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 15:56:25 GMT
Subject: RFR: 8344550: Compilation error of jpackage test
 JPackageStringBundle.java source
In-Reply-To: <8MUJDHEDRcJZt3ap9KRJE8vSY5n8W8azsQ3SQblujiQ=.6da3b36f-59b5-40e0-9aa7-1750fddbe233@github.com>
References: <8MUJDHEDRcJZt3ap9KRJE8vSY5n8W8azsQ3SQblujiQ=.6da3b36f-59b5-40e0-9aa7-1750fddbe233@github.com>
Message-ID: <CiAC9XZCl_AegZpVrkzzDHJdGBJHguc0nc_OhKWY2K4=.f935b7f6-dd50-4ffa-a803-4c632dc9bed9@github.com>

On Tue, 19 Nov 2024 15:50:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Bad merge fix

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22241#issuecomment-2486090092

From rriggs at openjdk.org  Tue Nov 19 16:05:00 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 16:05:00 GMT
Subject: RFR: 8344549: Cleanup AccessController in sun.misc.Unsafe
Message-ID: <k0e_3Hw7ViOlbX49AefxfoHtO2q7IbdyCKLxbRAUp0o=.43b2b136-70b1-41a4-a72c-a605873b1b83@github.com>

Unwrap calls using doPrivileged in jdk.unsupported sun.misc.Unsafe.

-------------

Commit messages:
 - simplify declaration of INSTANCE
 - 8344549: Cleanup AccessController in sun.misc.Unsafe

Changes: https://git.openjdk.org/jdk/pull/22242/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22242&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344549
  Stats: 16 lines in 1 file changed: 0 ins; 12 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22242.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22242/head:pull/22242

PR: https://git.openjdk.org/jdk/pull/22242

From hgreule at openjdk.org  Tue Nov 19 16:11:14 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 19 Nov 2024 16:11:14 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
Message-ID: <8-11iSlDurp5uruEU9oyF0302kSMtS5cU5lf3gtiiqQ=.28dc19b7-06b9-4487-a8f1-6bb1d91c1679@github.com>

On Fri, 15 Nov 2024 22:17:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
> 
> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
> 
> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
> 
> Testing: tier 1-5 green

src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 430:

> 428:         // Single parameter of declared type Object[]
> 429:         Class<?>[] parameters = reflectionFactory.getExecutableSharedParameterTypes(method);
> 430:         return parameters.length == 1 && parameters[0] == Object[].class;

Would it be possible to check for the `PolymorphicSignature` annotation instead?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1848647321

From vklang at openjdk.org  Tue Nov 19 16:12:52 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 19 Nov 2024 16:12:52 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
Message-ID: <WaC_aWYoeA2wKEX8FXpHB-rMooYB0U0xM6EnZ6RDAJ4=.bb0d5f3d-75ff-40a1-95df-fb4308c7f128@github.com>

On Sun, 17 Nov 2024 15:33:02 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2053:

> 2051:                     if (((phase = deactivate(w, phase)) & IDLE) != 0)
> 2052:                         break;
> 2053:                     src = -1;

@DougLea So if I understand this correctly, the setting of `src` to -1 is to differ from `j` on the next loop step (since `j` is bound by bitmask to be positive)?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848650671

From alanb at openjdk.org  Tue Nov 19 16:21:50 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 16:21:50 GMT
Subject: RFR: 8344549: Cleanup AccessController in sun.misc.Unsafe
In-Reply-To: <k0e_3Hw7ViOlbX49AefxfoHtO2q7IbdyCKLxbRAUp0o=.43b2b136-70b1-41a4-a72c-a605873b1b83@github.com>
References: <k0e_3Hw7ViOlbX49AefxfoHtO2q7IbdyCKLxbRAUp0o=.43b2b136-70b1-41a4-a72c-a605873b1b83@github.com>
Message-ID: <XT5cNRHFDqqRCHMH8f9TFLSmncL0ujlRRT5OxApP7sA=.caf10607-0293-49c0-adb9-34be3ae553ba@github.com>

On Tue, 19 Nov 2024 15:58:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Unwrap calls using doPrivileged in jdk.unsupported sun.misc.Unsafe.

Good

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22242#pullrequestreview-2445973187

From duke at openjdk.org  Tue Nov 19 16:27:26 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 19 Nov 2024 16:27:26 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <r9eKHNULUj1MRQbDg1tfT5MprAIHZP2rLXnjBlWsYlw=.fbc77506-c477-4138-8dd0-1f0cc3895fc3@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

Shall I give it another day or two before integrating?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2486177273

From eirbjo at openjdk.org  Tue Nov 19 16:30:50 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Tue, 19 Nov 2024 16:30:50 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
Message-ID: <dSX5F0cz58F6KPMi0eaZDqRmHQTGA_hjJBGk9lJXqS4=.b1cbd6d0-9e9e-4166-905e-e59988720bd8@github.com>

On Fri, 15 Nov 2024 14:50:21 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> Currently, the man pages are stored as troff (a text format) in the open repo, and a content-wise identical copy is stored as markdown (another text format) in the closed repo.
>> 
>> Since markdown is preferred to troff in terms of editing, we make changes to the man pages in markdown and then convert it to troff.
>> 
>> This closed-markdown to open-troff processing needs to be done manually by an Oracle engineer. This is done regularly at the start and end of a new release cycle, adding to the burden of creating a new release. It is also done (if any of the reviewers knows about the process) whenever an Oracle engineer updates a man page. If a community contributor changes the behavior of a tool, an Oracle engineer needs to change the documentation for them, since they cannot do it themselves.
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   It's somewhat nicer to use \\s instead of space character in regex

Is the warning log when pandoc is not installed a bit loud?


% make images
Building target 'images' in configuration 'macosx-x86_64-server-release'
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Warning: pandoc not found. Not generating man pages
Finished building target 'images' in configuration 'macosx-x86_64-server-release'

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2486187436

From liach at openjdk.org  Tue Nov 19 16:32:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Nov 2024 16:32:49 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <aaxNxEBDBwpuW6Xmfj2hvBgQxVPqh3uZVl3pGNZcPgc=.9c0237be-278e-437b-a954-f28b533982df@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

Do you want Alan to review? I can ask him offline if he is interested or if this can be merged as-is.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2486190290

From duke at openjdk.org  Tue Nov 19 16:37:01 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Tue, 19 Nov 2024 16:37:01 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <cvO7Clx6muuXQA0fCrRhDbvzByVGTtvuXKD6wbupQ6U=.0ba0ca67-c5c1-4442-9d17-339f95ada52e@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

I'm fine either way. More eyes is better but if Alan is busy that's fine; I'm reasonably confident in this change at this point.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2486202701

From liach at openjdk.org  Tue Nov 19 16:38:45 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Nov 2024 16:38:45 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <8-11iSlDurp5uruEU9oyF0302kSMtS5cU5lf3gtiiqQ=.28dc19b7-06b9-4487-a8f1-6bb1d91c1679@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <8-11iSlDurp5uruEU9oyF0302kSMtS5cU5lf3gtiiqQ=.28dc19b7-06b9-4487-a8f1-6bb1d91c1679@github.com>
Message-ID: <2uZCbedHs4fAKMGE8MGrZeRBxTM6sdjQsiPOX5z0zak=.eae9d186-8bcb-4aab-9300-24947f79b7fa@github.com>

On Tue, 19 Nov 2024 16:08:20 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
>> 
>> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
>> 
>> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
>> 
>> Testing: tier 1-5 green
>
> src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 430:
> 
>> 428:         // Single parameter of declared type Object[]
>> 429:         Class<?>[] parameters = reflectionFactory.getExecutableSharedParameterTypes(method);
>> 430:         return parameters.length == 1 && parameters[0] == Object[].class;
> 
> Would it be possible to check for the `PolymorphicSignature` annotation instead?

I think the main problem with annotation is that annotation creation needs to use `java.lang.reflect.Proxy`, which is unavailable until module system is initialized. Extra allocations are costs too, while checks here only reuse existing objects.

In fact, I don't think Java's core libraries ever check for annotations, and the annotation's support class, `jdk.internal.reflect.ConstantPool`, has always been only loaded but never initialized in a simple hello world program since Java 5.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1848692679

From alanb at openjdk.org  Tue Nov 19 16:41:03 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 16:41:03 GMT
Subject: Integrated: 8344143: Test
 jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out
 on  macosx-x64
In-Reply-To: <PGEjkYY9ag93OHGxfDBfWCBFVYTAP2u8CQ6x4bou0k8=.d8488269-c1f9-4ef8-b0d7-72cb4d29ebca@github.com>
References: <PGEjkYY9ag93OHGxfDBfWCBFVYTAP2u8CQ6x4bou0k8=.d8488269-c1f9-4ef8-b0d7-72cb4d29ebca@github.com>
Message-ID: <pWBIG3hff636no-Yq_cH7QK7c96xoSzUuEpaTWJltAw=.e0334590-528d-42ee-9a63-355562206470@github.com>

On Mon, 18 Nov 2024 09:28:58 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> Dial down GetStackTraceALotWhenBlocking and GetStackTraceALotWhenPinned as they make slow progress when executed concurrently on under power systems. GetStackTraceALotWhenBlocking has 3 busy threads, GetStackTraceALotWhenPinned has two spinning threads. When they run concurrently in jdk/:tier1_part1 then they compete for CPU cycles on systems with a small number of cores, specifically the macOS systems in CIs and GHA that have only 4 cores, and make slow progress.
> 
> Both tests are also changed to fail eagerly if the main thread is interrupted by jtreg. Also the progress output of both tests is adjusted to print a progress message every second if possible.

This pull request has now been integrated.

Changeset: 48223f7b
Author:    Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/48223f7b9c6fbaf4e6751a5b41ea9e9046a48f91
Stats:     28 lines in 2 files changed: 17 ins; 4 del; 7 mod

8344143: Test jdk/java/lang/Thread/virtual/stress/GetStackTraceALotWhenPinned.java timed out on  macosx-x64

Reviewed-by: pchilanomate

-------------

PR: https://git.openjdk.org/jdk/pull/22193

From liach at openjdk.org  Tue Nov 19 16:44:54 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Nov 2024 16:44:54 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <2uZCbedHs4fAKMGE8MGrZeRBxTM6sdjQsiPOX5z0zak=.eae9d186-8bcb-4aab-9300-24947f79b7fa@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <8-11iSlDurp5uruEU9oyF0302kSMtS5cU5lf3gtiiqQ=.28dc19b7-06b9-4487-a8f1-6bb1d91c1679@github.com>
 <2uZCbedHs4fAKMGE8MGrZeRBxTM6sdjQsiPOX5z0zak=.eae9d186-8bcb-4aab-9300-24947f79b7fa@github.com>
Message-ID: <ipZHgeOPRp9nFUpi0j1ozWSaWZmGlhYQwxQ5ex0KJ58=.bd830307-aa28-4087-9cb9-b2ba26094f02@github.com>

On Tue, 19 Nov 2024 16:35:44 GMT, Chen Liang <liach at openjdk.org> wrote:

>> src/java.base/share/classes/jdk/internal/reflect/MethodHandleAccessorFactory.java line 430:
>> 
>>> 428:         // Single parameter of declared type Object[]
>>> 429:         Class<?>[] parameters = reflectionFactory.getExecutableSharedParameterTypes(method);
>>> 430:         return parameters.length == 1 && parameters[0] == Object[].class;
>> 
>> Would it be possible to check for the `PolymorphicSignature` annotation instead?
>
> I think the main problem with annotation is that annotation creation needs to use `java.lang.reflect.Proxy`, which is unavailable until module system is initialized. Extra allocations are costs too, while checks here only reuse existing objects.
> 
> In fact, I don't think Java's core libraries ever check for annotations, and the annotation's support class, `jdk.internal.reflect.ConstantPool`, has always been only loaded but never initialized in a simple hello world program since Java 5.

In fact, another solution I have contemplated is to update `JavaLangInvokeAccess` implementations. 4 methods in it, `unreflectConstructor`, `unreflectField`, `findVirtual`, and `findStatic`, are exclusively used by core reflection.

That solution proposes to bypass `findVirtualForMH`/`findVirtualForVH` and bypass `setVarargs(MemberName)` in `getDirectMethodCommon`/`getDirectConstructorCommon` in these internal hooks.

But I think this may be too invasive and unfriendly to backports (also note: backport to 21 isn't clean, there is a small conflict in doc comments), and using native instead of MH for these 2 corner cases shouldn't be too big of a performance concern.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1848704448

From hgreule at openjdk.org  Tue Nov 19 16:48:45 2024
From: hgreule at openjdk.org (Hannes Greule)
Date: Tue, 19 Nov 2024 16:48:45 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <ipZHgeOPRp9nFUpi0j1ozWSaWZmGlhYQwxQ5ex0KJ58=.bd830307-aa28-4087-9cb9-b2ba26094f02@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <8-11iSlDurp5uruEU9oyF0302kSMtS5cU5lf3gtiiqQ=.28dc19b7-06b9-4487-a8f1-6bb1d91c1679@github.com>
 <2uZCbedHs4fAKMGE8MGrZeRBxTM6sdjQsiPOX5z0zak=.eae9d186-8bcb-4aab-9300-24947f79b7fa@github.com>
 <ipZHgeOPRp9nFUpi0j1ozWSaWZmGlhYQwxQ5ex0KJ58=.bd830307-aa28-4087-9cb9-b2ba26094f02@github.com>
Message-ID: <kWWjp7-JMpy0O7vWMKUnSLmD96cZMs-_kOq9IVQtP7Q=.997b2b24-014c-4d23-96ad-bac4a1149246@github.com>

On Tue, 19 Nov 2024 16:42:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> I think the main problem with annotation is that annotation creation needs to use `java.lang.reflect.Proxy`, which is unavailable until module system is initialized. Extra allocations are costs too, while checks here only reuse existing objects.
>> 
>> In fact, I don't think Java's core libraries ever check for annotations, and the annotation's support class, `jdk.internal.reflect.ConstantPool`, has always been only loaded but never initialized in a simple hello world program since Java 5.
>
> In fact, another solution I have contemplated is to update `JavaLangInvokeAccess` implementations. 4 methods in it, `unreflectConstructor`, `unreflectField`, `findVirtual`, and `findStatic`, are exclusively used by core reflection.
> 
> That solution proposes to bypass `findVirtualForMH`/`findVirtualForVH` and bypass `setVarargs(MemberName)` in `getDirectMethodCommon`/`getDirectConstructorCommon` in these internal hooks.
> 
> But I think this may be too invasive and unfriendly to backports (also note: backport to 21 isn't clean, there is a small conflict in doc comments), and using native instead of MH for these 2 corner cases shouldn't be too big of a performance concern.

Okay, in that case it's probably fine - I assume there's also no easy way to ensure in a test that all signature polymorphic methods are covered by these checks?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1848710006

From rriggs at openjdk.org  Tue Nov 19 16:49:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 16:49:56 GMT
Subject: RFR: 8344550: Compilation error of jpackage test
 JPackageStringBundle.java source
In-Reply-To: <8MUJDHEDRcJZt3ap9KRJE8vSY5n8W8azsQ3SQblujiQ=.6da3b36f-59b5-40e0-9aa7-1750fddbe233@github.com>
References: <8MUJDHEDRcJZt3ap9KRJE8vSY5n8W8azsQ3SQblujiQ=.6da3b36f-59b5-40e0-9aa7-1750fddbe233@github.com>
Message-ID: <HRyxS77zUrUEB7LQRj7TX2mkwprbd0pUOb5rmLd-WSA=.6367055f-59ae-4ae6-b6be-bbd02ce86f85@github.com>

On Tue, 19 Nov 2024 15:50:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Bad merge fix

The patch worked for me; lets get this fixed.

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22241#pullrequestreview-2446050094

From bpb at openjdk.org  Tue Nov 19 16:53:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Nov 2024 16:53:27 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v3]
In-Reply-To: <gBg11daChj4EjyUkoClLcNSIn7Z5aPKXN-RGMM4Wlzg=.68d03bfa-bf38-45df-8751-ec2a3a595b20@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <VCnLIe3bCm8omYUvww8BnqmzCJyvQzH2qQ0qNJ7GS74=.49a0053f-cc28-4f7e-a277-0e2874c534ba@github.com>
 <gBg11daChj4EjyUkoClLcNSIn7Z5aPKXN-RGMM4Wlzg=.68d03bfa-bf38-45df-8751-ec2a3a595b20@github.com>
Message-ID: <2gk-nNfTQVPFG6tDnDhTvkn7KC09U6a8kgzAYriWnts=.f2b662d0-2795-49d2-9d3d-e520dbc1ebe3@github.com>

On Tue, 19 Nov 2024 07:56:55 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344446: Revert spurious inclusion of SCTP changes
>
> src/java.base/share/classes/java/io/FileInputStream.java line 136:
> 
>> 134:         if (name == null) {
>> 135:             throw new NullPointerException();
>> 136:         }
> 
> I assume (old) L133-139 can be replaced with `String name = file.getPath()`, the explicit check that name is null goes away with the SM check.

See 9fbcb82.

> src/java.base/share/classes/java/io/FileOutputStream.java line 205:
> 
>> 203:         if (name == null) {
>> 204:             throw new NullPointerException();
>> 205:         }
> 
> Same comment as the FOS constructor.

See 9fbcb82.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1848715568
PR Review Comment: https://git.openjdk.org/jdk/pull/22219#discussion_r1848715621

From bpb at openjdk.org  Tue Nov 19 16:53:27 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Nov 2024 16:53:27 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v4]
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <sO_kDlu8NOOrng8dBr2kpS3AnHme2OeZuQEZtOBFVAw=.f6028377-74bf-4eed-ad83-71b37639399d@github.com>

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8344446: Address reviewer comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22219/files
  - new: https://git.openjdk.org/jdk/pull/22219/files/a15574a3..9fbcb823

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22219&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22219&range=02-03

  Stats: 15 lines in 2 files changed: 3 ins; 10 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22219.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22219/head:pull/22219

PR: https://git.openjdk.org/jdk/pull/22219

From jiangli at openjdk.org  Tue Nov 19 16:55:14 2024
From: jiangli at openjdk.org (Jiangli Zhou)
Date: Tue, 19 Nov 2024 16:55:14 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v9]
In-Reply-To: <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <EAfwJ0jtfI7BDP5SjM7a6AqErWeVQ7yHqrAje9d7Yx0=.ace20be4-dbec-4172-8e9a-a6506cd07d8a@github.com>
 <ZrGBEvjcR_2HIgnhwbndnm9J2AzumuWWAjSMbR7ClQw=.130b5d02-506c-4a6e-9402-473734a7d5b1@github.com>
 <QEyhmjtUis_7E8umUO_S7CpGfLxFMCGcKpkYbqxyR-c=.52160107-9ba4-4884-a6d9-1bc208126e7c@github.com>
 <u2fHrEnR89C-zHBHVzzTWT9OxlkbWj-a653OQVhPTt4=.b9bf0775-d5fb-4aa5-b441-d4a8db85b15e@github.com>
 <RMacEqw-EG630Un-DYa-lMKkRFNsItFUqzvvRf6dT64=.349aceb7-a266-4fbd-b11f-3420ba56fd81@github.com>
 <4TglRts9KEQcf0NHTe2LvbzxSK9w5PoaEcIQhP-7fD8=.815bf1da-830d-4035-95bf-1916322f9567@github.com>
Message-ID: <g8WYeWvEKm866CVcBJ5zGwbq3eswifUHIJr5q6hBq90=.56717a02-7172-472b-a5de-551838459648@github.com>

On Wed, 13 Nov 2024 01:40:23 GMT, Jiangli Zhou <jiangli at openjdk.org> wrote:

>> @jianglizhou Thank you for your assistance in figuring out the problem. I guess I throw out too much code from the hermetic-java-runtime branch when trying to minimize the changes to only build-related stuff. The jimage changes were so busy so I probably ignored them a bit too much.
>
> @magicus Just want to check if there's anything that you are waiting from me for this PR. My understanding is that you'll update the PR to fix the incremental build and debuginfo before the last review iteration. Please let me know if there are anything else. Thanks!

> @jianglizhou
> 
> > I think we would need to decide what is the dll_dir with the static JDK support and hermetic support.
> 
> From my understanding, `_sun_boot_library_path` does not have any meaning when running with static builds. As I said before, I think we really ought to take a step back, consider the wider picture, and refactor the way we interact with internal native libraries. Determining how to handle `_sun_boot_library_path` for static builds are definitely part of that work.

There might still be some usages of `_sun_boot_library_path` with static JDK. I recently made changes (in our local copy and not yet in https://github.com/openjdk/leyden/tree/hermetic-java-runtime) to use `_sun_boot_library_path` to locate the `jspawnhelper` in `<jdk>/lib` when spawning child process is needed, for supporting specific hermetic Java testing mode (without building a full hermetic image). At some point, we want to call out the supported execution modes (e.g. hermetic mode, dynamic/tradition mode, hermetic testing mode, etc) in https://docs.google.com/document/d/1LWy9vFDis5-hbJwrFUBH1rc8w8f3oL6O3sOzQXjXVUM/edit?usp=sharing as part of the ongoing discussions with Alan, Ron and others. Agreed that `_sun_boot_library_path` should be part of the bigger picture design/discussion.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20837#issuecomment-2486244160

From asemenyuk at openjdk.org  Tue Nov 19 16:59:07 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 16:59:07 GMT
Subject: Integrated: 8344550: Compilation error of jpackage test
 JPackageStringBundle.java source
In-Reply-To: <8MUJDHEDRcJZt3ap9KRJE8vSY5n8W8azsQ3SQblujiQ=.6da3b36f-59b5-40e0-9aa7-1750fddbe233@github.com>
References: <8MUJDHEDRcJZt3ap9KRJE8vSY5n8W8azsQ3SQblujiQ=.6da3b36f-59b5-40e0-9aa7-1750fddbe233@github.com>
Message-ID: <TNE2VApEU5GQD1Itth-sq3_rNeigLQQ5PdlBB2byPoo=.e1925008-e954-4ad3-9ba7-4d3001c22b64@github.com>

On Tue, 19 Nov 2024 15:50:07 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Bad merge fix

This pull request has now been integrated.

Changeset: 7f672eb2
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/7f672eb266b76a9310dcf108f72adf2469e63dee
Stats:     3 lines in 1 file changed: 1 ins; 0 del; 2 mod

8344550: Compilation error of jpackage test JPackageStringBundle.java source

Reviewed-by: rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/22241

From alanb at openjdk.org  Tue Nov 19 17:00:55 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Tue, 19 Nov 2024 17:00:55 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v4]
In-Reply-To: <sO_kDlu8NOOrng8dBr2kpS3AnHme2OeZuQEZtOBFVAw=.f6028377-74bf-4eed-ad83-71b37639399d@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <sO_kDlu8NOOrng8dBr2kpS3AnHme2OeZuQEZtOBFVAw=.f6028377-74bf-4eed-ad83-71b37639399d@github.com>
Message-ID: <zFu02RWoD6El8HTwQBXk9Yq42GtUIUjLPZOLe5Yn-n4=.bf159d4b-d4a4-4902-8f3e-5d039fe825ac@github.com>

On Tue, 19 Nov 2024 16:53:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344446: Address reviewer comments

Marked as reviewed by alanb (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2446072996

From rriggs at openjdk.org  Tue Nov 19 17:00:56 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 17:00:56 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v4]
In-Reply-To: <sO_kDlu8NOOrng8dBr2kpS3AnHme2OeZuQEZtOBFVAw=.f6028377-74bf-4eed-ad83-71b37639399d@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <sO_kDlu8NOOrng8dBr2kpS3AnHme2OeZuQEZtOBFVAw=.f6028377-74bf-4eed-ad83-71b37639399d@github.com>
Message-ID: <_1GmywY6TxQDZjbiBmVA2eSTU3HicQTHPhuQ6ZU7sUI=.90eb61c4-e0e5-404f-8778-bbfe0ec6b2ab@github.com>

On Tue, 19 Nov 2024 16:53:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344446: Address reviewer comments

Marked as reviewed by rriggs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22219#pullrequestreview-2446076768

From vklang at openjdk.org  Tue Nov 19 17:00:59 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Tue, 19 Nov 2024 17:00:59 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
Message-ID: <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>

On Sun, 17 Nov 2024 15:33:02 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2780:

> 2778:                 now = true;
> 2779:         }
> 2780:         if (now) {

@DougLea I'd probably add a blank line above this one to signal that this if is not a part of the previous if-else chain.

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2805:

> 2803:             }
> 2804:         }
> 2805:         return e;

@DougLea Is there any benefit to using `break` in the loop rather than `return e;` directly?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2838:

> 2836:                         }
> 2837:                     }
> 2838:                     else if ((q.phase & (IDLE|1)) == 0 ||

@DougLea What's the intent of the `|1` part here? ?

src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 4082:

> 4080:             AccessController.doPrivileged(new PrivilegedAction<>() {
> 4081:                     public ForkJoinPool run() {
> 4082:                         return new ForkJoinPool((byte)0); }});

@AlanBateman Any recommendation as to what is ideal here with SM removed? /cc @DougLea

src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 247:

> 245:         = U.objectFieldOffset(Thread.class, "threadLocals");
> 246:     private static final long INHERITABLETHREADLOCALS
> 247:         = U.objectFieldOffset(Thread.class, "inheritableThreadLocals");

@AlanBateman Thoughts here? ?

src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 270:

> 268:         @SuppressWarnings("removal")
> 269:         public void setContextClassLoader(ClassLoader cl) {
> 270:             if (System.getSecurityManager() != null &&

@AlanBateman Alternatives for this? ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848717378
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848720748
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848722786
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848724803
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848727422
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848728622

From dfuchs at openjdk.org  Tue Nov 19 17:02:01 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Nov 2024 17:02:01 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v2]
In-Reply-To: <nUmdm2qAkhj91dOAKYssC1lVpahjlNC1UaNlo1i5eaU=.5d93a2c9-09af-4e22-b196-02a841f28ab0@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <nUmdm2qAkhj91dOAKYssC1lVpahjlNC1UaNlo1i5eaU=.5d93a2c9-09af-4e22-b196-02a841f28ab0@github.com>
Message-ID: <JXHDFqDclzWLcu1yt6W_h5NVvrIVzayLyip5VEboPIs=.eff424a3-e295-4d54-8b89-48bf053f2bc3@github.com>

On Tue, 19 Nov 2024 00:53:22 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>>     - `com.sun.jndi.rmi.object.trustURLCodebase`
>> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
>> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
>> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
>> 
>> These changes require a CSR that will be submitted soon.
>> 
>> ### Testing
>> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
>> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Implement Daniel suggestions, add missing new lines to test files

LGTM

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22154#pullrequestreview-2446079717

From bpb at openjdk.org  Tue Nov 19 17:07:04 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Nov 2024 17:07:04 GMT
Subject: RFR: 8344077: Remove security manager dependency in java.io [v4]
In-Reply-To: <sO_kDlu8NOOrng8dBr2kpS3AnHme2OeZuQEZtOBFVAw=.f6028377-74bf-4eed-ad83-71b37639399d@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
 <sO_kDlu8NOOrng8dBr2kpS3AnHme2OeZuQEZtOBFVAw=.f6028377-74bf-4eed-ad83-71b37639399d@github.com>
Message-ID: <02SIY-HPpFtcNjgX35_BLMDG9wmU2FWMZ3ZcsPvtF0I=.51df16e2-3c57-482d-8776-1472daeae084@github.com>

On Tue, 19 Nov 2024 16:53:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344446: Address reviewer comments

Thanks, everyone, for the comments and reviews. I will integrate once this has cleared tier 1-3 testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22219#issuecomment-2486272068

From liach at openjdk.org  Tue Nov 19 17:17:49 2024
From: liach at openjdk.org (Chen Liang)
Date: Tue, 19 Nov 2024 17:17:49 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <kWWjp7-JMpy0O7vWMKUnSLmD96cZMs-_kOq9IVQtP7Q=.997b2b24-014c-4d23-96ad-bac4a1149246@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <8-11iSlDurp5uruEU9oyF0302kSMtS5cU5lf3gtiiqQ=.28dc19b7-06b9-4487-a8f1-6bb1d91c1679@github.com>
 <2uZCbedHs4fAKMGE8MGrZeRBxTM6sdjQsiPOX5z0zak=.eae9d186-8bcb-4aab-9300-24947f79b7fa@github.com>
 <ipZHgeOPRp9nFUpi0j1ozWSaWZmGlhYQwxQ5ex0KJ58=.bd830307-aa28-4087-9cb9-b2ba26094f02@github.com>
 <kWWjp7-JMpy0O7vWMKUnSLmD96cZMs-_kOq9IVQtP7Q=.997b2b24-014c-4d23-96ad-bac4a1149246@github.com>
Message-ID: <hfGbYuJnUAScWOTFMFFyiuB3alAP5uMBEa6aQZNoywo=.84cebc75-a8fd-4116-aea9-6fc6815db1a1@github.com>

On Tue, 19 Nov 2024 16:45:47 GMT, Hannes Greule <hgreule at openjdk.org> wrote:

>> In fact, another solution I have contemplated is to update `JavaLangInvokeAccess` implementations. 4 methods in it, `unreflectConstructor`, `unreflectField`, `findVirtual`, and `findStatic`, are exclusively used by core reflection.
>> 
>> That solution proposes to bypass `findVirtualForMH`/`findVirtualForVH` and bypass `setVarargs(MemberName)` in `getDirectMethodCommon`/`getDirectConstructorCommon` in these internal hooks.
>> 
>> But I think this may be too invasive and unfriendly to backports (also note: backport to 21 isn't clean, there is a small conflict in doc comments), and using native instead of MH for these 2 corner cases shouldn't be too big of a performance concern.
>
> Okay, in that case it's probably fine - I assume there's also no easy way to ensure in a test that all signature polymorphic methods are covered by these checks?

These checks are 1-1 to the JVMS 2.9.3/JLS 15.12.3, where definitions of signature polymorphic methods reside.

Actually, since you've asked, I checked the usage of `PolymorphicSignature` - it's not used by javac at all! The only usages I can find is in JVMCI tests. And I don't find any test that verify the set of all `PolymorphicSignature` annotated methods is the set of all signature polymorphic methods. (A similar test exists for `CallerSensitive`).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1848752806

From duke at openjdk.org  Tue Nov 19 17:28:55 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 19 Nov 2024 17:28:55 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v17]
In-Reply-To: <rYiFVw3VNx2ZxCLCD6q9xE0R8ZQMyf8KU9legnXaC-g=.d77ab481-09b0-4b77-8642-b5dbbf7f73d5@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <KW-U-91MyntIMaUwjtxY0h21c3ZiDU0MvBZHGHplZe0=.65fcb40d-7f42-4278-acfa-a84377c81757@github.com>
 <zd-vraoffPK17e27kdpujyHNmPP4NFKRcJrzV7nUj9U=.952beef0-84ed-4176-a160-01b631f5a277@github.com>
 <wrIrBVSNEeOc4aMpWPmb_Z8whdxn40geeFn_JUhrl5g=.e2d75a9c-12a9-4409-bdd1-2badb392bdff@github.com>
 <rYiFVw3VNx2ZxCLCD6q9xE0R8ZQMyf8KU9legnXaC-g=.d77ab481-09b0-4b77-8642-b5dbbf7f73d5@github.com>
Message-ID: <XOQ1jBoNl1dxHxXfzFyt69g92vu54C-Gee-wi60_eQA=.a4e76052-dcb7-493c-bb8b-3bba2c1ff2e3@github.com>

On Tue, 19 Nov 2024 09:21:08 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

> While you are at it, it would be useful to add one test for each of the paths in the new algorithm (including the exception cases) in the existing [SquareRootTests](https://github.com/openjdk/jdk/blob/master/test/jdk/java/math/BigDecimal/SquareRootTests.java) This helps to identify future regressions when the code is later modified for any reason.

I will add the path-based tests once the path tree has reached a stable version, in order to avoid changing tests if the path tree changes.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848773886

From jvernee at openjdk.org  Tue Nov 19 17:39:48 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Tue, 19 Nov 2024 17:39:48 GMT
Subject: RFR: 8331735: UpcallLinker::on_exit races with GC when copying
 frame anchor
In-Reply-To: <hi1S3ZzHdg6zZjg72DUYqqmvgWaLWUwGQkxvMtzdOFw=.455120d6-adc9-4216-aa0d-7eac182362a8@github.com>
References: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>
 <hi1S3ZzHdg6zZjg72DUYqqmvgWaLWUwGQkxvMtzdOFw=.455120d6-adc9-4216-aa0d-7eac182362a8@github.com>
Message-ID: <6tN8BgGqulZRILwuuI-y6oX_1l1I6DfYmePj_EzoC4A=.fed13363-9eb0-44a8-a1ce-dce4bd56fe17@github.com>

On Tue, 19 Nov 2024 06:47:17 GMT, David Holmes <dholmes at openjdk.org> wrote:

> I wonder if we can assert we are in a safepoint-safe state when doing so?

I think we can do this. I've prototyped this here: https://github.com/openjdk/jdk/compare/pr/21742...JornVernee:jdk:SafeFrameAnchor+assert

This catches the issue fixed by this patch, and it passes at least tier 1. We'd need something similar in assembly where we touch the frame anchor, is `MacroAssembler::set_last_Java_frame` and `MacroAssembler::reset_last_Java_frame`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21742#issuecomment-2486347485

From naoto at openjdk.org  Tue Nov 19 17:42:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Nov 2024 17:42:07 GMT
Subject: RFR: 8343788: Provide means to alter lib/tzmappings entries on Windows
Message-ID: <z7j5vrQoWKMnE7_RsTMDFcs2XpHkzCw1t9rTBaMM2Kg=.6c2257e5-ccdb-4f04-90e5-22e2341a2678@github.com>

Windows Java runtime has a mapping file /lib/tzmappings which maps Windows time zones to Java's time zones. The file is generated based on CLDR's windowsZones.xml, but in rare occasions, its update is out of sync with Windows updates. This enhancement is to address those discrepancies for the time being (till CLDR/Windows are in sync). This change will also address zone mapping discrepancies in the update releases where CLDR versions stay the same.

-------------

Commit messages:
 - initial commit

Changes: https://git.openjdk.org/jdk/pull/22250/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22250&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8343788
  Stats: 54 lines in 2 files changed: 53 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22250.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22250/head:pull/22250

PR: https://git.openjdk.org/jdk/pull/22250

From prr at openjdk.org  Tue Nov 19 18:01:00 2024
From: prr at openjdk.org (Phil Race)
Date: Tue, 19 Nov 2024 18:01:00 GMT
Subject: RFR: 8342869: Errors related to unused code on Windows after
 8339120 in awt
In-Reply-To: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
References: <GgNU1hfyQrV_U_b04LJ7EtBFVjIoU9gHjSgxhkRzjJ8=.2e8e4e92-036d-415a-988e-6ac791621eb4@github.com>
Message-ID: <esgL0GQFbtCir68nPU3VIkH6ALR-An70UHfi8twf7YQ=.af48e6e1-901d-40bc-86f3-07a63637c5e9@github.com>

On Wed, 23 Oct 2024 05:07:37 GMT, Julian Waters <jwaters at openjdk.org> wrote:

> After 8339120, gcc began catching many different instances of unused code in the Windows specific codebase. Some of these seem to be bugs. I've taken the effort to mark out all the relevant globals and locals that trigger the unused warnings and addressed all of them by commenting out the code as appropriate. I am confident that in many cases this simplistic approach of commenting out code does not fix the underlying issue, and the warning actually found a bug that should be fixed. In these instances, I will be aiming to fix these bugs with help from reviewers, so I recommend anyone reviewing who knows more about the code than I do to see whether there is indeed a bug that needs fixing in a different way than what I did

There's not much I like about this PR. I think it would be better to withdraw it and submit a bug against AWT for people to look at what should really be done about these cases. Which could include "do nothing".

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21655#issuecomment-2486391417

From rgiulietti at openjdk.org  Tue Nov 19 18:49:52 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Nov 2024 18:49:52 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v20]
In-Reply-To: <_fJUaRv1a31e9yfp1cnd1qSfko_CHTgf4f9Tp3-kWTQ=.65808a89-1f55-4af2-9b5f-bfdafd1ad997@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <_fJUaRv1a31e9yfp1cnd1qSfko_CHTgf4f9Tp3-kWTQ=.65808a89-1f55-4af2-9b5f-bfdafd1ad997@github.com>
Message-ID: <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>

On Tue, 19 Nov 2024 14:44:40 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
>> 
>> The main steps of the algorithm are as follows:
>> first argument reduce the value to an integer using the following relations:
>> 
>> x = y * 10 ^ exp
>> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
>> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
>> 
>> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
>> 
>> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.
>
> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Correct remainder checking

src/java.base/share/classes/java/math/BigDecimal.java line 2200:

> 2198:                 // Adjust to requested precision and preferred
> 2199:                 // scale as appropriate.
> 2200:                 result = result.adjustToPreferredScale(preferredScale, mc.precision);

Suggestion:

                return result.adjustToPreferredScale(preferredScale, mc.precision);

The redundant `else` below can then be removed, resulting in less "indented" code.
But the current choice is OK as well if you like it better.

src/java.base/share/classes/java/math/BigDecimal.java line 2253:

> 2251: 
> 2252:                     case UP, CEILING -> {
> 2253:                         BigInteger[] sqrtRem = workingInt.sqrtAndRemainder();

Can't this follow the same logic as for the halfway cases, with just `sqrt()` and a `!workingInt.equals(sqrt.multiply(sqrt))` test? This would increase consistency.
Are there performance reasons to do it as in the current code?

src/java.base/share/classes/java/math/BigDecimal.java line 2260:

> 2258:                     }
> 2259: 
> 2260:                     default -> throw new AssertionError("Unexpected value for RoundingMode: " + mc.roundingMode);

I think `MatchException` might be better suited (with a `null` cause), but I'll crosscheck and let you know tomorrow.

src/java.base/share/classes/java/math/BigDecimal.java line 2274:

> 2272:             }
> 2273:             return result;
> 2274:         } else {

As above, this redundant `else` could be removed and the code below be un-indented a bit. Again, up to your preferences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848870665
PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848871435
PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848871866
PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848872056

From rriggs at openjdk.org  Tue Nov 19 18:53:57 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 18:53:57 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v12]
In-Reply-To: <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
Message-ID: <XMtcgYHCYS6G1g0SeTRNsso2beWj25Fbgp8iyBQP9Kc=.3551e40d-530e-48a5-b936-49c86b8bc017@github.com>

On Tue, 19 Nov 2024 08:09:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Touchups
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - Drop --add-exports from the test
>  - prev is not needed
>  - Do not need -ea -esa in tests, our testing infra adds them already
>  - Add the node cache
>  - Avoid NPE on empty list, add tests, touchups
>  - Reimplement with segmented linked list of arrays
>  - Review feedback: make sure trimming actually works, stylistic changes
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/44fcc8a0...dc55597d

With SM removal, there is a doPrivileged call in Cleaner.java.
Should that be handled separately from this PR?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2486491155

From duke at openjdk.org  Tue Nov 19 18:58:02 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 19 Nov 2024 18:58:02 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v20]
In-Reply-To: <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <_fJUaRv1a31e9yfp1cnd1qSfko_CHTgf4f9Tp3-kWTQ=.65808a89-1f55-4af2-9b5f-bfdafd1ad997@github.com>
 <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>
Message-ID: <0fXmyD-L97EjV2oYPNwIN3KxPwNr90OnoxbLRTtkTV4=.9eff1d84-41da-4611-9e28-e3551a214956@github.com>

On Tue, 19 Nov 2024 18:43:46 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct remainder checking
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2200:
> 
>> 2198:                 // Adjust to requested precision and preferred
>> 2199:                 // scale as appropriate.
>> 2200:                 result = result.adjustToPreferredScale(preferredScale, mc.precision);
> 
> Suggestion:
> 
>                 return result.adjustToPreferredScale(preferredScale, mc.precision);
> 
> The redundant `else` below can then be removed, resulting in less "indented" code.
> But the current choice is OK as well if you like it better.

I've made the current choice for consistency with the old implementation, but indeed I think that using `return` is more handy.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848884543

From bchristi at openjdk.org  Tue Nov 19 18:58:17 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 18:58:17 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs
Message-ID: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>

Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

-------------

Commit messages:
 - Remove SecMgr, etc usage from java.prefs

Changes: https://git.openjdk.org/jdk/pull/22252/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344337
  Stats: 243 lines in 6 files changed: 16 ins; 129 del; 98 mod
  Patch: https://git.openjdk.org/jdk/pull/22252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22252/head:pull/22252

PR: https://git.openjdk.org/jdk/pull/22252

From smarks at openjdk.org  Tue Nov 19 19:01:08 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 19 Nov 2024 19:01:08 GMT
Subject: Integrated: 8344149: Remove usage of Security Manager from java.rmi
In-Reply-To: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
References: <0eC-oz2EUDKd5H4A9WzfPyzc6IC4FCcCl2faVmXnHbY=.5482877d-45f1-4458-baeb-c9993784727d@github.com>
Message-ID: <IqcgOaLQRIgqJqgPUsezg9IHw8v1_5odQ8zlocpA9u8=.0480309f-2f0e-4b44-81fb-4d0569f0044e@github.com>

On Fri, 15 Nov 2024 01:12:34 GMT, Stuart Marks <smarks at openjdk.org> wrote:

> First cut at removal of Security Manager stuff from RMI.
> 
> This covers just about every SM-related case in RMI, except for a bit of package checking in MarshalInputStream. This will be handled separately. It's covered by [JDK-8344329](https://bugs.openjdk.org/browse/JDK-8344329).
> 
> Further simplifications could be done in RuntimeUtil and NewThreadAction. However, those changes started to become somewhat more intrusive than I'd like for this PR, which is focused on removing security-related stuff. EDIT: I've filed [JDK-8344461](https://bugs.openjdk.org/browse/JDK-8344461) to cover this additional cleanup work.

This pull request has now been integrated.

Changeset: 6a5256ec
Author:    Stuart Marks <smarks at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6a5256ec042e16a2157475e86e7859b345a91bd0
Stats:     723 lines in 27 files changed: 7 ins; 550 del; 166 mod

8344149: Remove usage of Security Manager from java.rmi

Reviewed-by: rriggs, kevinw, aefimov

-------------

PR: https://git.openjdk.org/jdk/pull/22129

From duke at openjdk.org  Tue Nov 19 19:06:03 2024
From: duke at openjdk.org (fabioromano1)
Date: Tue, 19 Nov 2024 19:06:03 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v20]
In-Reply-To: <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <_fJUaRv1a31e9yfp1cnd1qSfko_CHTgf4f9Tp3-kWTQ=.65808a89-1f55-4af2-9b5f-bfdafd1ad997@github.com>
 <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>
Message-ID: <48CfTsTXdDNecwYilLleS0vvG0WLs4nOPATKAjH2qeM=.290da8cd-e8de-4965-a6f0-14f457739886@github.com>

On Tue, 19 Nov 2024 18:44:27 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct remainder checking
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2253:
> 
>> 2251: 
>> 2252:                     case UP, CEILING -> {
>> 2253:                         BigInteger[] sqrtRem = workingInt.sqrtAndRemainder();
> 
> Can't this follow the same logic as for the halfway cases, with just `sqrt()` and a `!workingInt.equals(sqrt.multiply(sqrt))` test? This would increase consistency.
> Are there performance reasons to do it as in the current code?

Yes, indeed in this case the remainder is always needed, so invoking `workingInt.sqrtAndRemainder()` is faster than checking `!workingInt.equals(sqrt.multiply(sqrt))`, as it avoids the squaring of `sqrt`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848892890

From dl at openjdk.org  Tue Nov 19 19:08:56 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 19 Nov 2024 19:08:56 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <WaC_aWYoeA2wKEX8FXpHB-rMooYB0U0xM6EnZ6RDAJ4=.bb0d5f3d-75ff-40a1-95df-fb4308c7f128@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
 <WaC_aWYoeA2wKEX8FXpHB-rMooYB0U0xM6EnZ6RDAJ4=.bb0d5f3d-75ff-40a1-95df-fb4308c7f128@github.com>
Message-ID: <Kij8ipHXIwVzCPhG8ebDftNtDpYZB_9e65Arz4DzcQg=.72b3c745-bd1d-4764-8f9b-af476bb491ae@github.com>

On Tue, 19 Nov 2024 16:10:19 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2053:
> 
>> 2051:                     if (((phase = deactivate(w, phase)) & IDLE) != 0)
>> 2052:                         break;
>> 2053:                     src = -1;
> 
> @DougLea So if I understand this correctly, the setting of `src` to -1 is to differ from `j` on the next loop step (since `j` is bound by bitmask to be positive)?

yes. To be little clearer added:
                    src = -1;                            // re-enable propagation

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848898267

From dl at openjdk.org  Tue Nov 19 19:15:48 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 19 Nov 2024 19:15:48 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
 <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
Message-ID: <bD9XwVkdFqAnZhKqcphbDcs26qNS0_9C0JiFB4oISnY=.f20f0d40-765f-488e-9012-2492f4660468@github.com>

On Tue, 19 Nov 2024 16:52:44 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2805:
> 
>> 2803:             }
>> 2804:         }
>> 2805:         return e;
> 
> @DougLea Is there any benefit to using `break` in the loop rather than `return e;` directly?

It's marginal, but the current structure has a single return vs many that could have been done here, leading to simpler flow graph for compiler.. (In some other methods, it's not worth doing.)

> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 4082:
> 
>> 4080:             AccessController.doPrivileged(new PrivilegedAction<>() {
>> 4081:                     public ForkJoinPool run() {
>> 4082:                         return new ForkJoinPool((byte)0); }});
> 
> @AlanBateman Any recommendation as to what is ideal here with SM removed? /cc @DougLea

I  moved this to end so that in next pass with SM removed, the static init will end with just:
common = new ForkJoinPool((byte)0).
(Which will be sure to be done after all the other static init finiahes.)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848915093
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1848921820

From lancea at openjdk.org  Tue Nov 19 19:21:59 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Tue, 19 Nov 2024 19:21:59 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <zNNkQaAhg0Dk1K3GKOIkWFWfz8YMYPdPgPfIGv2JEJE=.0f50efd4-b89d-44df-bb32-90c1d1c74e64@github.com>

On Tue, 19 Nov 2024 18:52:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

Hi Brent,

There looks to be a lot of commented out code that should be removed as part of your PR?

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 33:

> 31: //import java.security.PrivilegedAction;
> 32: //import java.security.PrivilegedExceptionAction;
> 33: import java.security.PrivilegedActionException;

I think you can remove these vs leaving them commented out

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 63:

> 61: //        };
> 62: //        AccessController.doPrivileged(load);
> 63:     }

Looks like there is some clean up here to do of the commented out code...

-------------

Changes requested by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22252#pullrequestreview-2446445645
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1848933440
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1848935376

From aefimov at openjdk.org  Tue Nov 19 19:22:44 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Tue, 19 Nov 2024 19:22:44 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
Message-ID: <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>

> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
> - The following two properties are removed:
>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>     - `com.sun.jndi.rmi.object.trustURLCodebase`
> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
> 
> These changes require a CSR that will be submitted soon.
> 
> ### Testing
> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  clarify factory location usages in NamingManager and jdk.naming.rmi module-info

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22154/files
  - new: https://git.openjdk.org/jdk/pull/22154/files/7b3edb84..e674e1d0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=01-02

  Stats: 6 lines in 2 files changed: 5 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22154/head:pull/22154

PR: https://git.openjdk.org/jdk/pull/22154

From bchristi at openjdk.org  Tue Nov 19 19:23:55 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 19:23:55 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v12]
In-Reply-To: <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
Message-ID: <9yxkqzJsj0vu3AnOpYOymFfjEN5Dw2NbPHFux-n2rrY=.b75e9ae4-dcbc-4753-8d3d-f151febe45d3@github.com>

On Tue, 19 Nov 2024 08:09:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Touchups
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - Drop --add-exports from the test
>  - prev is not needed
>  - Do not need -ea -esa in tests, our testing infra adds them already
>  - Add the node cache
>  - Avoid NPE on empty list, add tests, touchups
>  - Reimplement with segmented linked list of arrays
>  - Review feedback: make sure trimming actually works, stylistic changes
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/7a0b1012...dc55597d

Changes requested by bchristi (Reviewer).

test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 102:

> 100:         Assert.assertTrue(list.isEmpty());
> 101: 
> 102:         Random r = new Random(42);

If a constant random seed is used, the test will always run in the same way, yes?
Also, consider using `jdk.test.lib.RandomFactory`.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22043#pullrequestreview-2446460553
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1848938961

From shade at openjdk.org  Tue Nov 19 19:28:54 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Nov 2024 19:28:54 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v12]
In-Reply-To: <XMtcgYHCYS6G1g0SeTRNsso2beWj25Fbgp8iyBQP9Kc=.3551e40d-530e-48a5-b936-49c86b8bc017@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
 <XMtcgYHCYS6G1g0SeTRNsso2beWj25Fbgp8iyBQP9Kc=.3551e40d-530e-48a5-b936-49c86b8bc017@github.com>
Message-ID: <djTQNfsbfZTja0KThNEaTGZ6EwASyLOu2nLjWf4wBfY=.a45517a8-a600-4c9f-a9a1-753d904e1ad2@github.com>

On Tue, 19 Nov 2024 18:50:36 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> With SM removal, there is a doPrivileged call in Cleaner.java. Should that be handled separately from this PR?

Since this is not related to the problem at hand, I'd prefer to keep it out of this PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2486570633

From smarks at openjdk.org  Tue Nov 19 19:34:01 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 19 Nov 2024 19:34:01 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v7]
In-Reply-To: <3R1OyryqFGZnEHiYAZP3bQkhcaZRNkyZ0DanYU0AmEY=.f9074fd7-e97b-4462-8d17-643ff79f2c70@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <3R1OyryqFGZnEHiYAZP3bQkhcaZRNkyZ0DanYU0AmEY=.f9074fd7-e97b-4462-8d17-643ff79f2c70@github.com>
Message-ID: <8GilY9XS1rrqWnK1Su0V9RlN6TbiNc1oh1xfh_KRWEU=.4efb624d-71ab-4e61-9daf-b41193c2ecc4@github.com>

On Fri, 15 Nov 2024 11:15:28 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this enhancement which proposes to enhance `java.util.zip.Deflater/Inflater` classes to now implement `AutoCloseable`?
>> 
>> The actual work for this was done a few years back when we discussed the proposed approaches and then I raised a RFR. At that time I couldn't take this to completion. The current changes in this PR involve the implementation that was discussed at that time and also have implemented the review suggestions from that time. Here are those previous discussions and reviews:
>> 
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-June/061079.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061177.html
>> https://mail.openjdk.org/pipermail/core-libs-dev/2019-July/061229.html
>> 
>> To summarize those discussions, we had concluded that:
>> - `Deflater` and `Inflater` will implement the `AutoCloseable` interface
>> -  In the `close()` implementation we will invoke the `end()` method (`end()` can be potentially overridden by subclasses).
>> - `close()` will be specified and implemented to be idempotent. Calling `close()` a second time or more will be a no-op.
>> - Calling `end()` and then `close()`, although uncommon, will also support idempotency and that `close()` call will be a no-op.
>> - However, calling `close()` and then `end()` will not guarantee idempotency and depending on the implementing subclass, the `end()` may throw an exception.
>> 
>> New tests have been included as part of these changes and they continue to pass along with existing tests in tier1, tier2 and tier3. When I had originally added these new tests, I hadn't used junit. I can convert them to junit if that's preferable.
>> 
>> I'll file a CSR shortly.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   missed a few methods for specifying IllegalStateException

src/java.base/share/classes/java/util/zip/Deflater.java line 892:

> 890:      * and discards any unprocessed input.
> 891:      * <p>
> 892:      * If this method is invoked multiple times, the subsequent calls are treated as a no-op.

I would say,

> If this method is invoked multiple times, the second and subsequent calls do nothing.

src/java.base/share/classes/java/util/zip/Inflater.java line 65:

> 63:  * usage with try-with-resources, this class implements {@link AutoCloseable}. The
> 64:  * {@link #close()} method of this class calls {@code end()} to clean up its
> 65:  * resources. Subclasses are responsible for the cleanup of resources

Once we've agreed on the arrangement in the Deflater class, the corresponding changes should be made to Inflater, mutatis mutandis.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1848948353
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1848952003

From smarks at openjdk.org  Tue Nov 19 19:34:00 2024
From: smarks at openjdk.org (Stuart Marks)
Date: Tue, 19 Nov 2024 19:34:00 GMT
Subject: RFR: 8225763: Inflater and Deflater should implement AutoCloseable
 [v5]
In-Reply-To: <AGhgzPj3GaxzVBQtnV0Iv1SJxYyF4Oa6PAaJ-3-lMv4=.5888701e-a691-4923-85cd-6330ad167eeb@github.com>
References: <YW615Ce87stwKdmk4c-SeGfYNFlDjxjci8yvubhWQi4=.864410ee-d04b-45c4-bfdc-3db7723844bd@github.com>
 <WDw6WO-9RwCsJiqg-318U_v2Dd4omv0-7mHXxWp_cNw=.dadeb973-9649-419d-a322-e9c5ec092dbe@github.com>
 <TeT9OHflJUVSo6Ah_358k4w9kU3Vy9A7cygTwLDPGdQ=.802aa986-30b8-421c-b5fc-91c32cbefb62@github.com>
 <qfiRQjaGw8NACPQOqSDoawjsdxOvALtPwKFU1sZP1sk=.016de9c1-3a80-4528-8f33-557b6d743f89@github.com>
 <AGhgzPj3GaxzVBQtnV0Iv1SJxYyF4Oa6PAaJ-3-lMv4=.5888701e-a691-4923-85cd-6330ad167eeb@github.com>
Message-ID: <zKHXmBLeXoSnC81b2DEBbPO1MwVrvBDbygT9e4SwL5Q=.d6b495ae-bccc-4893-ad2d-64d320379600@github.com>

On Fri, 15 Nov 2024 12:17:47 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Stuart in one of his review comments in this PR had noted that:
>> 
>>> I think the class specification needs to be clearer about the positioning of end() and close(). The end() method has done the real work of "closing" since the classes were introduced. We're retrofitting them to to have a close() method that's essentially just a synonym for end(), and it's still perfectly legal for clients and subclasses to call end() instead of close(). I think we need to say that close() is present mainly to support AutoCloseable and try-with-resources.
>> 
>> The current wording of that class level javadoc is my attempt to implement that suggestion. Do you think we can word it differently and yet convey the purpose of close()?
>
> Hi Jai,
> 
> I am not convinced we need to call this out specifically at the class level given  the classes implements AutoClosable and close indicates it calls end.  We will also  want to add a Release Note which can help further clarify this
> 
> Now that being said, what I would suggest instead is a simple code example in the class header which using try-with-resources would be more effective/helpful.

Deflater and Inflater are unusual in that their resources are released by calling `end()` instead of `close()`. So I think some mention of the situation is in order.

The first responsibility is for normative text (before the example) to impose a requirement on applications that they call `end()` when they are finished. Something like:

> To release resources used by this Deflater, applications must call the `end()` method.

This is probably a good place to add a statement about, after `end()` has been called, all subsequent operations will throw IllegalStateException.

I don't think we need to include the text about subclasses. I tried drafting something but it seemed clumsy and unnecessary. But I'm open to other opinions about whether such text should be included.

At this point I think it's ok to introduce an `@apiNote` that mentions that a `close()` method simply calls `end()`, and that this class implements `AutoCloseable` in order to facilitate use with try-with-resources. And finally include the big example snippet, which is modified to use try-with-resources.

In addition, wording below about finalization and Cleaner should be removed. The requirement to call `end()` is sufficient, and I don't think there's anything special about this class that merits a discussion about GC-driven cleanup.

>> Hello Lance, you are right - I forgot to do that when I changed it to throw IllegalStateException from the previous NullPointerException. I've now updated the PR to document this on individual methods in the Inflater/Deflater which throw this exception.
>
> Thank you.  It was an oversight that the original javadoc did not call out the NPE, but now is our chance to get it right with a more reasonable exception.

Overall I agree with defining that IllegalStateException is thrown after the Deflater is closed, and adding documentation of this to all the methods that throw it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1848945718
PR Review Comment: https://git.openjdk.org/jdk/pull/19675#discussion_r1848949694

From mullan at openjdk.org  Tue Nov 19 19:35:57 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 19 Nov 2024 19:35:57 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <2YwIJb1kVEr1_HzmuxxA0psjKlNwq4QbwG2nO7SkTvE=.b1681a41-204e-44a9-8a77-b8195ffd0dfa@github.com>

On Tue, 19 Nov 2024 18:52:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

A few classes need updated copyrights.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22252#issuecomment-2486583493

From shade at openjdk.org  Tue Nov 19 19:35:59 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Nov 2024 19:35:59 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v12]
In-Reply-To: <djTQNfsbfZTja0KThNEaTGZ6EwASyLOu2nLjWf4wBfY=.a45517a8-a600-4c9f-a9a1-753d904e1ad2@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
 <XMtcgYHCYS6G1g0SeTRNsso2beWj25Fbgp8iyBQP9Kc=.3551e40d-530e-48a5-b936-49c86b8bc017@github.com>
 <djTQNfsbfZTja0KThNEaTGZ6EwASyLOu2nLjWf4wBfY=.a45517a8-a600-4c9f-a9a1-753d904e1ad2@github.com>
Message-ID: <J1Df0E3qVxF3Cfl8kOuf4Z69h3YK3zJMwiBzBI2rNxs=.334f7a12-51e6-48c4-b607-3906ba7efe87@github.com>

On Tue, 19 Nov 2024 19:26:03 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

> > With SM removal, there is a doPrivileged call in Cleaner.java. Should that be handled separately from this PR?
> 
> Since this is not related to the problem at hand, I'd prefer to keep it out of this PR.

Actually, I wonder if you mean [`Cleaner.java`](https://github.com/openjdk/jdk/blob/3328b4ecf225f95edfce6ab848dcfb62ddc1aaff/src/java.base/share/classes/jdk/internal/ref/Cleaner.java#L146-L153) that is not even affected by this patch? It is completely unrelated, and it would probably be gone with [JDK-8344332](https://bugs.openjdk.org/browse/JDK-8344332).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2486583047

From mullan at openjdk.org  Tue Nov 19 19:43:48 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 19 Nov 2024 19:43:48 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <gXQ0aSueBn6DnNs93bVO7VoilJdw_67V0-67qeg2gUg=.a9865a5a-e5ea-4331-aa55-23a9ba1b8174@github.com>

On Tue, 19 Nov 2024 18:52:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

src/java.prefs/share/classes/java/util/prefs/AbstractPreferences.java line 1059:

> 1057:      *         preference tree.
> 1058:      */
> 1059:     @SuppressWarnings("removal")

Can remove this line.

src/java.prefs/share/classes/java/util/prefs/Preferences.java line 220:

> 218:     private static final PreferencesFactory factory = factory();
> 219: 
> 220:     @SuppressWarnings("removal")

I think you can remove this line.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1848955427
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1848957788

From rriggs at openjdk.org  Tue Nov 19 19:47:46 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 19:47:46 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <I6YME9Mh6q8ACE4k6bxwhS0mDv0FDG3rpPiOW5eUvIk=.6279e98a-f374-43a5-bc96-804396b08b68@github.com>

On Tue, 19 Nov 2024 18:52:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

src/java.prefs/share/classes/java/util/prefs/Preferences.java line 248:

> 246:             }
> 247:         }
> 248:         return factory1();

No need to make factory1 a separate method, merge into factory.

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 766:

> 764: 
> 765:     protected void syncSpi() throws BackingStoreException {
> 766:         syncSpiPrivileged();

Inline syncSpiPrivileged(), it doesn't need to be separate and the name "privileged" is misleading

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1848958580
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1848966359

From rgiulietti at openjdk.org  Tue Nov 19 19:51:52 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Tue, 19 Nov 2024 19:51:52 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v20]
In-Reply-To: <48CfTsTXdDNecwYilLleS0vvG0WLs4nOPATKAjH2qeM=.290da8cd-e8de-4965-a6f0-14f457739886@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <_fJUaRv1a31e9yfp1cnd1qSfko_CHTgf4f9Tp3-kWTQ=.65808a89-1f55-4af2-9b5f-bfdafd1ad997@github.com>
 <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>
 <48CfTsTXdDNecwYilLleS0vvG0WLs4nOPATKAjH2qeM=.290da8cd-e8de-4965-a6f0-14f457739886@github.com>
Message-ID: <4QHi-nusUqZWKHbzY1_rCJz5QR27jnUEMdZd07q0daE=.cafee1a1-efb9-47b5-a6cf-083c06198b2e@github.com>

On Tue, 19 Nov 2024 19:02:09 GMT, fabioromano1 <duke at openjdk.org> wrote:

>> src/java.base/share/classes/java/math/BigDecimal.java line 2253:
>> 
>>> 2251: 
>>> 2252:                     case UP, CEILING -> {
>>> 2253:                         BigInteger[] sqrtRem = workingInt.sqrtAndRemainder();
>> 
>> Can't this follow the same logic as for the halfway cases, with just `sqrt()` and a `!workingInt.equals(sqrt.multiply(sqrt))` test? This would increase consistency.
>> Are there performance reasons to do it as in the current code?
>
> Yes, indeed in this case the remainder is always needed, so invoking `workingInt.sqrtAndRemainder()` is faster than checking `!workingInt.equals(sqrt.multiply(sqrt))`, as it avoids the squaring of `sqrt`.

I see.

I have no other comments on the code. I look forward for the tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1848971914

From shade at openjdk.org  Tue Nov 19 19:53:45 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Nov 2024 19:53:45 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v13]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <pXpDzNzwVroE1zDlS0-B6wyaKjbVxbAm4nRZbjgTFNU=.7279b591-6d30-4243-be70-33dc5d1ca778@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Use RandomFactory in test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/dc55597d..8b53bc83

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=12
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=11-12

  Stats: 6 lines in 1 file changed: 4 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From rriggs at openjdk.org  Tue Nov 19 19:53:48 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 19:53:48 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v12]
In-Reply-To: <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
Message-ID: <jnrVJBekI0pQRZAQbHDGRPfPOCBHZrCDTO1xREJq-Lg=.a2507295-b221-4e88-9108-1dfa3d64e502@github.com>

On Tue, 19 Nov 2024 08:09:38 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
> 
>  - Touchups
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - Drop --add-exports from the test
>  - prev is not needed
>  - Do not need -ea -esa in tests, our testing infra adds them already
>  - Add the node cache
>  - Avoid NPE on empty list, add tests, touchups
>  - Reimplement with segmented linked list of arrays
>  - Review feedback: make sure trimming actually works, stylistic changes
>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c5e55209...dc55597d

Right, I meant jdk.internal.ref.Cleaner.
So Yes, it will be gone after 8344332; and it can remain as is until that's implemented.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22043#issuecomment-2486613357

From shade at openjdk.org  Tue Nov 19 19:53:49 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Tue, 19 Nov 2024 19:53:49 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v12]
In-Reply-To: <9yxkqzJsj0vu3AnOpYOymFfjEN5Dw2NbPHFux-n2rrY=.b75e9ae4-dcbc-4753-8d3d-f151febe45d3@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <mC51cRgTHl_-vD4CYSM13L41NobyJG73q6Px2TlLSQI=.c72d2e1f-9a83-42af-bdc4-0434023c1627@github.com>
 <9yxkqzJsj0vu3AnOpYOymFfjEN5Dw2NbPHFux-n2rrY=.b75e9ae4-dcbc-4753-8d3d-f151febe45d3@github.com>
Message-ID: <ADykQR_6tjd7esZ_FmVRfuy2MtkkBdJjMAVji3qY8zA=.ccbdd9c4-ff0e-4a15-9e19-3229cd8f93e0@github.com>

On Tue, 19 Nov 2024 19:19:51 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 13 additional commits since the last revision:
>> 
>>  - Touchups
>>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>>  - Drop --add-exports from the test
>>  - prev is not needed
>>  - Do not need -ea -esa in tests, our testing infra adds them already
>>  - Add the node cache
>>  - Avoid NPE on empty list, add tests, touchups
>>  - Reimplement with segmented linked list of arrays
>>  - Review feedback: make sure trimming actually works, stylistic changes
>>  - Merge branch 'master' into JDK-8343704-cleaner-gc
>>  - ... and 3 more: https://git.openjdk.org/jdk/compare/c5e55209...dc55597d
>
> test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 102:
> 
>> 100:         Assert.assertTrue(list.isEmpty());
>> 101: 
>> 102:         Random r = new Random(42);
> 
> If a constant random seed is used, the test will always run in the same way, yes?
> Also, consider using `jdk.test.lib.RandomFactory`.

Migrated to `RandomFactory` now.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1848974469

From jbhateja at openjdk.org  Tue Nov 19 19:57:09 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 19 Nov 2024 19:57:09 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
Message-ID: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>

Hi All,

This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)

Following is the summary of changes included with this patch:-

1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
      -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
6. Auto-vectorization of newly supported scalar operations.
7. X86 and AARCH64 backend implementation for all supported intrinsics.
9. Functional and Performance validation tests.

**Missing Pieces:-**
**-  AARCH64 Backend.**

Kindly review and share your feedback.

Best Regards,
Jatin

-------------

Commit messages:
 - Code styling changes
 - Review comments resoultion.
 - Jcheck and build fixes
 - New halffloat type 'TypeH' and associated changes
 - Merge branch 'master' of http://github.com/openjdk/jdk into float16_support
 - Jcheck cleanup
 - Review comments and tests cleanup.
 - Annotating Float16 as a ValueBased class
 - Merge branch 'master' of http://github.com/openjdk/jdk into float16_support
 - Merge branch 'master' of http://github.com/openjdk/jdk into float16_support
 - ... and 6 more: https://git.openjdk.org/jdk/compare/2c509a15...132878ba

Changes: https://git.openjdk.org/jdk/pull/21490/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21490&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8342103
  Stats: 3055 lines in 58 files changed: 2974 ins; 0 del; 81 mod
  Patch: https://git.openjdk.org/jdk/pull/21490.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21490/head:pull/21490

PR: https://git.openjdk.org/jdk/pull/21490

From bkilambi at openjdk.org  Tue Nov 19 19:57:13 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 19 Nov 2024 19:57:13 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <jFmLUpO_eNeiY3rvLWgMvsdtre2VAv7JeqWSdUGLSGw=.b8327876-65e9-41fa-925b-6eaa161032a6@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Can we add the JMH micro benchmark that you added recently for FP16 as well ? or has it intentionally not been included?

Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR?

src/hotspot/share/opto/addnode.hpp line 445:

> 443:   MinHFNode(Node* in1, Node* in2) : MaxNode(in1, in2) {}
> 444:   virtual int Opcode() const;
> 445:   virtual const Type *add_ring(const Type*, const Type*) const;

`Type* ` ? to align with the style used in the constructor.

src/hotspot/share/opto/divnode.cpp line 752:

> 750: //=============================================================================
> 751: //------------------------------Value------------------------------------------
> 752: // An DivFNode divides its inputs.  The third input is a Control input, used to

DivHFNode?

src/hotspot/share/opto/divnode.cpp line 775:

> 773:   }
> 774: 
> 775:   if( t2 == TypeH::ONE )

should if condition be styled as - `if (<expression not beginning/ending with spaces>)` ? or is this to align with already existing float routines?

src/hotspot/share/opto/mulnode.cpp line 558:

> 556: }
> 557: 
> 558: // Compute the product type of two double ranges into this node.

of two *half-float* ranges?

src/hotspot/share/opto/node.cpp line 1600:

> 1598: 
> 1599: // Get a half float constant from a ConstNode.
> 1600: // Returns the constant if it is a float ConstNode

half float ConstNode?

src/hotspot/share/opto/type.hpp line 530:

> 528: };
> 529: 
> 530: // Class of Float-Constant Types.

Class of Half-float constant Types?

test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 122:

> 120:     public static final String VECTOR_SIZE_64  = VECTOR_SIZE + "64";
> 121: 
> 122:     private static final String TYPE_BYTE   = "byte";

Hi Jatin, why have these changes been made? The PrintIdeal output still prints the vector size of the node in this format - `#vectord<S,4>`. This test - `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java` was failing due to this mismatch ..

test/jdk/java/lang/Float/FP16ReductionOperations.java line 25:

> 23: 
> 24: /*
> 25:  * @test

Hi Jatin, is there any reason why these have been kept under the `Float` folder and not a separate `Float16` folder?

test/jdk/jdk/incubator/vector/ScalarFloat16OperationsTest.java line 334:

> 332: 
> 333:     @Test(dataProvider = "ternaryOpProvider")
> 334:     public static void minTest(Object input1, Object input2, Object input3) {

`fmaTest` ?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2411381410
PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2411607884
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848152453
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848128281
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848135401
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848112186
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848195342
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847971311
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1803209988
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1802767337
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848388981

From psandoz at openjdk.org  Tue Nov 19 19:57:14 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <O41_XxKb7IsELYD9OKghhEc5HMmM51CgLHvKgtsDyAs=.6470340f-009b-412d-9b6e-aa11c399a631@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

We should move the `Float16` class to `jdk.incubator.vector` and relevant intrinsic stuff to `jdk.internal.vm.vector`, and we don't need the changes to `BigDecimal` and `BigInteger`.

make/modules/jdk.incubator.vector/Java.gmk line 30:

> 28: DOCLINT += -Xdoclint:all/protected
> 29: 
> 30: JAVAC_FLAGS += --add-exports=java.base/jdk.internal=jdk.incubator.vector

Please remove this change.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2411758902
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1845208651

From darcy at openjdk.org  Tue Nov 19 19:57:14 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <O41_XxKb7IsELYD9OKghhEc5HMmM51CgLHvKgtsDyAs=.6470340f-009b-412d-9b6e-aa11c399a631@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <O41_XxKb7IsELYD9OKghhEc5HMmM51CgLHvKgtsDyAs=.6470340f-009b-412d-9b6e-aa11c399a631@github.com>
Message-ID: <GucrtB1jufeBPDnGiCLfTWTUVdS-1nnSn1TGZBqLCfw=.e61dacc4-bc57-4148-bbbf-c0def4a1f405@github.com>

On Mon, 14 Oct 2024 16:42:24 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> We should move the `Float16` class to `jdk.incubator.vector` and relevant intrinsic stuff to `jdk.internal.vm.vector`, and we don't need the changes to `BigDecimal` and `BigInteger`.

To expand on that point, a few weeks back I took a look at what porting Float16 from java.lang in the lworld+fp16 branch of Valhalla to the jdk.incubator.vector package in JDK 24 would look like: the result were favorable and the diffs are attached to JDK-8341260.

Before the work in this PR proceeds, I think the java.lang -> jdk.incubator.vector move of Float16 should occur first. This will allow leaner reviews and better API separation. I can get an updated PR of the move prepared within the next few days.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2420616927

From psandoz at openjdk.org  Tue Nov 19 19:57:14 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <GucrtB1jufeBPDnGiCLfTWTUVdS-1nnSn1TGZBqLCfw=.e61dacc4-bc57-4148-bbbf-c0def4a1f405@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <O41_XxKb7IsELYD9OKghhEc5HMmM51CgLHvKgtsDyAs=.6470340f-009b-412d-9b6e-aa11c399a631@github.com>
 <GucrtB1jufeBPDnGiCLfTWTUVdS-1nnSn1TGZBqLCfw=.e61dacc4-bc57-4148-bbbf-c0def4a1f405@github.com>
Message-ID: <Xuzoos9ns1Ane4ZJhvMpjDgIGn-iHJCuxFNmDZVe1B0=.69796943-4edd-45dc-a861-d3297117d9c8@github.com>

On Thu, 17 Oct 2024 21:33:03 GMT, Joe Darcy <darcy at openjdk.org> wrote:

> 
> Before the work in this PR proceeds, I think the java.lang -> jdk.incubator.vector move of Float16 should occur first. This will allow leaner reviews and better API separation. I can get an updated PR of the move prepared within the next few days.

Good point, we should separate the Java changes from the intrinsic + HotSpot changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2420632074

From darcy at openjdk.org  Tue Nov 19 19:57:14 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <Xuzoos9ns1Ane4ZJhvMpjDgIGn-iHJCuxFNmDZVe1B0=.69796943-4edd-45dc-a861-d3297117d9c8@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <O41_XxKb7IsELYD9OKghhEc5HMmM51CgLHvKgtsDyAs=.6470340f-009b-412d-9b6e-aa11c399a631@github.com>
 <GucrtB1jufeBPDnGiCLfTWTUVdS-1nnSn1TGZBqLCfw=.e61dacc4-bc57-4148-bbbf-c0def4a1f405@github.com>
 <Xuzoos9ns1Ane4ZJhvMpjDgIGn-iHJCuxFNmDZVe1B0=.69796943-4edd-45dc-a861-d3297117d9c8@github.com>
Message-ID: <K6SSvnZf6rnpelz1n_Ihc7dq-Eb-z_VeB0i5h278P_0=.d1ac8762-e250-4dfb-a9a4-f08500d4a9ff@github.com>

On Thu, 17 Oct 2024 21:35:40 GMT, Paul Sandoz <psandoz at openjdk.org> wrote:

> > Before the work in this PR proceeds, I think the java.lang -> jdk.incubator.vector move of Float16 should occur first. This will allow leaner reviews and better API separation. I can get an updated PR of the move prepared within the next few days.
> 
> Good point, we should separate the Java changes from the intrinsic + HotSpot changes.

PS Along those lines, see

https://github.com/openjdk/jdk/pull/21574

for a non-intrinsified port of Float16 to the vector API.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2420926866

From jrose at openjdk.org  Tue Nov 19 19:57:14 2024
From: jrose at openjdk.org (John R Rose)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <MAAsZqxOPWjFTpNt-fTjEsQYP7NSbN8xvLD01N4cmzY=.1e1d46f6-7e30-4324-aea2-88237f016f4a@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

As I noted on Joe's PR, I like the fact that the intrinsics are decoupled from the box class.

I'm now wondering if there is another simplification possible (as I claimed to Joe!) which is to reduce the number of intrinsics, ideally down to conversions (to and from HF).

For example, `sqrt_float16` is an intrinsic, but I think it could be just an invisible IR node.  After inlining the Java definition, you start with an IR graph that mentions `sqrtD` and is surrounded by conversion nodes.   Then you refactor the IR graph to use `sqrt_float16` directly, presumably with fewer conversions (and/or reinterprets).

Same argument for max, min, add, mul, etc.

I'm not saying the current PR is wrong, but I would like to know if it could be simplified, either now or later.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2424373685

From jbhateja at openjdk.org  Tue Nov 19 19:57:14 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <cBY8NJhZg8jJ-XLiwathyq4jP_uaaQdvcm5eLexX2UI=.c9f84c00-107e-4250-8d4d-89c38c34e0df@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Extending on John's thoughts. 
![image](https://github.com/user-attachments/assets/c795e79f-a857-4991-9b8a-c36d8525ba73)

![image](https://github.com/user-attachments/assets/264eeeea-86a0-43ed-a365-88b91e85d9cc)

There are two possibilities of a pattern match here, one rooted at node **A** and other at **B**

With pattern match rooted at **A**,  we will need to inject additional ConvHF2F after replacing AddF with AddHF to preserve the type semantics of IR graph,  [significand bit preservation constraints](https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Float.java#L1103) for NaN value imposed by Float.float16ToFloat API  makes the idealization toward the end infeasible, thereby reducing the operating vector size for FP16 operation to half of what can be possible, as depicted by following Ideal graph fragment. 

![image](https://github.com/user-attachments/assets/0094e613-2c11-40db-b2bb-84ddf6b251f2)

Thus only feasible match is the one rooted at node **B** 
 
![image](https://github.com/user-attachments/assets/22576617-9533-40e2-94f0-dd6048e295dd)


Please consider Java side implimentation of Float16.sqrt

Float16 sqrt(Float16 radicand) {
        return valueOf(Math.sqrt(radicand.doubleValue()));
}


Here, radicand is first upcasted to doubelValue, following 2P+2 rule of IEEE 754,  square root computed at double precision is not subjected to double rounding penalty when final results is down casted to Float16 value.

Following is  the C2 IR for above Java implementation.


 T0 = Param0 (TypeInt::SHORT)

 T1 = CastHF2F T0 
 T2 = CastF2D   T1
 T3 = SqrtD T2

 T4 = ConvD2F T3
 T5 = CastF2HF T4


To replace SqrtD with SqrtHF,  we need following IR modifications. 


 T0 = Param0 (TypeInt::SHORT)
 // Replacing IR T1-T3  in original fragment with following IR T1-T6.  
 T1 = ReinterpretS2HF T0
 T3 = SqrtHF T1
 T4 = ReinterpretHF2S T3
 T5 = ConvHF2F  T4
 T6 = ConvF2D T5
 
T7 = ConvD2F T6
T5 = CastF2HF T4

  
Simplified IR after applying Identity rules ,  


 T0 = Param0 (TypeInt::SHORT)
 // Replacing IR T1-T3  in original fragment with following IR T1-T6.  
 T1 = ReinterpretS2HF T0
 T3 = SqrtHF T1
 T4 = ReinterpretHF2S T3

  
While above transformation are valid replacements for current intrinsic approach which uses explicit entry points in newly defined Float16Math helper class, they deviate from implementation of several j.l intrinsified methods which could be replaced by pattern matches e.g. 
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2022
https://github.com/openjdk/jdk/blob/master/src/java.base/share/classes/java/lang/Math.java#L2116

I think we need to carefully pick pattern match over intrinsification if former handles more general cases.

If our intention is to capture various Float16 operation patterns in user's code which does not directly uses Float16 API then pattern matching looks appealing, but APIs like SQRT and FMA are very carefully drafted keeping in view rounding impact, and such patterns will be hard to find, thus it should be ok to take intrinsic route for them, simpler cases like add / sub / mul /div / max / min can be handled through a pattern matching approach.

There are also some issues around VM symbol creations for intrinsic entries defined in non-java.base modules which did not surface with then Float16 and Float16Math were part of java.base module.

For this PR taking hybrid approach comprising of both pattern match and intensification looks reasonable to me.

Please let me know if you have any comments.

Some FAQs on the newly added ideal type for half-float IR nodes:-

Q. Why do we not use existing TypeInt::SHORT instead of creating a new TypeH type?
A. Newly defined half float type named TypeH is special as its basictype is T_SHORT while its ideal type is  RegF. Thus, the C2 type system views its associated IR node as a 16-bit short value while the register allocator assigns it a floating point register.

Q. Problem with ConF?
A. During Auto-Vectorization, ConF replication constrains the operational vector lane count to half of what can otherwise be used for regular Float16 operation i.e. only 16 floats can be accommodated into a 512-bit vector thereby limiting the lane count of vectors in its use-def chain, one possible way to address it is through a kludge in auto-vectorizer to cast them to a 16 bits constant by analyzing its context. Newly defined Float16 constant nodes 'ConH' are inherently 16-bit encoded IEEE 754 FP16 values and can be efficiently packed to leverage full target vector width.

All Float16 IR nodes now carry newly defined Type::HALF_FLOAT type instead of Type::FLOAT, thus we no longer need special handling in auto-vectorizer to prune their container type to short.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2425873278
PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2482867818

From jbhateja at openjdk.org  Tue Nov 19 19:57:14 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <jFmLUpO_eNeiY3rvLWgMvsdtre2VAv7JeqWSdUGLSGw=.b8327876-65e9-41fa-925b-6eaa161032a6@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <jFmLUpO_eNeiY3rvLWgMvsdtre2VAv7JeqWSdUGLSGw=.b8327876-65e9-41fa-925b-6eaa161032a6@github.com>
Message-ID: <mnM_p0Pdz85-rXhlCh7hH1-_goMKjmc2tVeV1GuZGoM=.e3fa6359-c710-4866-a3ab-c27087a9d0fd@github.com>

On Mon, 14 Oct 2024 15:32:41 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR?

Hi @Bhavana-Kilambi ,
I am in process of refining existing patch, tests and benchmark, will update the PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2436821263

From darcy at openjdk.org  Tue Nov 19 19:57:14 2024
From: darcy at openjdk.org (Joe Darcy)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <s8JeVhT2kelJ0ViWuOy6icLHhM49S8ZhFcLOAAremig=.f736e356-3f4d-465d-aead-327f6ef3173d@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

FYI, https://github.com/openjdk/jdk/pull/21574 has been pushed, adding Float16 to the incubating vector package.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2475035058

From bkilambi at openjdk.org  Tue Nov 19 19:57:14 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <mnM_p0Pdz85-rXhlCh7hH1-_goMKjmc2tVeV1GuZGoM=.e3fa6359-c710-4866-a3ab-c27087a9d0fd@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <jFmLUpO_eNeiY3rvLWgMvsdtre2VAv7JeqWSdUGLSGw=.b8327876-65e9-41fa-925b-6eaa161032a6@github.com>
 <mnM_p0Pdz85-rXhlCh7hH1-_goMKjmc2tVeV1GuZGoM=.e3fa6359-c710-4866-a3ab-c27087a9d0fd@github.com>
Message-ID: <RrD6EPSQRv9N_mNasJan4TK9EIwsjHPwhufazUVitvE=.e15cecd3-debe-42dc-8b6b-100b30fe19cc@github.com>

On Fri, 25 Oct 2024 04:46:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR?
>
>> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR?
> 
> Hi @Bhavana-Kilambi ,
> I am in process of refining existing patch, tests and benchmark, will update the PR.

Hi @jatin-bhateja , could you also please merge my patch which adds aarch64 backend for these operations here - https://github.com/jatin-bhateja/jdk/pull/6
If you feel there needs to be any changes made before you'd like to merge it, please do let me know and I'll do it. Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2476695747

From psandoz at openjdk.org  Tue Nov 19 19:57:14 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Tue, 19 Nov 2024 19:57:14 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <mnM_p0Pdz85-rXhlCh7hH1-_goMKjmc2tVeV1GuZGoM=.e3fa6359-c710-4866-a3ab-c27087a9d0fd@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <jFmLUpO_eNeiY3rvLWgMvsdtre2VAv7JeqWSdUGLSGw=.b8327876-65e9-41fa-925b-6eaa161032a6@github.com>
 <mnM_p0Pdz85-rXhlCh7hH1-_goMKjmc2tVeV1GuZGoM=.e3fa6359-c710-4866-a3ab-c27087a9d0fd@github.com>
Message-ID: <oeag_N8gZsXqnMFw_POIx6-089lNjlQoCMe8uvqYZFU=.50786861-939f-40cd-8295-4c65854065d1@github.com>

On Fri, 25 Oct 2024 04:46:52 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR?
>
>> Hi Jatin, could you also include the idealization tests here - test/hotspot/jtreg/compiler/c2/irTests/MulHFNodeIdealizationTests.java and ConvF2HFIdealizationTests.java in this PR?
> 
> Hi @Bhavana-Kilambi ,
> I am in process of refining existing patch, tests and benchmark, will update the PR.

@jatin-bhateja i commented directly on code in the commit entitled "Annotating Float16 as a ValueBased class" but i don't see it. This is not the right way to it, see my [comment](https://github.com/openjdk/jdk/pull/21574#discussion_r1841020576) related to this on Joe's FLoat16 PR. We should address it as a separate PR for ease of review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2476891427

From jbhateja at openjdk.org  Tue Nov 19 19:57:19 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 19 Nov 2024 19:57:19 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <bu_f3Jh-bje2KYXVQS-c9SYHtTMSzoXyXObYlr-ueDw=.340ed4f8-baf9-4caf-8c85-7cbb3e751471@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <bu_f3Jh-bje2KYXVQS-c9SYHtTMSzoXyXObYlr-ueDw=.340ed4f8-baf9-4caf-8c85-7cbb3e751471@github.com>
Message-ID: <CrVDItGL-GfJlu2dxNg_hEhMooMCSJOjG8xXLaBWyrI=.60c48d22-20aa-4e0e-8c50-0f51678090dd@github.com>

On Mon, 18 Nov 2024 23:11:20 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 6. Auto-vectorization of newly supported scalar operations.
>> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
>> 9. Functional and Performance validation tests.
>> 
>> **Missing Pieces:-**
>> **-  AARCH64 Backend.**
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3974:
> 
>> 3972:   generate_libm_stubs();
>> 3973: 
>> 3974:   StubRoutines::_fmod = generate_libmFmod(); // from stubGenerator_x86_64_fmod.cpp
> 
> Good to retain the is_intrinsic_available checks.

I reinstantiated it, it was an artifact of my commit.

> src/hotspot/cpu/x86/x86.ad line 4518:
> 
>> 4516: #ifdef _LP64
>> 4517: instruct ReplS_imm(vec dst, immH con, rRegI rtmp) %{
>> 4518:   predicate(VM_Version::supports_avx512_fp16() && Matcher::vector_element_basic_type(n) == T_SHORT);
> 
> I have a question about the predicate for ReplS_imm. What happens if the predicate is false? There doesn't seem to be any other instruct rule to cover that situation. Also I don't see any check in match rule supported on Replicate node.

We only create Half Float constants (ConH) if the target supports FP16 ISA. 
These constants are generated by Value transforms associated with FP16-specific IR, whose creation is guarded by target-specific match rule supported checks.

> src/hotspot/cpu/x86/x86.ad line 10964:
> 
>> 10962:   match(Set dst (SubVHF src1 src2));
>> 10963:   format %{ "evbinopfp16_reg $dst, $src1, $src2" %}
>> 10964:   ins_cost(450);
> 
> Why ins_cost 450 here for reg version and 150 for mem version of binOps?  Whereas sqrt above has 150 cost for both reg and mem version. Good to be consistent.

Cost does not play much role here, removed it for consistency, matching algorithm is a BURS style two pass algorithm, binary state tree construction is done during a bottom-up walk of  expressions, each state captures the cost associated with different reductions, actual selection is done through top down walk of the state tree, it is during this stage we pick the reduction with minimum cost from the set of reductions generating same kinds of result operand, once selected, matcher then follows the low-cost path of the state tree, associating cost guide the selector in choosing from the set of active reducitions. in general it's advisable to assign lower cost to memory variant patterns on CISC targets since this way we can save emitting explicit load.

> src/hotspot/cpu/x86/x86.ad line 11015:
> 
>> 11013:   ins_encode %{
>> 11014:     int vlen_enc = vector_length_encoding(this);
>> 11015:     __ evfmadd132ph($dst$$XMMRegister, $src2$$XMMRegister, $src1$$XMMRegister, vlen_enc);
> 
> Wondering if for auto vectorization the natural fma form is dst = dst + src1 * src2 i.e.
>      match(Set dst (FmaVHF dst (Binary src1 src2)));
> which then leads to fmadd231.

ISA supports multiple flavors, the current scheme is in line with the wiring of inputs done before matching.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847906271
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847906153
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847907028
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847906530

From sviswanathan at openjdk.org  Tue Nov 19 19:57:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Nov 2024 19:57:19 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <bu_f3Jh-bje2KYXVQS-c9SYHtTMSzoXyXObYlr-ueDw=.340ed4f8-baf9-4caf-8c85-7cbb3e751471@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

src/hotspot/cpu/x86/assembler_x86.cpp line 3481:

> 3479: void Assembler::vmovw(XMMRegister dst, Register src) {
> 3480:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 3481:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false".

src/hotspot/cpu/x86/assembler_x86.cpp line 3483:

> 3481:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);
> 3482:   attributes.set_is_evex_instruction();
> 3483:   int encode = vex_prefix_and_encode(dst->encoding(), 0, src->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes);

I think we need to change this to:
int encode = vex_prefix_and_encode(dst->encoding(), 0, src->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes, true);
Please note the last argument for APX encoding when src is in higher register bank.

src/hotspot/cpu/x86/assembler_x86.cpp line 3489:

> 3487: void Assembler::vmovw(Register dst, XMMRegister src) {
> 3488:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 3489:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false".

src/hotspot/cpu/x86/assembler_x86.cpp line 3491:

> 3489:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);
> 3490:   attributes.set_is_evex_instruction();
> 3491:   int encode = vex_prefix_and_encode(src->encoding(), 0, dst->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes);

I think we need to change this to:
int encode = vex_prefix_and_encode(src->encoding(), 0, dst->encoding(), VEX_SIMD_66, VEX_OPCODE_MAP5, &attributes, true);
Please note the last argument for APX encoding when dst is in higher register bank.

src/hotspot/cpu/x86/assembler_x86.cpp line 8464:

> 8462: void Assembler::evaddph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8463:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8464:   InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

It will be good to have the second argument with comment as "/* vex_w */ false".

src/hotspot/cpu/x86/assembler_x86.cpp line 8483:

> 8481: void Assembler::evsubph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8482:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8483:   InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8502:

> 8500: void Assembler::evmulph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8501:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8502:   InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8521:

> 8519: void Assembler::evminph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8520:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8521:   InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8540:

> 8538: void Assembler::evmaxph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8539:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8540:   InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8559:

> 8557: void Assembler::evdivph(XMMRegister dst, XMMRegister nds, XMMRegister src, int vector_len) {
> 8558:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8559:   InstructionAttr attributes(vector_len, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ true);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8576:

> 8574: }
> 8575: 
> 8576: void Assembler::evsqrtph(XMMRegister dst, XMMRegister src1, int vector_len) {

A nitpick src1 could be src :).

src/hotspot/cpu/x86/assembler_x86.cpp line 8614:

> 8612: }
> 8613: 
> 8614: void Assembler::eaddsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {

This should be vaddsh.

src/hotspot/cpu/x86/assembler_x86.cpp line 8616:

> 8614: void Assembler::eaddsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {
> 8615:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8616:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8622:

> 8620: }
> 8621: 
> 8622: void Assembler::esubsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {

This should be vsubsh.

src/hotspot/cpu/x86/assembler_x86.cpp line 8624:

> 8622: void Assembler::esubsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {
> 8623:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8624:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8630:

> 8628: }
> 8629: 
> 8630: void Assembler::edivsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {

This should be vdivsh.

src/hotspot/cpu/x86/assembler_x86.cpp line 8632:

> 8630: void Assembler::edivsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {
> 8631:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8632:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8638:

> 8636: }
> 8637: 
> 8638: void Assembler::emulsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {

This should be vmulsh.

src/hotspot/cpu/x86/assembler_x86.cpp line 8640:

> 8638: void Assembler::emulsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {
> 8639:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8640:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8646:

> 8644: }
> 8645: 
> 8646: void Assembler::emaxsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {

This should be vmaxsh.

src/hotspot/cpu/x86/assembler_x86.cpp line 8648:

> 8646: void Assembler::emaxsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {
> 8647:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8648:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8654:

> 8652: }
> 8653: 
> 8654: void Assembler::eminsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {

This should be vminsh.

src/hotspot/cpu/x86/assembler_x86.cpp line 8656:

> 8654: void Assembler::eminsh(XMMRegister dst, XMMRegister nds, XMMRegister src) {
> 8655:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8656:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/assembler_x86.cpp line 8662:

> 8660: }
> 8661: 
> 8662: void Assembler::esqrtsh(XMMRegister dst, XMMRegister src) {

This should be vsqrtsh.

src/hotspot/cpu/x86/assembler_x86.cpp line 8664:

> 8662: void Assembler::esqrtsh(XMMRegister dst, XMMRegister src) {
> 8663:   assert(VM_Version::supports_avx512_fp16(), "requires AVX512-FP16");
> 8664:   InstructionAttr attributes(AVX_128bit, false, /* legacy_mode */ false, /* no_mask_reg */ true, /* uses_vl */ false);

It will be good to have the second argument with comment as "/* vex_w */ false"

src/hotspot/cpu/x86/stubGenerator_x86_64.cpp line 3974:

> 3972:   generate_libm_stubs();
> 3973: 
> 3974:   StubRoutines::_fmod = generate_libmFmod(); // from stubGenerator_x86_64_fmod.cpp

Good to retain the is_intrinsic_available checks.

src/hotspot/cpu/x86/x86.ad line 4518:

> 4516: #ifdef _LP64
> 4517: instruct ReplS_imm(vec dst, immH con, rRegI rtmp) %{
> 4518:   predicate(VM_Version::supports_avx512_fp16() && Matcher::vector_element_basic_type(n) == T_SHORT);

I have a question about the predicate for ReplS_imm. What happens if the predicate is false? There doesn't seem to be any other instruct rule to cover that situation. Also I don't see any check in match rule supported on Replicate node.

src/hotspot/cpu/x86/x86.ad line 10895:

> 10893:   format %{ "esqrtsh $dst, $src" %}
> 10894:   ins_encode %{
> 10895:     int opcode = this->ideal_Opcode();

opcode is unused.

src/hotspot/cpu/x86/x86.ad line 10936:

> 10934:   ins_encode %{
> 10935:     int vlen_enc = vector_length_encoding(this);
> 10936:     int opcode = this->ideal_Opcode();

opcode unused later.

src/hotspot/cpu/x86/x86.ad line 10949:

> 10947:   ins_encode %{
> 10948:     int vlen_enc = vector_length_encoding(this);
> 10949:     int opcode = this->ideal_Opcode();

opcode unused later.

src/hotspot/cpu/x86/x86.ad line 10964:

> 10962:   match(Set dst (SubVHF src1 src2));
> 10963:   format %{ "evbinopfp16_reg $dst, $src1, $src2" %}
> 10964:   ins_cost(450);

Why ins_cost 450 here for reg version and 150 for mem version of binOps?  Whereas sqrt above has 150 cost for both reg and mem version. Good to be consistent.

src/hotspot/cpu/x86/x86.ad line 11012:

> 11010:   effect(DEF dst);
> 11011:   format %{ "evfmaph_reg $dst, $src1, $src2\t# $dst = $dst * $src1 + $src2 fma packedH" %}
> 11012:   ins_cost(450);

Good to be consistent with ins_cost for reg vs mem version.

src/hotspot/cpu/x86/x86.ad line 11015:

> 11013:   ins_encode %{
> 11014:     int vlen_enc = vector_length_encoding(this);
> 11015:     __ evfmadd132ph($dst$$XMMRegister, $src2$$XMMRegister, $src1$$XMMRegister, vlen_enc);

Wondering if for auto vectorization the natural fma form is dst = dst + src1 * src2 i.e.
     match(Set dst (FmaVHF dst (Binary src1 src2)));
which then leads to fmadd231.

src/hotspot/share/adlc/output_h.cpp line 1298:

> 1296:         case Form::idealD: type = "Type::DOUBLE";   break;
> 1297:         case Form::idealL: type = "TypeLong::LONG"; break;
> 1298:         case Form::idealH: type = "Type::HALF_LONG"; break;

This should be Type::HALF_FLOAT

src/hotspot/share/classfile/vmSymbols.hpp line 143:

> 141:   template(java_util_DualPivotQuicksort,              "java/util/DualPivotQuicksort")             \
> 142:   template(jdk_internal_misc_Signal,                  "jdk/internal/misc/Signal")                 \
> 143:   template(jdk_internal_math_Float16Math,             "jdk/internal/math/Float16Math")            \

This seems to be leftover template.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843870304
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843899813
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843870852
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843902337
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843871328
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843906656
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843908957
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843910609
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843912897
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843914392
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843916999
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843922125
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843922490
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843923239
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843924299
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843925126
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843925319
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843926551
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843926789
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843928252
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843928447
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843929519
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843929686
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843930969
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1843931641
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847403451
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847400518
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844234786
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844237825
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844238487
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1844244532
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847443990
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847448109
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847470619
PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1847475384

From sviswanathan at openjdk.org  Tue Nov 19 19:57:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Nov 2024 19:57:19 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <CrVDItGL-GfJlu2dxNg_hEhMooMCSJOjG8xXLaBWyrI=.60c48d22-20aa-4e0e-8c50-0f51678090dd@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <bu_f3Jh-bje2KYXVQS-c9SYHtTMSzoXyXObYlr-ueDw=.340ed4f8-baf9-4caf-8c85-7cbb3e751471@github.com>
 <CrVDItGL-GfJlu2dxNg_hEhMooMCSJOjG8xXLaBWyrI=.60c48d22-20aa-4e0e-8c50-0f51678090dd@github.com>
Message-ID: <W3JKKQqwxlCtGfemlg9NNpWtPQ0xyXpZEEALHIzJrSM=.2349dee2-de57-4ed5-b349-b0c60baa995c@github.com>

On Tue, 19 Nov 2024 08:43:06 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> src/hotspot/cpu/x86/x86.ad line 11015:
>> 
>>> 11013:   ins_encode %{
>>> 11014:     int vlen_enc = vector_length_encoding(this);
>>> 11015:     __ evfmadd132ph($dst$$XMMRegister, $src2$$XMMRegister, $src1$$XMMRegister, vlen_enc);
>> 
>> Wondering if for auto vectorization the natural fma form is dst = dst + src1 * src2 i.e.
>>      match(Set dst (FmaVHF dst (Binary src1 src2)));
>> which then leads to fmadd231.
>
> ISA supports multiple flavors, the current scheme is in line with the wiring of inputs done before matching.

You could save some reg/reg movs with 231 flavor.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848290834

From sviswanathan at openjdk.org  Tue Nov 19 19:57:19 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Nov 2024 19:57:19 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <bu_f3Jh-bje2KYXVQS-c9SYHtTMSzoXyXObYlr-ueDw=.340ed4f8-baf9-4caf-8c85-7cbb3e751471@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <bu_f3Jh-bje2KYXVQS-c9SYHtTMSzoXyXObYlr-ueDw=.340ed4f8-baf9-4caf-8c85-7cbb3e751471@github.com>
Message-ID: <3vPdEXbVVSjvDf_JAaLRwBTsYCBuD631lPgFz6pIkV4=.65022b33-9275-41ba-83e0-64df0b07f31b@github.com>

On Tue, 19 Nov 2024 00:29:42 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 6. Auto-vectorization of newly supported scalar operations.
>> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
>> 9. Functional and Performance validation tests.
>> 
>> **Missing Pieces:-**
>> **-  AARCH64 Backend.**
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> src/hotspot/share/classfile/vmSymbols.hpp line 143:
> 
>> 141:   template(java_util_DualPivotQuicksort,              "java/util/DualPivotQuicksort")             \
>> 142:   template(jdk_internal_misc_Signal,                  "jdk/internal/misc/Signal")                 \
>> 143:   template(jdk_internal_math_Float16Math,             "jdk/internal/math/Float16Math")            \
> 
> This seems to be leftover template.

I don't see use of this one, you have another one with jdk_internal_vm_vector_Float16Math which is being used.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1848295979

From bkilambi at openjdk.org  Tue Nov 19 19:57:19 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Tue, 19 Nov 2024 19:57:19 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <jFmLUpO_eNeiY3rvLWgMvsdtre2VAv7JeqWSdUGLSGw=.b8327876-65e9-41fa-925b-6eaa161032a6@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <jFmLUpO_eNeiY3rvLWgMvsdtre2VAv7JeqWSdUGLSGw=.b8327876-65e9-41fa-925b-6eaa161032a6@github.com>
Message-ID: <Xam88Q9Gn89A5-TVxHNZ7TQP39m6yoJdDfi4RTl4e78=.c1aeb3c7-a91f-4bac-be51-7f6544365be2@github.com>

On Wed, 16 Oct 2024 14:19:40 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 6. Auto-vectorization of newly supported scalar operations.
>> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
>> 9. Functional and Performance validation tests.
>> 
>> **Missing Pieces:-**
>> **-  AARCH64 Backend.**
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> test/hotspot/jtreg/compiler/lib/ir_framework/IRNode.java line 122:
> 
>> 120:     public static final String VECTOR_SIZE_64  = VECTOR_SIZE + "64";
>> 121: 
>> 122:     private static final String TYPE_BYTE   = "byte";
> 
> Hi Jatin, why have these changes been made? The PrintIdeal output still prints the vector size of the node in this format - `#vectord<S,4>`. This test - `test/hotspot/jtreg/compiler/vectorization/TestFloatConversionsVectorNaN.java` was failing due to this mismatch ..

Infact many tests under test/hotspot fail due to this change.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1804557172

From dfuchs at openjdk.org  Tue Nov 19 20:01:56 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Tue, 19 Nov 2024 20:01:56 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
Message-ID: <b5rfty6fuRQ5uKpqvGf8XSoQVX944VHtybgEO8UAqnc=.2e6909ae-6a6a-42ac-8a1a-414df0b5bb40@github.com>

On Tue, 19 Nov 2024 19:22:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>>     - `com.sun.jndi.rmi.object.trustURLCodebase`
>> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
>> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
>> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
>> 
>> These changes require a CSR that will be submitted soon.
>> 
>> ### Testing
>> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
>> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify factory location usages in NamingManager and jdk.naming.rmi module-info

The updates looks good to me. Thanks for the clarification.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22154#pullrequestreview-2446536122

From asemenyuk at openjdk.org  Tue Nov 19 20:24:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 20:24:59 GMT
Subject: RFR: 8289771: jpackage: ResourceEditor error when path is overly long
 on Windows
Message-ID: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>

Fix `ResourceEditor` class to handle long paths.

Based on https://github.com/openjdk/jdk/pull/9384 PR.

This repairs app image building on Windows if the path to jpackage temp directory exceeds 260 (`MAX_PATH`) characters. MSI building is still broken and can NOT be repaired due to WiX's limitations.

Repaired scenario when the `--dest` option references a long path on Windows. Previously jpackage would have failed to build MSI package.

Other changes:
 - Rename `Executor.setRemovePath()` into `Executor.setRemovePathEnvVar()` to make the method name match the implementation.
 - Move the mutable part of `WixPipeline` class into `WixPipeline.Builder` class.
 - Fixed minor flaws in "WinL10nTest.java"

-------------

Commit messages:
 - Merge branch 'master' into JDK-8289771
 - Fix bad merge
 - Use JDK21 Path.resolve()
 - Fix bad merge
 - Merge branch 'JDK-8344550' into JDK-8289771
 - 8344550: Compilation error of jpackage test JPackageStringBundle.java source
 - Copy transient msi file in "msi-copy" subdir of the test work dir instead of the test work dir.
 - l10n bugfix
 - Merge branch 'master' into JDK-8289771
 - - Restored absolute paths in wix command lines.
 - ... and 7 more: https://git.openjdk.org/jdk/compare/78602be1...eff5cf01

Changes: https://git.openjdk.org/jdk/pull/22092/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22092&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8289771
  Stats: 512 lines in 18 files changed: 415 ins; 12 del; 85 mod
  Patch: https://git.openjdk.org/jdk/pull/22092.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22092/head:pull/22092

PR: https://git.openjdk.org/jdk/pull/22092

From asemenyuk at openjdk.org  Tue Nov 19 20:24:59 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 20:24:59 GMT
Subject: RFR: 8289771: jpackage: ResourceEditor error when path is overly
 long on Windows
In-Reply-To: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
References: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
Message-ID: <oQvS-7JNG-U7jxF4tf2BHeAzxavCL2WdMm9yKviTVGQ=.d9bdf5a5-f5a0-4c94-afa8-01ce0364af0b@github.com>

On Thu, 14 Nov 2024 04:40:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix `ResourceEditor` class to handle long paths.
> 
> Based on https://github.com/openjdk/jdk/pull/9384 PR.
> 
> This repairs app image building on Windows if the path to jpackage temp directory exceeds 260 (`MAX_PATH`) characters. MSI building is still broken and can NOT be repaired due to WiX's limitations.
> 
> Repaired scenario when the `--dest` option references a long path on Windows. Previously jpackage would have failed to build MSI package.
> 
> Other changes:
>  - Rename `Executor.setRemovePath()` into `Executor.setRemovePathEnvVar()` to make the method name match the implementation.
>  - Move the mutable part of `WixPipeline` class into `WixPipeline.Builder` class.
>  - Fixed minor flaws in "WinL10nTest.java"

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22092#issuecomment-2486673400

From bpb at openjdk.org  Tue Nov 19 20:32:53 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Nov 2024 20:32:53 GMT
Subject: Integrated: 8344077: Remove security manager dependency in java.io
In-Reply-To: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
References: <ogaYsPqu_eBix_ywIhviRmLnOu-_rKKeVdhxSIBG94o=.38a102b9-2d41-4fd0-a6cb-38769880b2e1@github.com>
Message-ID: <ghZfbTPiJjr84zSGkF_PUyadgqi4j7Ac_jozClqT5lg=.ba05ef06-3a18-4967-8f09-ad014a8b800e@github.com>

On Mon, 18 Nov 2024 20:28:49 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Expunge the use of the `SecurityManager`, `AccessController`, and the like from the `java.io` package.

This pull request has now been integrated.

Changeset: 81e43114
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/81e43114eca5199a0d816c02f50ecb6bc370135b
Stats:     278 lines in 9 files changed: 5 ins; 237 del; 36 mod

8344077: Remove security manager dependency in java.io

Reviewed-by: rriggs, alanb, naoto, lancea

-------------

PR: https://git.openjdk.org/jdk/pull/22219

From jbhateja at openjdk.org  Tue Nov 19 20:39:00 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Tue, 19 Nov 2024 20:39:00 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <W3JKKQqwxlCtGfemlg9NNpWtPQ0xyXpZEEALHIzJrSM=.2349dee2-de57-4ed5-b349-b0c60baa995c@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <bu_f3Jh-bje2KYXVQS-c9SYHtTMSzoXyXObYlr-ueDw=.340ed4f8-baf9-4caf-8c85-7cbb3e751471@github.com>
 <CrVDItGL-GfJlu2dxNg_hEhMooMCSJOjG8xXLaBWyrI=.60c48d22-20aa-4e0e-8c50-0f51678090dd@github.com>
 <W3JKKQqwxlCtGfemlg9NNpWtPQ0xyXpZEEALHIzJrSM=.2349dee2-de57-4ed5-b349-b0c60baa995c@github.com>
Message-ID: <tVgDdJjf2a1lHLsDQkL1YSkfT0Qi-e0EmTefIuqZcRU=.8d87301b-3608-4076-8fa8-4626ea850206@github.com>

On Tue, 19 Nov 2024 12:41:46 GMT, Sandhya Viswanathan <sviswanathan at openjdk.org> wrote:

>> ISA supports multiple flavors, the current scheme is in line with the wiring of inputs done before matching.
>
> You could save some reg/reg movs with 231 flavor.

It will depend on the live ranges of the three inputs.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1849024128

From asemenyuk at openjdk.org  Tue Nov 19 20:39:12 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 20:39:12 GMT
Subject: RFR: 8289771: jpackage: ResourceEditor error when path is overly
 long on Windows [v2]
In-Reply-To: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
References: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
Message-ID: <GLjJsKM8R67OJn1PyrU6nFGvc1gWqJ7K0cViKgXjaj0=.0d6f7065-71dd-4cf9-a8be-7fe5699c4490@github.com>

> Fix `ResourceEditor` class to handle long paths.
> 
> Based on https://github.com/openjdk/jdk/pull/9384 PR.
> 
> This repairs app image building on Windows if the path to jpackage temp directory exceeds 260 (`MAX_PATH`) characters. MSI building is still broken and can NOT be repaired due to WiX's limitations.
> 
> Repaired scenario when the `--dest` option references a long path on Windows. Previously jpackage would have failed to build MSI package.
> 
> Other changes:
>  - Rename `Executor.setRemovePath()` into `Executor.setRemovePathEnvVar()` to make the method name match the implementation.
>  - Move the mutable part of `WixPipeline` class into `WixPipeline.Builder` class.
>  - Fixed minor flaws in "WinL10nTest.java"

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Redundant change reverted

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22092/files
  - new: https://git.openjdk.org/jdk/pull/22092/files/eff5cf01..92cf525d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22092&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22092&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 1 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22092.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22092/head:pull/22092

PR: https://git.openjdk.org/jdk/pull/22092

From erikj at openjdk.org  Tue Nov 19 20:41:22 2024
From: erikj at openjdk.org (Erik Joelsson)
Date: Tue, 19 Nov 2024 20:41:22 GMT
Subject: RFR: 8339480: Build static-jdk image with a statically linked
 launcher [v17]
In-Reply-To: <YIPIccykqXpQc2UGuoaE99ZabdrBSYRpOrAWg721qus=.cbd8ae38-2631-479a-a915-ca17f3ab8707@github.com>
References: <5r5p2HyEXsEIr7wnq_5RSMfcbw-gsP4fBvTgr9P2lvY=.d3a51eae-661a-45d2-80e1-723e05e5eb32@github.com>
 <YIPIccykqXpQc2UGuoaE99ZabdrBSYRpOrAWg721qus=.cbd8ae38-2631-479a-a915-ca17f3ab8707@github.com>
Message-ID: <FqbzYEVzXfoJA3IXrygZ4AQJ8PZSqG4fZ5MM3zvcchI=.05d0e116-bc15-46a5-9ea0-be0bee85a96f@github.com>

On Mon, 18 Nov 2024 15:12:12 GMT, Magnus Ihse Bursie <ihse at openjdk.org> wrote:

>> As a prerequisite for Hermetic Java, we need a statically linked `java` launcher. It should behave like the normal, dynamically linked `java` launcher, except that all JDK native libraries should be statically, not dynamically, linked.
>> 
>> This patch is the first step towards this goal. It will generate a `static-jdk` image with a statically linked launcher. This launcher is missing several native libs, however, and does therefore not behave like a proper dynamic java. One of the reasons for this is that local symbol hiding in static libraries are not implemented yet, which causes symbol clashes when linking all static libraries together. This will be addressed in an upcoming patch. 
>> 
>> All changes in the `src` directory are copied from, or inspired by, changes made in [the hermetic-java-runtime branch in Project Leyden](https://github.com/openjdk/leyden/tree/hermetic-java-runtime).
>
> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Copy debuginfo

make/StaticLibs.gmk line 67:

> 65:   # BitmapToYXBandedRectangles, so we exclude it for now.
> 66:   BROKEN_STATIC_LIBS += splashscreen
> 67:   # windowsaccessbridge-64 has multiple collisions and conflicts

I don't think we will ever include the accessbridge libraries. Those are never loaded by the JDK itself. They are meant to be loaded by other applications to interact with the JDK. So instead of classifying them as "broken", I think they should just be permanently excluded for a valid reason.

make/autoconf/buildjdk-spec.gmk.template line 80:

> 78: CXXFLAGS_JDKEXE := @OPENJDK_BUILD_CXXFLAGS_JDKEXE@
> 79: LDFLAGS_JDKEXE := @OPENJDK_BUILD_LDFLAGS_JDKEXE@
> 80: LDFLAGS_STATIC_JDK := @OPENJDK_BUILD_LDFLAGS_STATIC_JDK@

Do we really expect to ever build a static-jdk as buildjdk?

make/common/JdkNativeCompilation.gmk line 313:

> 311:     # created libraries, and is read by ModuleWrapper.
> 312:     ifneq ($$($1_EXCLUDE_FROM_STATIC_LIBS), true)
> 313:       $$(MODULE)_JDK_LIBS += $$($1_NAME)

This variable is used to track libraries that should be included in static libs. Perhaps the name should include the word "static" to make this clearer? Otherwise it doesn't make sense to exclude libraries like this from this list.

make/modules/java.desktop/lib/ClientLibraries.gmk line 166:

> 164:         jfdctflt.o jfdctfst.o jfdctint.o jidctflt.o jidctfst.o jidctint.o \
> 165:         jidctred.o jmemmgr.o jmemnobs.o jpegdecoder.o jquant1.o jquant2.o \
> 166:         jutils.o

If libsplashscreen is already excluded in StaticLibs.gmk, why do we need to exclude obj files here?

Would it be possible to generate this list? I assume it's all the src files in libjavajpeg, but with the object file suffix.

make/modules/java.desktop/lib/ClientLibraries.gmk line 180:

> 178:         deflate.o Deflater.o Inflater.o gzclose.o gzlib.o gzread.o gzwrite.o \
> 179:         infback.o inffast.o inflate.o inftrees.o trees.o uncompr.o zadler32.o \
> 180:         zcrc32.o zip_util.o zutil.o

Same as above.

make/modules/jdk.accessibility/Lib.gmk line 77:

> 75:       VERSIONINFO_RESOURCE := \
> 76:           $(ACCESSIBILITY_SRCDIR)/common/AccessBridgeStatusWindow.rc, \
> 77:       STATIC_LIB_EXCLUDE_OBJS := AccessBridgeDebug.obj AccessBridgeMessages.obj, \

Again, the accessbridge libraries aren't loaded by the JDK, so it doesn't really make sense to include them in a single static launcher.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1848957096
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849009531
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849016315
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849022738
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849023239
PR Review Comment: https://git.openjdk.org/jdk/pull/20837#discussion_r1849026904

From rriggs at openjdk.org  Tue Nov 19 20:48:50 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Tue, 19 Nov 2024 20:48:50 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
Message-ID: <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>

On Tue, 19 Nov 2024 19:22:44 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>>     - `com.sun.jndi.rmi.object.trustURLCodebase`
>> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
>> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
>> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
>> 
>> These changes require a CSR that will be submitted soon.
>> 
>> ### Testing
>> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
>> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   clarify factory location usages in NamingManager and jdk.naming.rmi module-info

src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 262:

> 260:         }
> 261: 
> 262:         worker = new Thread(this);

Rataining a static factory for thread may use useful to be able to customize thread behavior.

It should be considered that the new threads are Virtual threads:
 i.e.  `Thread.ofVirtual().startVirtualThread(Runnable)`

src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java line 163:

> 161:     InputStream getJavaHomeConfStream(String filename) {
> 162:         try {
> 163:             String javahome = System.getProperty("java.home");

StaticProperty.javaHome() is available as a stable value for the property.

src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 127:

> 125:      *    Return {@code refInfo} if the factory cannot be created.
> 126:      *    Downloading a factory class from a location specified in the reference
> 127:      *    is not supported out of the box.

"out of the box" seems a bit informal for the space.
Perhaps...

Downloading a factory class from a location specified in the reference can be supported by a custom implementation of {@link ObjectFactoryBuilder}.

etc.

src/jdk.naming.rmi/share/classes/com/sun/jndi/rmi/registry/RegistryContext.java line 471:

> 469:             /*
> 470:              * Downloading a factory class from a location specified in the reference
> 471:              * is not supported out of the box. A custom "ObjectFactoryBuilder"

Update here too for "out of the box" as above.

src/jdk.naming.rmi/share/classes/module-info.java line 61:

> 59:  *     </li>
> 60:  * </ul>
> 61:  * <p> Factory class names associated with a {@linkplain javax.naming.Reference#getFactoryClassLocation() factory

ditto

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849021691
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849026408
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849030767
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849031705
PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1849032876

From naoto at openjdk.org  Tue Nov 19 21:03:07 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Tue, 19 Nov 2024 21:03:07 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v2]
In-Reply-To: <8W7-Y64Rn1pVLuPfLoAktG-ekfebPelcoWQbxxiEMjE=.f07e118b-99ea-4ef0-909d-6141b08e4a55@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <8W7-Y64Rn1pVLuPfLoAktG-ekfebPelcoWQbxxiEMjE=.f07e118b-99ea-4ef0-909d-6141b08e4a55@github.com>
Message-ID: <SrzJo73RPFigmAaiueCT3eIwWsTGihps9ScE0I_kuXw=.67aa29f8-d82e-4d67-8e24-415da708d173@github.com>

On Tue, 19 Nov 2024 07:58:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change.
>> 
>> APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
>> Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address Chen's review; make other similar changes

Looks good. Some comments that I missed in the initial (internal) review.

src/java.base/share/classes/java/util/Locale.java line 89:

> 87:  * exchange. Each {@code Locale} is associated with locale data which is retrieved
> 88:  * by the installed {@link java.util.spi.LocaleServiceProvider LocaleServiceProvider}
> 89:  * implementations. Depending on the implementation, such data may vary by release.

This reads like locale data are only obtained with the SPI implementations that are provided by the users. The locale data also (and mainly) come from within Java runtime itself. (BTW, "installed" should be removed, as it is no longer correct. Same applies to getAvailableLocales()/availableLocales() methods)

src/java.base/share/classes/java/util/Locale.java line 98:

> 96:  * Locale.forLanguageTag("en-Latn-US-POSIX-u-nu-latn")} would be comprised of all
> 97:  * the fields below. This particular {@code Locale} would represent English in
> 98:  * the United States using the Latin alphabet and numerics for use in POSIX

"script" is more precise than "alphabet", as the latter suggests only letters [A-Z]

src/java.base/share/classes/java/util/Locale.java line 144:

> 142:  *   each indicating its own semantics, these values should be ordered
> 143:  *   by importance, with most important first, separated by
> 144:  *   underscore('_').  The variant field is case sensitive.</dd>

This part "separated by underscore('_')" is missing in the revised doc

src/java.base/share/classes/java/util/Locale.java line 216:

> 214:  * overloads do not make any syntactic checks on the input.
> 215:  *
> 216:  * <h3><a id="def_locale_extension">Unicode locale/language extension</a></h3>

Probably using the exact name in the external spec is better [Unicode BCP 47 U Extension](https://unicode.org/reports/tr35/#u_Extension)

src/java.base/share/classes/java/util/Locale.java line 218:

> 216:  * <h3><a id="def_locale_extension">Unicode locale/language extension</a></h3>
> 217:  *
> 218:  * <p>UTS#35, "Unicode Locale Data Markup Language" defines optional

UTS35 (https://unicode.org/reports/tr35/) should be listed with @spec link

src/java.base/share/classes/java/util/Locale.java line 344:

> 342:  *  to BCP 47 syntax. Use a builder to enforce syntactic restrictions on the input.</dd>
> 343:  * </dl>
> 344:  * <p>The following are all equivalent:

"all equivalent" seems a bit vague, as the actual implementation is not equivalent (unlike other examples below). Something like "the following all produce equivalent locale objects" or along the lines?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22192#pullrequestreview-2446512394
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1848969909
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1849007375
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1849018322
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1849026657
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1849027660
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1849032564

From mullan at openjdk.org  Tue Nov 19 21:09:34 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 19 Nov 2024 21:09:34 GMT
Subject: RFR: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules
Message-ID: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>

Now that JEP 486 has been integrated, `java.security.jgss` and `jdk.security.jgss` module dependencies on `System.getSecurityManager` and `AccessController.doPrivileged*` can be removed.

There is an undocumented property named "sun.security.krb5.autodeducerealm" that can probably be removed as it only affected behavior when an SM was enabled; however I have left the code that reads the property as-is (see sun/security/krb5/Realm.java) and have opened a separate issue to determine if it can be safely removed.

-------------

Commit messages:
 - Initial cleanup.

Changes: https://git.openjdk.org/jdk/pull/22256/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22256&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344248
  Stats: 876 lines in 42 files changed: 23 ins; 589 del; 264 mod
  Patch: https://git.openjdk.org/jdk/pull/22256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22256/head:pull/22256

PR: https://git.openjdk.org/jdk/pull/22256

From mullan at openjdk.org  Tue Nov 19 21:09:36 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Tue, 19 Nov 2024 21:09:36 GMT
Subject: RFR: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules
In-Reply-To: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
References: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
Message-ID: <fguJn3jyK9Nn3-VDhzK-fre6OS2d1BcdMyEAWhq82_4=.a3d9d625-ffe5-4c41-85b1-4600c2c11796@github.com>

On Tue, 19 Nov 2024 20:43:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Now that JEP 486 has been integrated, `java.security.jgss` and `jdk.security.jgss` module dependencies on `System.getSecurityManager` and `AccessController.doPrivileged*` can be removed.
> 
> There is an undocumented property named "sun.security.krb5.autodeducerealm" that can probably be removed as it only affected behavior when an SM was enabled; however I have left the code that reads the property as-is (see sun/security/krb5/Realm.java) and have opened a separate issue to determine if it can be safely removed.

src/java.security.jgss/share/classes/sun/security/jgss/GSSUtil.java line 367:

> 365:                 });
> 366:             return creds;
> 367:         } catch (PrivilegedActionException pae) {

The `PrivilegedExceptionAction` never throws a checked exception, so it was not necessary to retain the code inside the catch block.

src/java.security.jgss/share/classes/sun/security/jgss/krb5/Krb5Context.java line 665:

> 663:                                 }});
> 664:                             kerbTicket = tmp;
> 665:                         } catch (PrivilegedActionException e) {

The PrivilegedExceptionAction never throws a checked exception, so it was not necessary to retain the code inside the catch block.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22256#discussion_r1849039807
PR Review Comment: https://git.openjdk.org/jdk/pull/22256#discussion_r1849040940

From dl at openjdk.org  Tue Nov 19 21:12:58 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 19 Nov 2024 21:12:58 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
 <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
Message-ID: <BYdB_2uQUAlILCzpdJbJ3VqmokLXIvvs4LaiuAQDLb8=.2e61a8c6-3f77-4958-a85c-42a4de9a8f16@github.com>

On Tue, 19 Nov 2024 16:54:04 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 2838:
> 
>> 2836:                         }
>> 2837:                     }
>> 2838:                     else if ((q.phase & (IDLE|1)) == 0 ||
> 
> @DougLea What's the intent of the `|1` part here? ?

clarified by:
                    else if ((q.phase & (IDLE|1)) == 0 || // externally locked

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1849059348

From acobbs at openjdk.org  Tue Nov 19 21:50:13 2024
From: acobbs at openjdk.org (Archie Cobbs)
Date: Tue, 19 Nov 2024 21:50:13 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v7]
In-Reply-To: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
Message-ID: <FbyrPlsyHoA5n00uzetLuQwtOqeRmzjV6IRFSEveyRs=.fc5e3346-4055-4f93-b9a4-923fceded816@github.com>

> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.

Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:

 - Remove more unnecessary @SuppressWarnings annotations.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Remove more unnecessary warning suppressions.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
 - Merge branch 'master' into SuppressWarningsCleanup-core-libs
 - Update copyright years.
 - Remove a few more @SuppressWarnings annotations.
 - Remove a few more @SuppressWarnings annotations.
 - Update copyright years.
 - ... and 3 more: https://git.openjdk.org/jdk/compare/81e43114...1905d6e3

-------------

Changes: https://git.openjdk.org/jdk/pull/21852/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21852&range=06
  Stats: 197 lines in 100 files changed: 0 ins; 104 del; 93 mod
  Patch: https://git.openjdk.org/jdk/pull/21852.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21852/head:pull/21852

PR: https://git.openjdk.org/jdk/pull/21852

From asemenyuk at openjdk.org  Tue Nov 19 22:07:10 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 22:07:10 GMT
Subject: RFR: 8289771: jpackage: ResourceEditor error when path is overly
 long on Windows [v3]
In-Reply-To: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
References: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
Message-ID: <IbdCnDfjxPGlrD7cUbMxodzSoP-hAvxPQq8S54i5EAU=.aefb8e0e-7b2f-4bb2-8a34-d5e17844833a@github.com>

> Fix `ResourceEditor` class to handle long paths.
> 
> Based on https://github.com/openjdk/jdk/pull/9384 PR.
> 
> This repairs app image building on Windows if the path to jpackage temp directory exceeds 260 (`MAX_PATH`) characters. MSI building is still broken and can NOT be repaired due to WiX's limitations.
> 
> Repaired scenario when the `--dest` option references a long path on Windows. Previously jpackage would have failed to build MSI package.
> 
> Other changes:
>  - Rename `Executor.setRemovePath()` into `Executor.setRemovePathEnvVar()` to make the method name match the implementation.
>  - Move the mutable part of `WixPipeline` class into `WixPipeline.Builder` class.
>  - Fixed minor flaws in "WinL10nTest.java"

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Make path guaranteed to be long enough

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22092/files
  - new: https://git.openjdk.org/jdk/pull/22092/files/92cf525d..d73e1279

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22092&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22092&range=01-02

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22092.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22092/head:pull/22092

PR: https://git.openjdk.org/jdk/pull/22092

From sviswanathan at openjdk.org  Tue Nov 19 22:16:23 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Nov 2024 22:16:23 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v5]
In-Reply-To: <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <lYLZfTdJwvrqTDnD4njhGml5mT8yhsuU6KRRMYsMPsI=.7f107606-7069-4f3d-abde-7acd95c39109@github.com>
Message-ID: <3LxHrzC6cOgSadtyQP7g_3yHYNUev0PUXNTege2qdDI=.3e661cb5-b54d-462a-9482-d6c06394ad9b@github.com>

On Thu, 14 Nov 2024 18:24:59 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions incorporated.

Changes look good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2446759294

From dl at openjdk.org  Tue Nov 19 22:51:04 2024
From: dl at openjdk.org (Doug Lea)
Date: Tue, 19 Nov 2024 22:51:04 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v30]
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <jdXX1VI1LqZh-s8G-mqnEBTj460KfGSz7uL532mSHtM=.8999d2a6-e629-4181-a0b1-190759275c87@github.com>

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 52 additional commits since the last revision:

 - Merge branch 'openjdk:master' into JDK-8336707
 - Add comments
 - Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager
 - Merge branch 'openjdk:master' into JDK-8336707
 - Merge branch 'openjdk:master' into JDK-8336707
 - Rename variable
 - Merge branch 'openjdk:master' into JDK-8336707
 - Improve readbility; tweak runState checks
 - Address review comments
 - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
 - ... and 42 more: https://git.openjdk.org/jdk/compare/272f452b...b0fe90e0

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21507/files
  - new: https://git.openjdk.org/jdk/pull/21507/files/0f5aa3dc..b0fe90e0

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=29
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21507&range=28-29

  Stats: 55326 lines in 530 files changed: 23950 ins; 29119 del; 2257 mod
  Patch: https://git.openjdk.org/jdk/pull/21507.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21507/head:pull/21507

PR: https://git.openjdk.org/jdk/pull/21507

From bchristi at openjdk.org  Tue Nov 19 22:51:49 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 22:51:49 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs
In-Reply-To: <zNNkQaAhg0Dk1K3GKOIkWFWfz8YMYPdPgPfIGv2JEJE=.0f50efd4-b89d-44df-bb32-90c1d1c74e64@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <zNNkQaAhg0Dk1K3GKOIkWFWfz8YMYPdPgPfIGv2JEJE=.0f50efd4-b89d-44df-bb32-90c1d1c74e64@github.com>
Message-ID: <_Vt7y3sxrt0wPqpkmYy8mRniM4aNC8DMUyGB2rPHlpI=.156f74b9-47ee-47d8-beb6-0bd692599fb1@github.com>

On Tue, 19 Nov 2024 19:18:12 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.
>
> src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 63:
> 
>> 61: //        };
>> 62: //        AccessController.doPrivileged(load);
>> 63:     }
> 
> Looks like there is some clean up here to do of the commented out code...

Whoops!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1849152042

From bchristi at openjdk.org  Tue Nov 19 22:54:31 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 22:54:31 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <gABIx0R7GRrtxitmLR5rRsIdxRGFlhCTXsL-BHcIYmU=.3eef107f-2f34-4a67-8d4a-5d4304751f7f@github.com>

On Tue, 19 Nov 2024 18:52:59 GMT, Brent Christian <bchristi at openjdk.org> wrote:

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

src/java.prefs/share/classes/java/util/prefs/Preferences.java line 40:

> 38: import java.util.ServiceConfigurationError;
> 39: 
> 40: // These imports needed only as a workaround for a JavaDoc bug

This comment was added quite a while ago. But FWIW, a specdiff comparison shows no JavaDoc differences.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1849154006

From asemenyuk at openjdk.org  Tue Nov 19 22:58:22 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 22:58:22 GMT
Subject: RFR: 8344587: Reduce number of "jdk.jpackage.internal" classes used
 from other packages
Message-ID: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>

Stop using internal AppImageFile, ApplicationLayout, and PackageFile classes in the tests. Replace them with stubs.

Stop referencing IOUtils class from XmlUtils and PathUtils classes.

-------------

Commit messages:
 - Minor improvements
 - Make IOUtils class package-private
 - Bugfix & cleanup
 - Merge branch 'master' into SplitIOUtils.DecoupleAppImageFile
 - Bad merge fix
 - Bad merge fix
 - Make AppImageFile and PackageFile classes package-private
 - Revert "Get rid of FunctionalUtils.java". Brings back Functional.java to make the diff easier to digest. It will be replaced with redoing c58b6587b3b4fb9c08afd27eacf139e0ed9afb83 commit in the next PR.
 - Fix bad merge
 - 8344550: Compilation error of jpackage test JPackageStringBundle.java source
 - ... and 14 more: https://git.openjdk.org/jdk/compare/78602be1...9d1f097d

Changes: https://git.openjdk.org/jdk/pull/22261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22261&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344587
  Stats: 381 lines in 21 files changed: 288 ins; 61 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/22261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22261/head:pull/22261

PR: https://git.openjdk.org/jdk/pull/22261

From asemenyuk at openjdk.org  Tue Nov 19 22:58:37 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 22:58:37 GMT
Subject: RFR: 8343478: Remove unnecessary @SuppressWarnings annotations
 (core-libs) [v7]
In-Reply-To: <FbyrPlsyHoA5n00uzetLuQwtOqeRmzjV6IRFSEveyRs=.fc5e3346-4055-4f93-b9a4-923fceded816@github.com>
References: <9ZqHljyJeMr8fPG4-iU6bfQT9hQxTAwrGCl4xsQn3LA=.0b01f899-d849-4e23-8d50-8f186aade664@github.com>
 <FbyrPlsyHoA5n00uzetLuQwtOqeRmzjV6IRFSEveyRs=.fc5e3346-4055-4f93-b9a4-923fceded816@github.com>
Message-ID: <orMOnvkrksdnnyBuius74dW6mmg09oQWeoq3JaDSldA=.b65c151e-365d-4dde-bf04-8f5c09cb2018@github.com>

On Tue, 19 Nov 2024 21:50:13 GMT, Archie Cobbs <acobbs at openjdk.org> wrote:

>> Please review this patch which removes unnecessary `@SuppressWarnings` annotations.
>
> Archie Cobbs has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 13 commits:
> 
>  - Remove more unnecessary @SuppressWarnings annotations.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Remove more unnecessary warning suppressions.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Put back @SuppressWarnings annotations to be fixed by JDK-8343286.
>  - Merge branch 'master' into SuppressWarningsCleanup-core-libs
>  - Update copyright years.
>  - Remove a few more @SuppressWarnings annotations.
>  - Remove a few more @SuppressWarnings annotations.
>  - Update copyright years.
>  - ... and 3 more: https://git.openjdk.org/jdk/compare/81e43114...1905d6e3

jpackage looks good. Thank you!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21852#issuecomment-2486917552

From bchristi at openjdk.org  Tue Nov 19 23:06:59 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 23:06:59 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs [v2]
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <JgbXZv07Cn4rOT4bE6Xyjx0L4TPiEam56lBbYk_7G8A=.12932922-87c7-4937-9d35-d4cdd9491c68@github.com>

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  remove commented code + other review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22252/files
  - new: https://git.openjdk.org/jdk/pull/22252/files/de6717ca..fa0072b7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=00-01

  Stats: 197 lines in 6 files changed: 28 ins; 80 del; 89 mod
  Patch: https://git.openjdk.org/jdk/pull/22252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22252/head:pull/22252

PR: https://git.openjdk.org/jdk/pull/22252

From bchristi at openjdk.org  Tue Nov 19 23:16:38 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Tue, 19 Nov 2024 23:16:38 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs [v3]
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <yPUx983DZfehEsGqvS2VcBYlr1hFWn9FOpua6L-K9IA=.c778f275-7225-422e-8178-7f054eec2f8b@github.com>

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  One more comment removal; fix 1 indent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22252/files
  - new: https://git.openjdk.org/jdk/pull/22252/files/fa0072b7..452db4e4

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=01-02

  Stats: 3 lines in 1 file changed: 1 ins; 1 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22252/head:pull/22252

PR: https://git.openjdk.org/jdk/pull/22252

From sviswanathan at openjdk.org  Tue Nov 19 23:25:20 2024
From: sviswanathan at openjdk.org (Sandhya Viswanathan)
Date: Tue, 19 Nov 2024 23:25:20 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <7pJQGLP9E-cCKTxiOJTIxdbGaUjRtbNWYOb-NlymDfI=.fed0c520-4406-4ca0-90a1-3cdd9565aa7d@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

x86 changes look good to me.

-------------

Marked as reviewed by sviswanathan (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21490#pullrequestreview-2446932147

From asemenyuk at openjdk.org  Tue Nov 19 23:26:13 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Tue, 19 Nov 2024 23:26:13 GMT
Subject: RFR: 8344587: Reduce number of "jdk.jpackage.internal" classes
 used from other packages
In-Reply-To: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
References: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
Message-ID: <alBvIupcBbi0NyBSyDN0FzZSSP3edvHpHGOILZQhHpQ=.e77cdfab-c747-4307-bdba-7c2b014726ac@github.com>

On Tue, 19 Nov 2024 22:31:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Stop using internal AppImageFile, ApplicationLayout, and PackageFile classes in the tests. Replace them with stubs.
> 
> Stop referencing IOUtils class from XmlUtils and PathUtils classes.

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22261#issuecomment-2486959152

From bpb at openjdk.org  Tue Nov 19 23:39:16 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Tue, 19 Nov 2024 23:39:16 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs [v3]
In-Reply-To: <yPUx983DZfehEsGqvS2VcBYlr1hFWn9FOpua6L-K9IA=.c778f275-7225-422e-8178-7f054eec2f8b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <yPUx983DZfehEsGqvS2VcBYlr1hFWn9FOpua6L-K9IA=.c778f275-7225-422e-8178-7f054eec2f8b@github.com>
Message-ID: <gAx6LiDB7VIX8Sg5B6gGdwjhtJUYo1u1UFQpEQr_lQo=.c2541bc5-952d-4700-897e-25504cee2a10@github.com>

On Tue, 19 Nov 2024 23:16:38 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   One more comment removal; fix 1 indent

I think the try-block at line 137 in FileSystemPreferences would be more readable if it were indented. I know it was not indented in the original, either.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22252#issuecomment-2486985694

From almatvee at openjdk.org  Wed Nov 20 00:00:16 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 20 Nov 2024 00:00:16 GMT
Subject: RFR: 8289771: jpackage: ResourceEditor error when path is overly
 long on Windows [v3]
In-Reply-To: <IbdCnDfjxPGlrD7cUbMxodzSoP-hAvxPQq8S54i5EAU=.aefb8e0e-7b2f-4bb2-8a34-d5e17844833a@github.com>
References: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
 <IbdCnDfjxPGlrD7cUbMxodzSoP-hAvxPQq8S54i5EAU=.aefb8e0e-7b2f-4bb2-8a34-d5e17844833a@github.com>
Message-ID: <s9KDA-Z5fZV8wgEJOPLhnY9KjpHalotNcUHnsYMAehg=.127a6d91-8824-4ad3-8bce-204543babcdc@github.com>

On Tue, 19 Nov 2024 22:07:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fix `ResourceEditor` class to handle long paths.
>> 
>> Based on https://github.com/openjdk/jdk/pull/9384 PR.
>> 
>> This repairs app image building on Windows if the path to jpackage temp directory exceeds 260 (`MAX_PATH`) characters. MSI building is still broken and can NOT be repaired due to WiX's limitations.
>> 
>> Repaired scenario when the `--dest` option references a long path on Windows. Previously jpackage would have failed to build MSI package.
>> 
>> Other changes:
>>  - Rename `Executor.setRemovePath()` into `Executor.setRemovePathEnvVar()` to make the method name match the implementation.
>>  - Move the mutable part of `WixPipeline` class into `WixPipeline.Builder` class.
>>  - Fixed minor flaws in "WinL10nTest.java"
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make path guaranteed to be long enough

Looks good with minor comment.

test/jdk/tools/jpackage/windows/WinLongPathTest.java line 38:

> 36: 
> 37: /*
> 38: /* @test

Extra `/`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22092#pullrequestreview-2447053380
PR Review Comment: https://git.openjdk.org/jdk/pull/22092#discussion_r1849314467

From almatvee at openjdk.org  Wed Nov 20 00:21:14 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 20 Nov 2024 00:21:14 GMT
Subject: RFR: 8344587: Reduce number of "jdk.jpackage.internal" classes
 used from other packages
In-Reply-To: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
References: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
Message-ID: <6B3YLS4DN9BC0RMmzu6QK5jDQ1SX6ujtzc2GpJGI9QM=.c47092c5-eec9-4509-9e88-156340e592f4@github.com>

On Tue, 19 Nov 2024 22:31:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Stop using internal AppImageFile, ApplicationLayout, and PackageFile classes in the tests. Replace them with stubs.
> 
> Stop referencing IOUtils class from XmlUtils and PathUtils classes.

Looks good.

-------------

Marked as reviewed by almatvee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22261#pullrequestreview-2447075436

From bchristi at openjdk.org  Wed Nov 20 00:52:16 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 20 Nov 2024 00:52:16 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v13]
In-Reply-To: <pXpDzNzwVroE1zDlS0-B6wyaKjbVxbAm4nRZbjgTFNU=.7279b591-6d30-4243-be70-33dc5d1ca778@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pXpDzNzwVroE1zDlS0-B6wyaKjbVxbAm4nRZbjgTFNU=.7279b591-6d30-4243-be70-33dc5d1ca778@github.com>
Message-ID: <mCB4jmb-VnRYjydf7J8alcX5IgNa1Q9lcZcmCO6yYXY=.cc955bf8-4046-495e-ab95-64e7c8ec62ad@github.com>

On Tue, 19 Nov 2024 19:53:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use RandomFactory in test

src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java line 55:

> 53:      * Synchronized by the same lock as the list itself.
> 54:      */
> 55:     CleanerImpl.CleanableList.Node node;

I think we can get away with not storing a `Node` in every `PhantomCleanable`, and instead look for it at `index` in each `Node` in the list. But I don't know if this would be a performance win. Heap savings (in `PhantomCleanableRef`)? Worse locality from loading multiple `Nodes`?
Just an idea...

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1849349523

From duke at openjdk.org  Wed Nov 20 01:44:05 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 01:44:05 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v2]
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <9kZDumc5k0ros9ULPAbJoHr6gaRB9GshLau7Hp26zRU=.9f462baf-5d4c-4a9a-9d93-4e0ffc59edc4@github.com>

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

Taizo Kurashige has updated the pull request incrementally with five additional commits since the last revision:

 - Merge branch 'fix_Win8301247Test_bug' of https://github.com/kurashige23/jdk into fix_Win8301247Test_bug
 - Chenge code page from 65001 to 437
 - Fix how to execute chcp command
 - Change setWinEnableUTF8 to setWinRunWithEnglishOutput
 - Suppress the output of chcp command

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22142/files
  - new: https://git.openjdk.org/jdk/pull/22142/files/b1ee8f6f..09853425

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=00-01

  Stats: 37 lines in 2 files changed: 11 ins; 7 del; 19 mod
  Patch: https://git.openjdk.org/jdk/pull/22142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22142/head:pull/22142

PR: https://git.openjdk.org/jdk/pull/22142

From bchristi at openjdk.org  Wed Nov 20 01:45:23 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 20 Nov 2024 01:45:23 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v13]
In-Reply-To: <pXpDzNzwVroE1zDlS0-B6wyaKjbVxbAm4nRZbjgTFNU=.7279b591-6d30-4243-be70-33dc5d1ca778@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pXpDzNzwVroE1zDlS0-B6wyaKjbVxbAm4nRZbjgTFNU=.7279b591-6d30-4243-be70-33dc5d1ca778@github.com>
Message-ID: <7rb2OP1sD67hcCf7_7fpU6iKdnCVnSIc1OD1Mc2mSnE=.6cb40460-b3fe-43e7-ac47-24267c3426d1@github.com>

On Tue, 19 Nov 2024 19:53:45 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Use RandomFactory in test

Changes requested by bchristi (Reviewer).

test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 126:

> 124:                 bs.set(idx, true);
> 125:             }
> 126:         }

Can the test remove everything left in the list after doing the `RANDOM_ITERATIONS`?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22043#pullrequestreview-2447166752
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1849383928

From duke at openjdk.org  Wed Nov 20 01:47:34 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 01:47:34 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v3]
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <hndlZN69I1KUIJiggSJVeiDyDMOeISljrOnqd-v7Q4c=.c49cb615-b76c-483f-9683-bd45c2dd834b@github.com>

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:

  Fix indent

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22142/files
  - new: https://git.openjdk.org/jdk/pull/22142/files/09853425..0d9fee82

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=01-02

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22142/head:pull/22142

PR: https://git.openjdk.org/jdk/pull/22142

From bpb at openjdk.org  Wed Nov 20 02:24:14 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 02:24:14 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v9]
In-Reply-To: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
Message-ID: <81nytC3uzQYaDXb49LwlrL-KD-DpQNPpNvT-1ZuEsP4=.bb85996e-8342-4646-9ae3-9796368bc9ea@github.com>

> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.

Brian Burkhalter has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge
 - 8337143: Minor makefile tweak
 - 8337143: Clean up to address reviewer comments
 - Merge
 - 8337143: Remove loading libnet from Inet6AddressImpl; delete commented out #include in Windows IOUtil.c
 - Merge
 - 8337143: Removed dependency of libjava on headers in libnio/ch
 - 8337143: Move natives to <platform>/native/libjava/nio/{ch,fs} as a function of their original location in libnio
 - 8337143: (fc, fs) Move filesystem-related native objects from libnio to libjava

-------------

Changes: https://git.openjdk.org/jdk/pull/20317/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=20317&range=08
  Stats: 1550 lines in 93 files changed: 774 ins; 668 del; 108 mod
  Patch: https://git.openjdk.org/jdk/pull/20317.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/20317/head:pull/20317

PR: https://git.openjdk.org/jdk/pull/20317

From bpb at openjdk.org  Wed Nov 20 02:24:15 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 02:24:15 GMT
Subject: RFR: 8337143: (fc, fs) Move filesystem-related native objects from
 libnio to libjava [v8]
In-Reply-To: <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
References: <TNlAuJBeBcTH1PE3w2bgVm-OFNoQcN84ICcym6yX3hs=.b134d04f-caff-49bf-87f1-de893bbcd6ef@github.com>
 <9c33BSHE6QZOYbovTdFn7-phiTp7TsKkeqIJ2vBMNco=.2c33a924-d137-4559-b0f5-154a643caf95@github.com>
Message-ID: <5l_XeflDxQIpBKlCLN0S0PbcpC3lnP4KHNMkPwbcj4U=.72734adb-4db6-41fd-a241-f792f67728b9@github.com>

On Fri, 13 Sep 2024 20:41:27 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> This proposed change would move the native objects required for NIO file interaction from the libnio native library to the libjava native library on Linux, macOS, and Windows.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8337143: Minor makefile tweak

The merge commit 403602f built and passed `jdk_core` tests on Linux, macOS, and Windows.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20317#issuecomment-2487186467

From asemenyuk at openjdk.org  Wed Nov 20 03:01:28 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 20 Nov 2024 03:01:28 GMT
Subject: RFR: 8289771: jpackage: ResourceEditor error when path is overly
 long on Windows [v3]
In-Reply-To: <s9KDA-Z5fZV8wgEJOPLhnY9KjpHalotNcUHnsYMAehg=.127a6d91-8824-4ad3-8bce-204543babcdc@github.com>
References: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
 <IbdCnDfjxPGlrD7cUbMxodzSoP-hAvxPQq8S54i5EAU=.aefb8e0e-7b2f-4bb2-8a34-d5e17844833a@github.com>
 <s9KDA-Z5fZV8wgEJOPLhnY9KjpHalotNcUHnsYMAehg=.127a6d91-8824-4ad3-8bce-204543babcdc@github.com>
Message-ID: <IJcE2nUA_E-kjIU-3s1Jzs4e3-hBUhE-bTjfmE7h-Zc=.2beda10e-d2e3-48d4-b765-034401890189@github.com>

On Tue, 19 Nov 2024 23:55:33 GMT, Alexander Matveev <almatvee at openjdk.org> wrote:

>> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Make path guaranteed to be long enough
>
> test/jdk/tools/jpackage/windows/WinLongPathTest.java line 38:
> 
>> 36: 
>> 37: /*
>> 38: /* @test
> 
> Extra `/`?

No, the leading `/*` is deliberate. I prefer it this way.

There is no consistency in formatting:

https://github.com/openjdk/jdk/blob/8a1f9f0a324e30b5da53d58434ac1b39569fc523/test/hotspot/jtreg/gc/ArraySize.java#L24

https://github.com/openjdk/jdk/blob/8a1f9f0a324e30b5da53d58434ac1b39569fc523/test/jdk/com/sun/jdi/InvokeVarArgs.java#L24

https://github.com/openjdk/jdk/blob/8a1f9f0a324e30b5da53d58434ac1b39569fc523/test/jdk/java/io/File/Mkdir.java#L24

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22092#discussion_r1849432814

From jlu at openjdk.org  Wed Nov 20 03:03:22 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 03:03:22 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v3]
In-Reply-To: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
Message-ID: <vE7O7eohfvzyh6dyKqtUwNl2MgZutk8iz79kckxSttY=.762a5087-9176-4d8d-8bcc-a205d545034f@github.com>

> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change.
> 
> APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
> Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  address Naoto's comments

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22192/files
  - new: https://git.openjdk.org/jdk/pull/22192/files/6b5b5cd0..c8dd75cc

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22192&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22192&range=01-02

  Stats: 13 lines in 1 file changed: 3 ins; 0 del; 10 mod
  Patch: https://git.openjdk.org/jdk/pull/22192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22192/head:pull/22192

PR: https://git.openjdk.org/jdk/pull/22192

From jlu at openjdk.org  Wed Nov 20 03:03:26 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 03:03:26 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v3]
In-Reply-To: <SrzJo73RPFigmAaiueCT3eIwWsTGihps9ScE0I_kuXw=.67aa29f8-d82e-4d67-8e24-415da708d173@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <8W7-Y64Rn1pVLuPfLoAktG-ekfebPelcoWQbxxiEMjE=.f07e118b-99ea-4ef0-909d-6141b08e4a55@github.com>
 <SrzJo73RPFigmAaiueCT3eIwWsTGihps9ScE0I_kuXw=.67aa29f8-d82e-4d67-8e24-415da708d173@github.com>
Message-ID: <Y9OuBynI-KIhZQ_il_zV0csS7SxtBBPN62SFaMf1nJs=.f91540a0-740e-4ded-896c-6f50959e8c5c@github.com>

On Tue, 19 Nov 2024 20:30:11 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address Naoto's comments
>
> src/java.base/share/classes/java/util/Locale.java line 144:
> 
>> 142:  *   each indicating its own semantics, these values should be ordered
>> 143:  *   by importance, with most important first, separated by
>> 144:  *   underscore('_').  The variant field is case sensitive.</dd>
> 
> This part "separated by underscore('_')" is missing in the revised doc

I intentionally omitted this because

- I thought it was redundant as the syntax already follows a few lines below.
- The `Locale` syntax allows both `_` and  `-`, not just `_`.

However, if you think it should remain, I'll restore it as `separated by ('_'|'-')`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1849432988

From jlu at openjdk.org  Wed Nov 20 03:03:24 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 03:03:24 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v2]
In-Reply-To: <SrzJo73RPFigmAaiueCT3eIwWsTGihps9ScE0I_kuXw=.67aa29f8-d82e-4d67-8e24-415da708d173@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <8W7-Y64Rn1pVLuPfLoAktG-ekfebPelcoWQbxxiEMjE=.f07e118b-99ea-4ef0-909d-6141b08e4a55@github.com>
 <SrzJo73RPFigmAaiueCT3eIwWsTGihps9ScE0I_kuXw=.67aa29f8-d82e-4d67-8e24-415da708d173@github.com>
Message-ID: <71Ir0-EYssrJNJcR0Y6ytL2T1eCPdB9c8ERjqDVk-ts=.1bf9e7d9-b24b-4401-a663-0b045dba36be@github.com>

On Tue, 19 Nov 2024 19:46:42 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address Chen's review; make other similar changes
>
> src/java.base/share/classes/java/util/Locale.java line 89:
> 
>> 87:  * exchange. Each {@code Locale} is associated with locale data which is retrieved
>> 88:  * by the installed {@link java.util.spi.LocaleServiceProvider LocaleServiceProvider}
>> 89:  * implementations. Depending on the implementation, such data may vary by release.
> 
> This reads like locale data are only obtained with the SPI implementations that are provided by the users. The locale data also (and mainly) come from within Java runtime itself. (BTW, "installed" should be removed, as it is no longer correct. Same applies to getAvailableLocales()/availableLocales() methods)

Thanks for the review Naoto. 

My angle was that the `"installed LocaleServiceProvider implementations"` implicitly included the Java runtime data as the default provider. The new wording is more explicit, please let me know what you think.

Also, "installed" is now replaced with "deployed" which is consistent with `ServiceLoader`. The rest of your suggestions should be fixed in https://github.com/openjdk/jdk/pull/22192/commits/c8dd75cc738316e34d203cde8a867a77efbca63e (minus the one I left a comment on).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1849432962

From jlu at openjdk.org  Wed Nov 20 03:04:56 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 03:04:56 GMT
Subject: RFR: 8344589: Update IANA Language Subtag Registry to Version
 2024-11-19
Message-ID: <gAQGUkG03O5urb6kto7g-kg9mTz0SrDPLfJj57oky8g=.1f7918c0-7edf-43c8-bd97-4bf050d8f034@github.com>

Please review this PR which keeps the IANA language subtag registry data up to date with release _2024-11-19_.

The changes are trivial and Locale tests pass as expected.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/22265/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22265&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344589
  Stats: 13 lines in 2 files changed: 10 ins; 0 del; 3 mod
  Patch: https://git.openjdk.org/jdk/pull/22265.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22265/head:pull/22265

PR: https://git.openjdk.org/jdk/pull/22265

From jlu at openjdk.org  Wed Nov 20 03:07:28 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 03:07:28 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
Message-ID: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>

Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 

This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).

After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

-------------

Commit messages:
 - init

Changes: https://git.openjdk.org/jdk/pull/22266/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22266&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344525
  Stats: 16 lines in 6 files changed: 0 ins; 0 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/22266.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22266/head:pull/22266

PR: https://git.openjdk.org/jdk/pull/22266

From almatvee at openjdk.org  Wed Nov 20 03:10:15 2024
From: almatvee at openjdk.org (Alexander Matveev)
Date: Wed, 20 Nov 2024 03:10:15 GMT
Subject: RFR: 8289771: jpackage: ResourceEditor error when path is overly
 long on Windows [v3]
In-Reply-To: <IbdCnDfjxPGlrD7cUbMxodzSoP-hAvxPQq8S54i5EAU=.aefb8e0e-7b2f-4bb2-8a34-d5e17844833a@github.com>
References: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
 <IbdCnDfjxPGlrD7cUbMxodzSoP-hAvxPQq8S54i5EAU=.aefb8e0e-7b2f-4bb2-8a34-d5e17844833a@github.com>
Message-ID: <_f2uYYA71FGErI6oh4kaby7QhU93fZM-T0ydjPWlEN8=.1ae6010c-9785-41df-88d1-383e3839c1d4@github.com>

On Tue, 19 Nov 2024 22:07:10 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Fix `ResourceEditor` class to handle long paths.
>> 
>> Based on https://github.com/openjdk/jdk/pull/9384 PR.
>> 
>> This repairs app image building on Windows if the path to jpackage temp directory exceeds 260 (`MAX_PATH`) characters. MSI building is still broken and can NOT be repaired due to WiX's limitations.
>> 
>> Repaired scenario when the `--dest` option references a long path on Windows. Previously jpackage would have failed to build MSI package.
>> 
>> Other changes:
>>  - Rename `Executor.setRemovePath()` into `Executor.setRemovePathEnvVar()` to make the method name match the implementation.
>>  - Move the mutable part of `WixPipeline` class into `WixPipeline.Builder` class.
>>  - Fixed minor flaws in "WinL10nTest.java"
>
> Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Make path guaranteed to be long enough

Marked as reviewed by almatvee (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22092#pullrequestreview-2447250167

From asemenyuk at openjdk.org  Wed Nov 20 03:16:16 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 20 Nov 2024 03:16:16 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v3]
In-Reply-To: <hndlZN69I1KUIJiggSJVeiDyDMOeISljrOnqd-v7Q4c=.c49cb615-b76c-483f-9683-bd45c2dd834b@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <hndlZN69I1KUIJiggSJVeiDyDMOeISljrOnqd-v7Q4c=.c49cb615-b76c-483f-9683-bd45c2dd834b@github.com>
Message-ID: <2oP32_tk1D1sSvDKCYxY3LS66G-fC0HTIVhy8NAahyk=.5919971d-fc75-432c-8267-f393fde851d2@github.com>

On Wed, 20 Nov 2024 01:47:34 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

>> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
>> 
>> I have referred to the following for how to use chcp:
>> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
>> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
>> 
>> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
>> 
>> Thanks
>
> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

Changes requested by asemenyuk (Reviewer).

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 487:

> 485:                 List::stream).toList();
> 486: 
> 487:         return String.format(format, printCommandLine(cmdline), cmdline.size() + 1);

`cmdline.size() + 1` seems to be wrong. It should be `cmdline.size()`.
 ` + 1` was needed previously when was applied to the `args.size()` that didn't count the executable. Sorry, I oversaw this thing in my patch.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22142#pullrequestreview-2447254472
PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1849441641

From iris at openjdk.org  Wed Nov 20 03:19:15 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 20 Nov 2024 03:19:15 GMT
Subject: RFR: 8344589: Update IANA Language Subtag Registry to Version
 2024-11-19
In-Reply-To: <gAQGUkG03O5urb6kto7g-kg9mTz0SrDPLfJj57oky8g=.1f7918c0-7edf-43c8-bd97-4bf050d8f034@github.com>
References: <gAQGUkG03O5urb6kto7g-kg9mTz0SrDPLfJj57oky8g=.1f7918c0-7edf-43c8-bd97-4bf050d8f034@github.com>
Message-ID: <4pglEY5pYSPAU9uW54twpL957kaPZg-fmlqi8fDU_lQ=.265959b6-8f44-4462-8dab-871288aa75d5@github.com>

On Wed, 20 Nov 2024 02:59:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which keeps the IANA language subtag registry data up to date with release _2024-11-19_.
> 
> The changes are trivial and Locale tests pass as expected.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22265#pullrequestreview-2447256614

From asemenyuk at openjdk.org  Wed Nov 20 03:19:15 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 20 Nov 2024 03:19:15 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v3]
In-Reply-To: <hndlZN69I1KUIJiggSJVeiDyDMOeISljrOnqd-v7Q4c=.c49cb615-b76c-483f-9683-bd45c2dd834b@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <hndlZN69I1KUIJiggSJVeiDyDMOeISljrOnqd-v7Q4c=.c49cb615-b76c-483f-9683-bd45c2dd834b@github.com>
Message-ID: <ntz3HJk2HduHC9nQx27-W6cHr2PI6GKBZs0WPnq8tHU=.4e990fb4-ad5f-4cae-8102-028bed452332@github.com>

On Wed, 20 Nov 2024 01:47:34 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

>> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
>> 
>> I have referred to the following for how to use chcp:
>> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
>> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
>> 
>> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
>> 
>> Thanks
>
> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix indent

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 344:

> 342:     private List<String> prefixCommandLineArgs() {
> 343:         if (winEnglishOutput) {
> 344:             return List.of("cmd.exe", "/c", "chcp", "437", ">nul", "2>&1", "&&");

I assume `chcp 437` works as expected. The summary still references `chcp 65001` command.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1849443613

From duke at openjdk.org  Wed Nov 20 04:14:16 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 04:14:16 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v3]
In-Reply-To: <njKLqhR3hSABDW2ZMVjlLNVQ3t04h7PdPH2jXc0nRCo=.64d6e018-fc9d-424e-ba24-712bf9f0e1d0@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <njKLqhR3hSABDW2ZMVjlLNVQ3t04h7PdPH2jXc0nRCo=.64d6e018-fc9d-424e-ba24-712bf9f0e1d0@github.com>
Message-ID: <oC0M9cU5SY5D73SqzpTqb9scZL6ESuw5mKXBWYdy_ec=.a9d5f855-7871-4581-8751-b351fe406809@github.com>

On Fri, 15 Nov 2024 13:25:01 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> The implementation may change, but the name of the function should remain the same.

That certainly makes sense. I changed setWinEnableUTF8 to setWinRunWithEnglishOutput as you suggested.

> I'd run suppress the output of "chcp" command: chcp 65001 >nul 2>&1. This will make its usage transparent for the clients of the "Executor" class.

That's true. I added `> nul2 > & 1` to suppress output of "chcp" command.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1849480383
PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1849480236

From duke at openjdk.org  Wed Nov 20 04:19:14 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 04:19:14 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform
In-Reply-To: <k8TFFj9L-4jrs5MdbLc2qmNqDqxWDlkvorKg8VIcXc4=.c2973a8d-0171-460c-b87e-b49957cde562@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <k8TFFj9L-4jrs5MdbLc2qmNqDqxWDlkvorKg8VIcXc4=.c2973a8d-0171-460c-b87e-b49957cde562@github.com>
Message-ID: <deg4NFjT8gxje-WWRmkLwFw7bMSzX5C7T35zX9JJqZY=.ab9b1878-fead-4633-bf1f-4a15b0f60368@github.com>

On Fri, 15 Nov 2024 14:23:36 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> I'm not sure "65001" is the right choice if the request is to get the output in English. Would "437" or "850" be more appropriate arguments for the "chcp" command?

After receiving your comment, I ran the chcp command on Windows Server 2019 (English locale) and the active code page was 437.
For this reason, I think 437 is more appropriate.
I changed code page from 65001 to 437.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22142#issuecomment-2487376685

From duke at openjdk.org  Wed Nov 20 04:19:17 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 04:19:17 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v3]
In-Reply-To: <njfua6SCISo_zOh2ygIMfEqU5oe77IpZOl8PqFsns74=.8e7959a5-176e-4002-9134-59b530038d60@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <njfua6SCISo_zOh2ygIMfEqU5oe77IpZOl8PqFsns74=.8e7959a5-176e-4002-9134-59b530038d60@github.com>
Message-ID: <Itiwuz3VIkD943kSdXdpPfjYXOnuODbKvZcbEs_m-L0=.0d083d19-c2b0-4f23-ae14-ad876e087801@github.com>

On Fri, 15 Nov 2024 14:20:00 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indent
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 344:
> 
>> 342:             command.add("cmd.exe");
>> 343:             command.add("/c");
>> 344:             command.add("chcp 65001 && " + printCommandLine(executablePath().toString(), args));
> 
> `printCommandLine()` function does a lousy job of escaping whitespaces in arguments. Its output is for logging purposes only. 
> 
> I experimented with the use of "chcp" in the "Executor" class and figured that it is not necessary to put the entire command line in a single argument. Please take a look at https://github.com/openjdk/jdk/commit/7975a8e97485b999691b986a78b1e0b47a9b30a1. It suppresses the output of "chcp" command, so client code may remain unchanged. Need to add the missing `setWinEnableUTF8()` and good to go.

Sorry for the incorrect use of `printCommandLine()`.

As I checked, I could certainly execute "chcp" without putting the entire command line in a single argument. I fixed referring to https://github.com/openjdk/jdk/commit/7975a8e97485b999691b986a78b1e0b47a9b30a1. Thanks.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1849482866

From duke at openjdk.org  Wed Nov 20 04:22:48 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 04:22:48 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v4]
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <5Y0MQng8FBGkm4iUYrEucI2hRz459l8DeN_iBN9Am94=.074c220f-cbf6-4410-a05f-6810397ccc3b@github.com>

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 65001". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:

  Fix about size of cmdline

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22142/files
  - new: https://git.openjdk.org/jdk/pull/22142/files/0d9fee82..9181324f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=02-03

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22142/head:pull/22142

PR: https://git.openjdk.org/jdk/pull/22142

From duke at openjdk.org  Wed Nov 20 04:25:15 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 04:25:15 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v3]
In-Reply-To: <2oP32_tk1D1sSvDKCYxY3LS66G-fC0HTIVhy8NAahyk=.5919971d-fc75-432c-8267-f393fde851d2@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <hndlZN69I1KUIJiggSJVeiDyDMOeISljrOnqd-v7Q4c=.c49cb615-b76c-483f-9683-bd45c2dd834b@github.com>
 <2oP32_tk1D1sSvDKCYxY3LS66G-fC0HTIVhy8NAahyk=.5919971d-fc75-432c-8267-f393fde851d2@github.com>
Message-ID: <U71lhkMv37Y7bCzk1DOu8Hlkdvp1p-z3LMNsf7j5kKM=.5a1b5211-79d2-46dd-8a8e-d85497238c02@github.com>

On Wed, 20 Nov 2024 03:13:23 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indent
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 487:
> 
>> 485:                 List::stream).toList();
>> 486: 
>> 487:         return String.format(format, printCommandLine(cmdline), cmdline.size() + 1);
> 
> `cmdline.size() + 1` seems to be wrong. It should be `cmdline.size()`.
>  ` + 1` was needed previously when was applied to the `args.size()` that didn't count the executable. Sorry, I oversaw this thing in my patch.

Thanks, I understood why `+ 1` is not needed. I removed `+ 1`.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1849494766

From duke at openjdk.org  Wed Nov 20 04:31:20 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 04:31:20 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v4]
In-Reply-To: <5Y0MQng8FBGkm4iUYrEucI2hRz459l8DeN_iBN9Am94=.074c220f-cbf6-4410-a05f-6810397ccc3b@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <5Y0MQng8FBGkm4iUYrEucI2hRz459l8DeN_iBN9Am94=.074c220f-cbf6-4410-a05f-6810397ccc3b@github.com>
Message-ID: <3tSyYU3CAe-VbkRryTdHPWv-pOr1pBp6k6rDPbOSjWA=.ae02e83d-e8ad-44e0-83f4-7f780b3f552f@github.com>

On Wed, 20 Nov 2024 04:22:48 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

>> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 437". This ensures that the encoding is UTF8 and that the English message "No Instance(s) Available." is output on localized windows platforms.
>> 
>> I have referred to the following for how to use chcp:
>> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
>> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
>> 
>> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
>> 
>> Thanks
>
> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix about size of cmdline

After making these fixes, I ran tools/jpackage tests importing `Executor` or `WindowsHelper.killAppLauncherProcess` on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22142#issuecomment-2487396860

From duke at openjdk.org  Wed Nov 20 04:31:21 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Wed, 20 Nov 2024 04:31:21 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v3]
In-Reply-To: <ntz3HJk2HduHC9nQx27-W6cHr2PI6GKBZs0WPnq8tHU=.4e990fb4-ad5f-4cae-8102-028bed452332@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <hndlZN69I1KUIJiggSJVeiDyDMOeISljrOnqd-v7Q4c=.c49cb615-b76c-483f-9683-bd45c2dd834b@github.com>
 <ntz3HJk2HduHC9nQx27-W6cHr2PI6GKBZs0WPnq8tHU=.4e990fb4-ad5f-4cae-8102-028bed452332@github.com>
Message-ID: <p69Zfdd2wYzYnr_Q09I-BfRoV4kkuyyAdGt8cnKz7FQ=.1a14df24-997a-4300-82f0-1ab060f9753d@github.com>

On Wed, 20 Nov 2024 03:16:47 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix indent
>
> test/jdk/tools/jpackage/helpers/jdk/jpackage/test/Executor.java line 344:
> 
>> 342:     private List<String> prefixCommandLineArgs() {
>> 343:         if (winEnglishOutput) {
>> 344:             return List.of("cmd.exe", "/c", "chcp", "437", ">nul", "2>&1", "&&");
> 
> I assume `chcp 437` works as expected. The summary still references `chcp 65001` command.

Yes, I confirmed that it works as expected. 

> The summary still references chcp 65001 command.

Thanks, I fixed summary.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22142#discussion_r1849501309

From lbourges at openjdk.org  Wed Nov 20 06:07:15 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 20 Nov 2024 06:07:15 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <sKK36C_3uK71m8PPYisvl9-SWAvr-_TY8RJtRbFEark=.86fc6127-ce47-4359-92d4-a795e53fe609@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

LGTM

-------------

Marked as reviewed by lbourges (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2447514188

From duke at openjdk.org  Wed Nov 20 06:42:52 2024
From: duke at openjdk.org (kabutz)
Date: Wed, 20 Nov 2024 06:42:52 GMT
Subject: RFR: 8344595: Naming incorrect for WAIT state in VirtualThread
 documentation
Message-ID: <o2GTTWzwJoKfc5yzzqCPasvgpeMOAVrI8OInUTIYLy4=.77ff531b-68b5-4f27-b4d6-2cdc119cde53@github.com>

See internal bug review 9077848

This is a very small unimportant mistake in the naming of the documentation that does not match the code.

-------------

Commit messages:
 - Made documentation match state field names WAIT and TIMED_WAIT

Changes: https://git.openjdk.org/jdk/pull/22253/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22253&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344595
  Stats: 6 lines in 1 file changed: 0 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22253.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22253/head:pull/22253

PR: https://git.openjdk.org/jdk/pull/22253

From jpai at openjdk.org  Wed Nov 20 06:52:11 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Nov 2024 06:52:11 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v4]
In-Reply-To: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
Message-ID: <MLAhSPSnolwYpL-AFTEAH1QVSYjPt99zKXBxGxK-w-g=.5bfe2263-f887-4cca-a214-852b03c10cfd@github.com>

> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
> 
> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
> 
> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - merge latest from master branch
 - Alan's review - fix code comment
 - merge latest from master branch
 - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22233/files
  - new: https://git.openjdk.org/jdk/pull/22233/files/1c26dbf2..14664538

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22233&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22233&range=02-03

  Stats: 5325 lines in 283 files changed: 1839 ins; 2432 del; 1054 mod
  Patch: https://git.openjdk.org/jdk/pull/22233.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22233/head:pull/22233

PR: https://git.openjdk.org/jdk/pull/22233

From jpai at openjdk.org  Wed Nov 20 06:52:12 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Nov 2024 06:52:12 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v3]
In-Reply-To: <0vLDna2xJ3urJPGq2vPhglcjH8tEfnFtnx2-0ji2_to=.c270f275-753c-4934-ad74-f6dfc694b266@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <0vLDna2xJ3urJPGq2vPhglcjH8tEfnFtnx2-0ji2_to=.c270f275-753c-4934-ad74-f6dfc694b266@github.com>
Message-ID: <1NbyA5w1rkuWYXhs3bG9w9SsrKDDINB4b4aTLPemOt8=.bdb6920f-d879-4685-b4ce-9dad1e68efee@github.com>

On Tue, 19 Nov 2024 12:54:18 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>> 
>> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
>> 
>> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
>> 
>> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Alan's review - fix code comment

The CSR for this has been approved and the latest state of this PR continues to pass tier1 and tier2 testing.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22233#issuecomment-2487633519

From alanb at openjdk.org  Wed Nov 20 07:00:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 07:00:14 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <f-3Cf4AhtV60tWd3TCBpsh1XJzIL5_tUAlazi-MJ92U=.721546e9-49e0-40e2-8b4c-bc8aa398af33@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

Some of these were checking if ExceptionOccurred(env) returns NULL so were readable, moving them to ExceptionCheck is fine, and a bit more efficient when there is a pending exception.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2447595468

From lbourges at openjdk.org  Wed Nov 20 07:23:14 2024
From: lbourges at openjdk.org (Laurent =?UTF-8?B?Qm91cmfDqHM=?=)
Date: Wed, 20 Nov 2024 07:23:14 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <wHmw4bi338AdR6fsLyLk2V4UOZmALKvIOOJhiG1Ngos=.e18a9038-5faa-4b28-aa29-ed6543c8e00c@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

I will check today if any 'bad' pattern is remaining in the openjdk master source folder... to be sure.

Maybe improving jni documentation would be great in another issue...

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22266#issuecomment-2487698104

From alanb at openjdk.org  Wed Nov 20 07:46:16 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 07:46:16 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v2]
In-Reply-To: <w3R1Ab4uKMmtwnFN0UCWDAZwvKVsUR2qHrwCXtPoIgI=.1a7cb021-e8ca-43fe-889a-c414da3c0839@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
 <w3R1Ab4uKMmtwnFN0UCWDAZwvKVsUR2qHrwCXtPoIgI=.1a7cb021-e8ca-43fe-889a-c414da3c0839@github.com>
Message-ID: <IkSLDSGsV14XuJHBqp68fXZpfece57VBdfJbv8HkWp8=.5f45d112-94ba-4359-8e0e-686185675140@github.com>

On Mon, 18 Nov 2024 19:22:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions applied:
>   Remove SecurityExceptions from LiveStackFrame
>   Rename safeTrim to trimArray

What about System.codeSource? I assume it can be removed and Module.ensureNativeAccess changed to get the code source itself (no SM check needed now).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22168#issuecomment-2487753723

From alanb at openjdk.org  Wed Nov 20 08:14:23 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 08:14:23 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
 <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
Message-ID: <IBl9XOE-kYirsjhTT87ROdqmLcmcV6HnE1pSN96Gq0M=.6ce514d2-393e-4001-a0d2-a5e681ec061c@github.com>

On Tue, 19 Nov 2024 16:57:05 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> Doug Lea has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager
>
> src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 247:
> 
>> 245:         = U.objectFieldOffset(Thread.class, "threadLocals");
>> 246:     private static final long INHERITABLETHREADLOCALS
>> 247:         = U.objectFieldOffset(Thread.class, "inheritableThreadLocals");
> 
> @AlanBateman Thoughts here? ?

resetThreadLocals looks good although. A discussion point is whether it the reset should be done for all FJP instances, not just the common pool but not this PR.

> src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 270:
> 
>> 268:         @SuppressWarnings("removal")
>> 269:         public void setContextClassLoader(ClassLoader cl) {
>> 270:             if (System.getSecurityManager() != null &&
> 
> @AlanBateman Alternatives for this? ?

I don't think it needs an alternative, instead L270-272 will be removed as part of the SM cleanup.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1849809984
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1849810047

From alanb at openjdk.org  Wed Nov 20 08:17:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 08:17:18 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory
In-Reply-To: <4z7Uv78Pb5MBXrDlyKpslavdKaycMuEJy6u1oe8nboQ=.9a089a01-b85b-4896-b50b-553d6a433ff1@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <4z7Uv78Pb5MBXrDlyKpslavdKaycMuEJy6u1oe8nboQ=.9a089a01-b85b-4896-b50b-553d6a433ff1@github.com>
Message-ID: <vA4RTwWw1T7OPwE2qfCYnQIWzXEZCwt0ilcvZMieDoI=.4a4c841d-483e-46df-9d9e-4864e107ea22@github.com>

On Sat, 29 Jun 2024 07:31:44 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> I skimmed through the latest update (d137f43) and I think you've got this to a good place and a sensible/workable proposal. I've asked from help from others on the security review of this.
> 
> Right now, I'm still wonder if defaultReadObjectForSerialization/defaultWriteObjectForSerialization should return the same as readObjectForSerialization/writeObjectForSerialization when the readObject/writeObject methods are defined. This is more of a concern for a class with a readObject of course as that readObject will likely check invariants that would be bypassed if the serialization library always uses the defaultXXX methods.
> 
> I'd probably drop the "Of" suffix from serialPersistentFieldsOf and serialVersionUIDOf but naming isn't important right now.

> still good @AlanBateman may want to review too.

I was in the initial discussion with David and okay with where this ended up. I reviewed the CSR. I don't have cycles right now to go through all the changes but happy to see that you and Chen have worked through it.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2487843295

From shade at openjdk.org  Wed Nov 20 09:19:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 20 Nov 2024 09:19:39 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:

  Check all elements are removable after random test

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/8b53bc83..63322b76

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=13
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=12-13

  Stats: 7 lines in 1 file changed: 7 ins; 0 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Wed Nov 20 09:19:39 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Wed, 20 Nov 2024 09:19:39 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v13]
In-Reply-To: <mCB4jmb-VnRYjydf7J8alcX5IgNa1Q9lcZcmCO6yYXY=.cc955bf8-4046-495e-ab95-64e7c8ec62ad@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <pXpDzNzwVroE1zDlS0-B6wyaKjbVxbAm4nRZbjgTFNU=.7279b591-6d30-4243-be70-33dc5d1ca778@github.com>
 <mCB4jmb-VnRYjydf7J8alcX5IgNa1Q9lcZcmCO6yYXY=.cc955bf8-4046-495e-ab95-64e7c8ec62ad@github.com>
Message-ID: <fHAWmugBU3p2oJ3U6vqJtMiK1gkdH25Rr3alEwmSCfU=.0aabe5b8-a5ee-4b00-883e-4ae047093487@github.com>

On Wed, 20 Nov 2024 00:50:01 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Use RandomFactory in test
>
> src/java.base/share/classes/jdk/internal/ref/PhantomCleanable.java line 55:
> 
>> 53:      * Synchronized by the same lock as the list itself.
>> 54:      */
>> 55:     CleanerImpl.CleanableList.Node node;
> 
> I think we can get away with not storing a `Node` in every `PhantomCleanable`, and instead look for it at `index` in each `Node` in the list. But I don't know if this would be a performance win. Heap savings (in `PhantomCleanableRef`)? Worse locality from loading multiple `Nodes`?
> Just an idea...

I don't think this is a great idea: it means linear search under the lock, which I don't think we want. As it stands now, we are doing removals in constant time. Current version also affects the footprint positively already: we change 3 references into 2 references + 1 int, so there is no pressing need for smartness in optimizing the footprint.

> test/jdk/jdk/internal/ref/Cleaner/CleanableListTest.java line 126:
> 
>> 124:                 bs.set(idx, true);
>> 125:             }
>> 126:         }
> 
> Can the test remove everything left in the list after doing the `RANDOM_ITERATIONS`?

Done in new commit.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1849918892
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1849920309

From jpai at openjdk.org  Wed Nov 20 09:42:46 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Nov 2024 09:42:46 GMT
Subject: RFR: 8344524: Remove SecurityManager related code from jdk.jlink
 module
Message-ID: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>

Can I please get a review for this change which removes SecurityManager usages from `jdk.jlink` module? This addresses https://bugs.openjdk.org/browse/JDK-8344524.

The internal class `jdk.tools.jlink.internal.JlinkPermission` too has been removed as part of this change.

No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

-------------

Commit messages:
 - 8344524: Remove SecurityManager related code from jdk.jlink module

Changes: https://git.openjdk.org/jdk/pull/22268/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22268&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344524
  Stats: 61 lines in 3 files changed: 0 ins; 60 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22268.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22268/head:pull/22268

PR: https://git.openjdk.org/jdk/pull/22268

From alanb at openjdk.org  Wed Nov 20 09:52:13 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 09:52:13 GMT
Subject: RFR: 8344524: Remove SecurityManager related code from jdk.jlink
 module
In-Reply-To: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
References: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
Message-ID: <n0m9rAodtD7KNRJ1JyHs2T5STTs2RGfwrBNVTTY1hzM=.75bf42c6-a5c2-4d3e-9ffb-cb3433d73c38@github.com>

On Wed, 20 Nov 2024 09:38:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which removes SecurityManager usages from `jdk.jlink` module? This addresses https://bugs.openjdk.org/browse/JDK-8344524.
> 
> The internal class `jdk.tools.jlink.internal.JlinkPermission` too has been removed as part of this change.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Looks fine.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22268#pullrequestreview-2448100849

From vklang at openjdk.org  Wed Nov 20 10:39:27 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Nov 2024 10:39:27 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <IBl9XOE-kYirsjhTT87ROdqmLcmcV6HnE1pSN96Gq0M=.6ce514d2-393e-4001-a0d2-a5e681ec061c@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
 <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
 <IBl9XOE-kYirsjhTT87ROdqmLcmcV6HnE1pSN96Gq0M=.6ce514d2-393e-4001-a0d2-a5e681ec061c@github.com>
Message-ID: <jOo8Mk-rgx1spZA7UD6UuYOSsz7hxvznaw1L63Uil9w=.88b4beab-fa60-4ab2-b7a8-ac2e557ec167@github.com>

On Wed, 20 Nov 2024 08:11:34 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 247:
>> 
>>> 245:         = U.objectFieldOffset(Thread.class, "threadLocals");
>>> 246:     private static final long INHERITABLETHREADLOCALS
>>> 247:         = U.objectFieldOffset(Thread.class, "inheritableThreadLocals");
>> 
>> @AlanBateman Thoughts here? ?
>
> resetThreadLocals looks good although. A discussion point is whether reset should be done for all FJP instances, not just the common pool but not this PR.

Thanks Alan. Yes, I think it should be considered to do it for all FJP instances.

>> src/java.base/share/classes/java/util/concurrent/ForkJoinWorkerThread.java line 270:
>> 
>>> 268:         @SuppressWarnings("removal")
>>> 269:         public void setContextClassLoader(ClassLoader cl) {
>>> 270:             if (System.getSecurityManager() != null &&
>> 
>> @AlanBateman Alternatives for this? ?
>
> I don't think it needs an alternative, instead L270-272 will be removed as part of the SM cleanup.

Sounds like a good plan ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1850053209
PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1850054254

From vklang at openjdk.org  Wed Nov 20 10:39:25 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Wed, 20 Nov 2024 10:39:25 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <bD9XwVkdFqAnZhKqcphbDcs26qNS0_9C0JiFB4oISnY=.f20f0d40-765f-488e-9012-2492f4660468@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
 <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
 <bD9XwVkdFqAnZhKqcphbDcs26qNS0_9C0JiFB4oISnY=.f20f0d40-765f-488e-9012-2492f4660468@github.com>
Message-ID: <pLcLS8vO6uuRc6xgTF87mFSYdmXoGNjdgDkAKv-xLZ4=.a6804e5b-981b-4f4a-afd2-a76d2ec5e0e6@github.com>

On Tue, 19 Nov 2024 19:12:29 GMT, Doug Lea <dl at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/concurrent/ForkJoinPool.java line 4082:
>> 
>>> 4080:             AccessController.doPrivileged(new PrivilegedAction<>() {
>>> 4081:                     public ForkJoinPool run() {
>>> 4082:                         return new ForkJoinPool((byte)0); }});
>> 
>> @AlanBateman Any recommendation as to what is ideal here with SM removed? /cc @DougLea
>
> I  moved this to end so that in next pass with SM removed, the static init will end with just:
> common = new ForkJoinPool((byte)0).
> (Which will be sure to be done after all the other static init finiahes.)

@DougLea I must've forgotten about addressing SM separately. ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1850050926

From alanb at openjdk.org  Wed Nov 20 10:41:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 10:41:17 GMT
Subject: RFR: 8344595: Naming incorrect for WAIT state in VirtualThread
 documentation
In-Reply-To: <o2GTTWzwJoKfc5yzzqCPasvgpeMOAVrI8OInUTIYLy4=.77ff531b-68b5-4f27-b4d6-2cdc119cde53@github.com>
References: <o2GTTWzwJoKfc5yzzqCPasvgpeMOAVrI8OInUTIYLy4=.77ff531b-68b5-4f27-b4d6-2cdc119cde53@github.com>
Message-ID: <Pl_YbknNxlm6IKB3J-kJQQro5po7ByoZAdXl04jPTVk=.30352eab-9904-4e2d-b171-12d3e1e0aff1@github.com>

On Tue, 19 Nov 2024 19:33:18 GMT, kabutz <duke at openjdk.org> wrote:

> See internal bug review 9077848
> 
> This is a very small unimportant mistake in the naming of the documentation that does not match the code.

Thanks, this comment was missed in the loom repo when we did the last rename.

You'll need to adjust the PR title to match the JBS issue before integrating.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22253#pullrequestreview-2448219550

From jpai at openjdk.org  Wed Nov 20 10:56:23 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Nov 2024 10:56:23 GMT
Subject: RFR: 8344540: Remove superseded wildcard description from java
 manpage
In-Reply-To: <IX-jo6P0nLWkVZJrUcDwyuo3T8VVmRYoG0C-hkM439k=.c6e06daa-7aed-4c56-a92e-43642147e9b6@github.com>
References: <IX-jo6P0nLWkVZJrUcDwyuo3T8VVmRYoG0C-hkM439k=.c6e06daa-7aed-4c56-a92e-43642147e9b6@github.com>
Message-ID: <ke7e7WXZbQEUyjrzH8Ee9EHALwTTIMdxLJag_2eQAD0=.fbf7995c-6222-4e77-82d4-e1c4a0a3cb6c@github.com>

On Tue, 19 Nov 2024 11:12:01 GMT, Christian Stein <cstein at openjdk.org> wrote:

> Please review this follow-up PR to improve `java`'s manpage section about wildcards in argument files: the confusing sentence is now removed.
> 
> This is a cleanup of commit https://github.com/openjdk/jdk/commit/5cb0d438231383d491b2fcca455d09af7f2ee016

Hello Christian, I think this change in the description of the syntax for arg files is accurate and removes any confusion. 

While at it, I think we should also do a small update to the following line in the section "Using the JDK_JAVA_OPTIONS Launcher Environment Variable":

> However, as in `@`-files, use of a wildcard is not supported.

Based on what I see in the launcher code which handles the `JDK_JAVA_OPTIONS` environment variable, I think we should just change it to:

> The wildcard literal `*` isn't expanded and is passed as-is to the `java` launcher.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22236#issuecomment-2488254734

From cstein at openjdk.org  Wed Nov 20 11:20:38 2024
From: cstein at openjdk.org (Christian Stein)
Date: Wed, 20 Nov 2024 11:20:38 GMT
Subject: RFR: 8344540: Remove superseded wildcard description from java
 manpage [v2]
In-Reply-To: <IX-jo6P0nLWkVZJrUcDwyuo3T8VVmRYoG0C-hkM439k=.c6e06daa-7aed-4c56-a92e-43642147e9b6@github.com>
References: <IX-jo6P0nLWkVZJrUcDwyuo3T8VVmRYoG0C-hkM439k=.c6e06daa-7aed-4c56-a92e-43642147e9b6@github.com>
Message-ID: <3UvLupHPQtWPOuWUuEOjasx4aZrkqT1SswqQihJY8KM=.78f14adb-a573-47ec-9da1-90f7feff6231@github.com>

> Please review this follow-up PR to improve `java`'s manpage section about wildcards in argument files: the confusing sentence is now removed.
> 
> This is a cleanup of commit https://github.com/openjdk/jdk/commit/5cb0d438231383d491b2fcca455d09af7f2ee016

Christian Stein has updated the pull request incrementally with one additional commit since the last revision:

  Update section as suggested

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22236/files
  - new: https://git.openjdk.org/jdk/pull/22236/files/bf9192e9..9e03b4e7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22236&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22236&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22236.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22236/head:pull/22236

PR: https://git.openjdk.org/jdk/pull/22236

From dfuchs at openjdk.org  Wed Nov 20 11:36:42 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 11:36:42 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
 <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
Message-ID: <5tT_WNZzZaDh-K5jUWrbGGsmPX3wMqUmfoXsLqg0-nM=.cb3da770-c85a-4fcd-96f6-f6396f29739f@github.com>

On Tue, 19 Nov 2024 20:33:35 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarify factory location usages in NamingManager and jdk.naming.rmi module-info
>
> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 262:
> 
>> 260:         }
>> 261: 
>> 262:         worker = new Thread(this);
> 
> Rataining a static factory for thread may use useful to be able to customize thread behavior.
> 
> It should be considered that the new threads are Virtual threads:
>  i.e.  `Thread.ofVirtual().startVirtualThread(Runnable)`

This is a good point but orthogonal to the issue we're fixing here. If we decide to change the implementation to use VirtualThread it may have some impact, such as read/receive becoming interruptible. So I believe this kind of enhancement should be carried in their own PR.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850154290

From dfuchs at openjdk.org  Wed Nov 20 11:41:18 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 11:41:18 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
 <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
Message-ID: <0GeqJaNQKdQbysUR5q6VH4Dz0wJnpMffPZgpXjKHpjI=.bb731579-a208-4852-a3d3-1dd6edbea12a@github.com>

On Tue, 19 Nov 2024 20:38:02 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarify factory location usages in NamingManager and jdk.naming.rmi module-info
>
> src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java line 163:
> 
>> 161:     InputStream getJavaHomeConfStream(String filename) {
>> 162:         try {
>> 163:             String javahome = System.getProperty("java.home");
> 
> StaticProperty.javaHome() is available as a stable value for the property.

Good point too - but that would require am additional qualified export of `jdk.internal.util` from `java.base` to `java.naming`. I'm not sure it's worth it. I mean - keeping qualified exports as few as possible is also a worthy goal.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850162238

From lancea at openjdk.org  Wed Nov 20 12:16:15 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 20 Nov 2024 12:16:15 GMT
Subject: RFR: 8344524: Remove SecurityManager related code from jdk.jlink
 module
In-Reply-To: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
References: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
Message-ID: <hGLBptuBBvolkCBCohEwGN3Mr0ogFf6mZVdXrsX9qyw=.bb0d67f1-f63e-4e1b-b3b2-a3ac3444f20e@github.com>

On Wed, 20 Nov 2024 09:38:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which removes SecurityManager usages from `jdk.jlink` module? This addresses https://bugs.openjdk.org/browse/JDK-8344524.
> 
> The internal class `jdk.tools.jlink.internal.JlinkPermission` too has been removed as part of this change.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22268#pullrequestreview-2448454639

From rgiulietti at openjdk.org  Wed Nov 20 12:17:21 2024
From: rgiulietti at openjdk.org (Raffaello Giulietti)
Date: Wed, 20 Nov 2024 12:17:21 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v20]
In-Reply-To: <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
 <_fJUaRv1a31e9yfp1cnd1qSfko_CHTgf4f9Tp3-kWTQ=.65808a89-1f55-4af2-9b5f-bfdafd1ad997@github.com>
 <WK5BOIRwpTqhEQPuU9MJJkeLFEjpLb4d5sh-M6tHB9E=.5bc06522-cb40-417a-bcfe-1774cbe80184@github.com>
Message-ID: <Qm_r0sXvrI1XasnYOzSNcLDrMgY3Uo2X0RFUVaceFZ4=.75a6b141-9bf1-4c6d-9f19-c5ca6351f464@github.com>

On Tue, 19 Nov 2024 18:44:51 GMT, Raffaello Giulietti <rgiulietti at openjdk.org> wrote:

>> fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Correct remainder checking
>
> src/java.base/share/classes/java/math/BigDecimal.java line 2260:
> 
>> 2258:                     }
>> 2259: 
>> 2260:                     default -> throw new AssertionError("Unexpected value for RoundingMode: " + mc.roundingMode);
> 
> I think `MatchException` might be better suited (with a `null` cause), but I'll crosscheck and let you know tomorrow.

You can leave `AssertionError` as it is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21301#discussion_r1850215392

From lancea at openjdk.org  Wed Nov 20 12:18:17 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 20 Nov 2024 12:18:17 GMT
Subject: RFR: 8344589: Update IANA Language Subtag Registry to Version
 2024-11-19
In-Reply-To: <gAQGUkG03O5urb6kto7g-kg9mTz0SrDPLfJj57oky8g=.1f7918c0-7edf-43c8-bd97-4bf050d8f034@github.com>
References: <gAQGUkG03O5urb6kto7g-kg9mTz0SrDPLfJj57oky8g=.1f7918c0-7edf-43c8-bd97-4bf050d8f034@github.com>
Message-ID: <a6aTLSlFrpIK23LQObn65ZsIVkGCbAAudCTYd83G46M=.a66de53c-2dd3-4432-9ea0-5f2eaa8c83a5@github.com>

On Wed, 20 Nov 2024 02:59:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which keeps the IANA language subtag registry data up to date with release _2024-11-19_.
> 
> The changes are trivial and Locale tests pass as expected.

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22265#pullrequestreview-2448458803

From dfuchs at openjdk.org  Wed Nov 20 12:38:17 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 12:38:17 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v4]
In-Reply-To: <MLAhSPSnolwYpL-AFTEAH1QVSYjPt99zKXBxGxK-w-g=.5bfe2263-f887-4cca-a214-852b03c10cfd@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <MLAhSPSnolwYpL-AFTEAH1QVSYjPt99zKXBxGxK-w-g=.5bfe2263-f887-4cca-a214-852b03c10cfd@github.com>
Message-ID: <ZAnvR2M752JghBpBCELAT6icFIu2h6en5PG9XthQOps=.ea6667f6-8210-4c2c-94d4-8eca8f8b9117@github.com>

On Wed, 20 Nov 2024 06:52:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>> 
>> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
>> 
>> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
>> 
>> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - merge latest from master branch
>  - Alan's review - fix code comment
>  - merge latest from master branch
>  - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

Not an expert here but those changes look good to me. It's good to see all this complicated code go away!

-------------

PR Review: https://git.openjdk.org/jdk/pull/22233#pullrequestreview-2448502485

From yzheng at openjdk.org  Wed Nov 20 12:44:28 2024
From: yzheng at openjdk.org (Yudi Zheng)
Date: Wed, 20 Nov 2024 12:44:28 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v4]
In-Reply-To: <MLAhSPSnolwYpL-AFTEAH1QVSYjPt99zKXBxGxK-w-g=.5bfe2263-f887-4cca-a214-852b03c10cfd@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <MLAhSPSnolwYpL-AFTEAH1QVSYjPt99zKXBxGxK-w-g=.5bfe2263-f887-4cca-a214-852b03c10cfd@github.com>
Message-ID: <-2yZS7G3SZA2DtrCXYv-peKcJ1s8XIGULnY-y2Ck4FY=.e41bec02-f549-4257-8613-6749ef123519@github.com>

On Wed, 20 Nov 2024 06:52:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>> 
>> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
>> 
>> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
>> 
>> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - merge latest from master branch
>  - Alan's review - fix code comment
>  - merge latest from master branch
>  - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

Marked as reviewed by yzheng (Committer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22233#pullrequestreview-2448510144

From jpai at openjdk.org  Wed Nov 20 12:44:29 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Nov 2024 12:44:29 GMT
Subject: Integrated: 8344223: Remove calls to SecurityManager and doPrivileged
 in java.net.URLClassLoader after JEP 486 integration
In-Reply-To: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
Message-ID: <gcYTJ23Q1eNm5tFxSbD3KSDfo901F2C930-1OfcnLNE=.43eec614-aec2-41f4-bbef-e50eb5ad969a@github.com>

On Tue, 19 Nov 2024 10:32:37 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
> 
> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
> 
> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.

This pull request has now been integrated.

Changeset: db7ee3da
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/db7ee3dad1d9c9578794d946dd5de1f51d77e5a1
Stats:     423 lines in 3 files changed: 26 ins; 311 del; 86 mod

8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

Reviewed-by: alanb, yzheng

-------------

PR: https://git.openjdk.org/jdk/pull/22233

From jpai at openjdk.org  Wed Nov 20 12:44:28 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Wed, 20 Nov 2024 12:44:28 GMT
Subject: RFR: 8344223: Remove calls to SecurityManager and doPrivileged in
 java.net.URLClassLoader after JEP 486 integration [v4]
In-Reply-To: <MLAhSPSnolwYpL-AFTEAH1QVSYjPt99zKXBxGxK-w-g=.5bfe2263-f887-4cca-a214-852b03c10cfd@github.com>
References: <qnxvNl2WDZA6VmIKJH80YOluq3CcDAlveSJ07b6WfzA=.276ad9e9-c712-499f-b0f1-dc0ab0759995@github.com>
 <MLAhSPSnolwYpL-AFTEAH1QVSYjPt99zKXBxGxK-w-g=.5bfe2263-f887-4cca-a214-852b03c10cfd@github.com>
Message-ID: <64ngIVK6Aa_TQsCOHaJ8wEr2CVROp0qPq5TCp8eGMH4=.84b26f16-f6e4-42a3-b365-3d117853bac7@github.com>

On Wed, 20 Nov 2024 06:52:11 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Can I please get a review of this change which proposes to remove SecurityManager related API usages from `URLClassLoader` and its related `URLClassPath`? This addresses https://bugs.openjdk.org/browse/JDK-8344223.
>> 
>> The `URLClassLoader.getPermissions()` method will need additional changes but that will be done as part of https://bugs.openjdk.org/browse/JDK-8343150.
>> 
>> I'll be opening a CSR for this change because we are removing support for the `jdk.net.URLClassPath.disableRestrictedPermissions` system property.
>> 
>> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass.
>
> Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:
> 
>  - merge latest from master branch
>  - Alan's review - fix code comment
>  - merge latest from master branch
>  - 8344223: Remove calls to SecurityManager and doPrivileged in java.net.URLClassLoader after JEP 486 integration

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22233#issuecomment-2488483292

From duke at openjdk.org  Wed Nov 20 12:45:30 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 20 Nov 2024 12:45:30 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <TD-csPnwHYIXSW-TzudiqSAbMDWybBnXD-0lgs3sZiQ=.ace58928-ca40-4421-ad18-59f181176f4f@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2488486010

From duke at openjdk.org  Wed Nov 20 12:45:30 2024
From: duke at openjdk.org (duke)
Date: Wed, 20 Nov 2024 12:45:30 GMT
Subject: RFR: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory [v11]
In-Reply-To: <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
 <yLADjTSvUk_dPNuuTgzqJIo4sUu3dvT_cjyQbNmbOVc=.965dc293-b709-4075-98b1-324ef14d7b33@github.com>
Message-ID: <0RjgFYED39PYL53L6KVVbQDXc72Gfc-FmLQ1qmGZMNQ=.886a32a8-6d14-4999-8d03-39a8f46b377d@github.com>

On Thu, 14 Nov 2024 15:10:37 GMT, David M. Lloyd <duke at openjdk.org> wrote:

>> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
>> 
>> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
>> 
>> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
>> 
>> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
>> cc: @AlanBateman
>
> David M. Lloyd has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 40 commits:
> 
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Address review feedback
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Merge remote-tracking branch 'upstream-jdk/master' into serialization
>  - Round out the documentation of the new methods to explain the supported and unsupported cases
>  - Move `serialPersistentFields` for a degree of method order consistency
>  - Address review feedback
>  - Test fixes and finish renaming
>  - Address review feedback
>  - Address review comment
>  - ... and 30 more: https://git.openjdk.org/jdk/compare/752e1629...8b83bd70

@dmlloyd 
Your change (at version 8b83bd703cdd898dda0d79b3b448f37c68dc0efb) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/19702#issuecomment-2488487584

From duke at openjdk.org  Wed Nov 20 13:00:34 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 20 Nov 2024 13:00:34 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v21]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <kNAVcuDc61DdBIppzqVaVURpFE5U9IuEP6uX2PnG6Wc=.79d0928d-d41b-4aa5-b17c-80381c3ce7b1@github.com>

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
> 
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
> 
> x = y * 10 ^ exp
> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
> 
> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
> 
> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplifications

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/2834b49e..0fff4c5e

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=20
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=19-20

  Stats: 114 lines in 1 file changed: 33 ins; 38 del; 43 mod
  Patch: https://git.openjdk.org/jdk/pull/21301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21301/head:pull/21301

PR: https://git.openjdk.org/jdk/pull/21301

From aefimov at openjdk.org  Wed Nov 20 13:06:57 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 20 Nov 2024 13:06:57 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v4]
In-Reply-To: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
Message-ID: <BAQA7nkp3XVKrSteHNTrbFC1DnexNf0uzP82ILYMOss=.cd21ef03-c4d4-4a02-b4e7-75d1dafaa998@github.com>

> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
> - The following two properties are removed:
>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>     - `com.sun.jndi.rmi.object.trustURLCodebase`
> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
> 
> These changes require a CSR that will be submitted soon.
> 
> ### Testing
> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.

Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:

 - Docs and comments update
 - Revert VersionHelper.createThread removal

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22154/files
  - new: https://git.openjdk.org/jdk/pull/22154/files/e674e1d0..673bc73b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=02-03

  Stats: 21 lines in 7 files changed: 9 ins; 6 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22154/head:pull/22154

PR: https://git.openjdk.org/jdk/pull/22154

From duke at openjdk.org  Wed Nov 20 13:11:36 2024
From: duke at openjdk.org (fabioromano1)
Date: Wed, 20 Nov 2024 13:11:36 GMT
Subject: RFR: 8341402: BigDecimal's square root optimization [v22]
In-Reply-To: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
References: <EzKD3rzw689jOBHcCBHYQ0Cbci194Tu6dBI6LVlJh_E=.4563f969-2f6e-4ec0-a3a6-379033ef6cae@github.com>
Message-ID: <n0Z0kzRCIc8-9vB22mewu1vBAeMcWiKToPTB6AyI0IU=.f5c49a2d-c05b-47c3-b3fc-1ba2fa6747c7@github.com>

> After changing `BigInteger.sqrt()` algorithm, this can be also used to speed up `BigDecimal.sqrt()` implementation. Here is how I made it.
> 
> The main steps of the algorithm are as follows:
> first argument reduce the value to an integer using the following relations:
> 
> x = y * 10 ^ exp
> sqrt(x) = sqrt(y) * 10^(exp / 2) if exp is even
> sqrt(x) = sqrt(y*10) * 10^((exp-1)/2) is exp is odd
> 
> Then use BigInteger.sqrt() on the reduced value to compute the numerical digits of the desired result.
> 
> Finally, scale back to the desired exponent range and perform any adjustment to get the preferred scale in the representation.

fabioromano1 has updated the pull request incrementally with one additional commit since the last revision:

  Code simplification

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21301/files
  - new: https://git.openjdk.org/jdk/pull/21301/files/0fff4c5e..43851d12

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=21
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21301&range=20-21

  Stats: 200 lines in 1 file changed: 73 ins; 74 del; 53 mod
  Patch: https://git.openjdk.org/jdk/pull/21301.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21301/head:pull/21301

PR: https://git.openjdk.org/jdk/pull/21301

From dl at openjdk.org  Wed Nov 20 13:26:21 2024
From: dl at openjdk.org (Doug Lea)
Date: Wed, 20 Nov 2024 13:26:21 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v29]
In-Reply-To: <jOo8Mk-rgx1spZA7UD6UuYOSsz7hxvznaw1L63Uil9w=.88b4beab-fa60-4ab2-b7a8-ac2e557ec167@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <DdTGVVxhz32yYVICE4Gx4GZEQyZR7HGNvjgVC3dNbBw=.fe6aefc9-541b-485e-81f1-e2c90702a4bf@github.com>
 <qeQnjlgqZB2OedmwlC0VGeks3Nkz1AOYTiq_b_5E4gE=.2fef17aa-c563-4bfd-8755-2105637040b5@github.com>
 <IBl9XOE-kYirsjhTT87ROdqmLcmcV6HnE1pSN96Gq0M=.6ce514d2-393e-4001-a0d2-a5e681ec061c@github.com>
 <jOo8Mk-rgx1spZA7UD6UuYOSsz7hxvznaw1L63Uil9w=.88b4beab-fa60-4ab2-b7a8-ac2e557ec167@github.com>
Message-ID: <Evur39jxHrn00Lf5mNRRibIKNaw6Wk9Tg3EOH96wsm8=.028ffa96-88f2-489c-a756-9d945c3a030c@github.com>

On Wed, 20 Nov 2024 10:36:13 GMT, Viktor Klang <vklang at openjdk.org> wrote:

>> resetThreadLocals looks good although. A discussion point is whether reset should be done for all FJP instances, not just the common pool but not this PR.
>
> Thanks Alan. Yes, I think it should be considered to do it for all FJP instances.

Well, almost all. There is a protected FJWT constructor with explicit arg about preserving ThreadLocals,, in which case it should also not reset CCL. (Also, I just noticed that the Thread ctor with !inherit now also forces using System classLoader, so the FJWT ctor no longer needs to in this case.) Will do as part of SM-removal pr coming next.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21507#discussion_r1850310793

From pminborg at openjdk.org  Wed Nov 20 13:46:49 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Wed, 20 Nov 2024 13:46:49 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v17]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <QNztJmsbdKcFfTnxsaFtSge7UUN_rISWqjomeR-_Hro=.599db9bc-8ff9-4b02-8ee8-06d351ce2a2b@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:

 - Update after comments
 - Merge branch 'master' into linker-padding-layout-only
 - Fix failing test
 - Merge branch 'master' into linker-padding-layout-only
 - Update after comments
 - Merge branch 'master' into linker-padding-layout-only
 - Simplify exception testing
 - Merge branch 'master' into linker-padding-layout-only
 - Remove redundant check
 - Rephrase doc
 - ... and 26 more: https://git.openjdk.org/jdk/compare/502056b1...28b3ad6d

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/69e6593d..28b3ad6d

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=16
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=15-16

  Stats: 85917 lines in 1414 files changed: 40952 ins; 38279 del; 6686 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From duke at openjdk.org  Wed Nov 20 14:04:54 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 14:04:54 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
Message-ID: <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>

> Use the built-in file system provider rather than the custom file system provider.
> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.

jyxzwd has updated the pull request incrementally with two additional commits since the last revision:

 - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider
 - Revert "8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider"
   
   This reverts commit 318888339bdc2ee6a632e4850a980d91bff79e79.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21997/files
  - new: https://git.openjdk.org/jdk/pull/21997/files/31888833..10bae79b

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21997&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21997&range=00-01

  Stats: 66 lines in 8 files changed: 32 ins; 32 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21997.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21997/head:pull/21997

PR: https://git.openjdk.org/jdk/pull/21997

From duke at openjdk.org  Wed Nov 20 14:04:54 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 14:04:54 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <zRxBk__5eBUlixtYNb1fZAIZ_UzY31w2ilj0ZkOfcq4=.38c84893-ec1b-45a9-bc55-3b1b4554dc1c@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <0e8yRN8McbHIFJLI_yty0VRCMeKJIJ_LnWiazcXow8o=.c343ba28-32e9-4ded-b548-09fb8de059a8@github.com>
 <AD34ezwPU7ZlJsxw_2-LhVpkzXrU3m6brKkIUUbZZF4=.7601a7ac-718e-4a7b-b56c-6fee3f11d5d5@github.com>
 <7ns1LkXz4mRFHkJScld_SJiAYbycE-u1O2l45Z77Upg=.c6c709fe-5959-47ca-9925-1083a7a2100c@github.com>
 <-WGTcJ7DWh0l2XW3uROYAt59jSWDsgFNLcEkMsjgM6Q=.a69f0a0e-afd0-4400-8c43-92def290c36f@github.com>
 <0DJigBuCtPZvcYPAXJjr7ZVRuSTmI7Bq_KfRaLDWYNE=.2afa03fa-5848-42da-a7bb-b6081afa7b02@github.com>
 <zRxBk__5eBUlixtYNb1fZAIZ_UzY31w2ilj0ZkOfcq4=.38c84893-ec1b-45a9-bc55-3b1b4554dc1c@github.com>
Message-ID: <umw-vgVH7uBETehbuarTcmSP6tI_ZYzi9ejh2Pg-h5w=.3df81e01-3121-42e0-a10c-5fcab2323ccf@github.com>

On Sun, 10 Nov 2024 17:04:12 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> If we load the custom DefaultFileSystemProvider by SystemClassLoader,then we will step into the method SystemModuleFinders$SystemModuleReader#findImageLocation again, and the var imageReader will be null.But we can not define a custom classLoader to load the custom DefaultFileSystemProvider since it needs to maintain JDK 8 source compatibility.So the only way that I can think of is to use the installedProvider which has the 'file' scheme to directly get the 'modules' path value.
>> 
>> In ImageReaderFactory:
>> 
>> private static final Path BOOT_MODULES_JIMAGE = null;
>> 
>>     static {
>>         // check installed providers
>>         for (FileSystemProvider provider : FileSystemProvider.installedProviders()) {
>>             if ("file".equalsIgnoreCase(provider.getScheme())) {
>>                 try {
>>                     BOOT_MODULES_JIMAGE = provider.getFileSystem(URI.create("file:/")).getPath(JAVA_HOME, "lib", "modules");
>>                     if (BOOT_MODULES_JIMAGE != null) break;
>>                 } catch (UnsupportedOperationException uoe) {
>>                 }
>>             }
>>         }
>>     }
>> 
>> What do you think of this?I am new to openjdk source development.So I truely appreciate the time you dedecate to my question!
>
> I assume this will lead to recursive initialisation, e.g. `FileSystems.getFileSystem(URI.create("jrt:/"))` will use FileSystemProvider.installedProviders to iterate over the installed providers.
> 
> I don't have time to look into this more but I think it will have to reflectively get the FileSystem so that the code isn't compiled with references to the built-in provider, as in something like this (not tested):
> 
> 
>     private static final Path BOOT_MODULES_JIMAGE;
>     static {
>         FileSystem fs;
>         if (ImageReaderFactory.class.getClassLoader() == null) {
>             // fs = DefaultFileSystemProvider.theFileSystem()
>             try {
>                 fs = (FileSystem) Class.forName("sun.nio.fs.DefaultFileSystemProvider")
>                         .getMethod("theFileSystem")
>                         .invoke(null);
>             } catch (Exception e) {
>                 throw new ExceptionInInitializerError(e);
>             }
>         } else {
>             fs = FileSystems.getDefault();
>         }
>         BOOT_MODULES_JIMAGE = fs.getPath(JAVA_HOME, "lib", "modules");
>     }
> 
> Also just to say that we need to create a good test for this issue. I expect it will be rarely to interpose on the default file system and use jrtfs at the same time, but that is what this bug report is about so we'll need to create a good test.

#### The reason why it is difficult to solve the issue through modifying ImageReadFactory directly

1. We only can use the `java8 `api
2. We can not access any classes which are not exported by `java.base` module,even by using java reflection.Because when there is a remote/target jdk, the class in jrt-fs.jar loaded by `JrtFsLoader`  is actually in `Unnamed Module`.

The essence of this issue is that when loading the Main class, which depends on Path.of, then it needs to load CustomFileSystemProvider, resulting in a circular dependency, which will access the fields of a class that is still being initialized.

The correct situation should be that Main class should be loaded with CustomFileSystemProvided, and when it comes to CustomFileSystemProvided it should use Built-in FileSystemProvider.

But if we following the above assumptions, and when we **first load the main class**, we will run to the `SystemModuleFinders# findImageLocation`  twice then the `ImageReader imageReader = SystemImage.reader()` will be null because we should load the customFileSystemProvider during main class loading and the the both of loading will use the same  `SystemModuleFinders# findImageLocation` method.So we must load the CustomFileSystemProvided **before** loading main class.

#### The solution

1. In `System#initPhase3` which will be called before loading main class, load the CustomFileSystemProvided after `VM.initLevel(4);`.Because we will use **SystemClassLoader**.
2. And we need also to ensure the return value of `FileSystems#getDefault` is `DefaultFileSystemProvider.theFileSystem`, which depends on the value of `VM.isModuleSystemInited()`. But now the `VM.initLevel` is **4** so the value of `VM.isModuleSystemInited()` is **false**. At first I want to change the judgment condition of `if` . That means I need to create a initLevel after `SYSTEM_BOOTED = 4`, but there is already `SYSTEM_SHUTDOWN = 5` defined in VM class.I can not set a `4.5` value to a new initLevel,so I add a new  boolen field to represent the status of loading CustomFileSystemProvider.Its initValue is **false** and its value can only be set from false to true so there is no need for lock.
3. Change the judgment condition of `if` to `if (VM.isModuleSystemInited()&&VM.isCustomDefaultFileSystemProviderLoaded())`
4. After load the CustomFileSystemProvided,  regardless of whether the  `-Djava.nio.file.spi.DefaultFileSystemProvider`  was set, it needs to call `VM.setCustomDefaultFileSystemProviderLoaded();`

After loading the CustomFileSystemProvided, the initialization of `Path BOOT_MODULES_JIMAGE = ImageReaderFactory#Paths.get(JAVA_HOME, "lib", "modules");` will use the fileSystem which is provided by the loaded CustomFileSystemProvided. Even it will also call `FileSystems#getDefaultProvider` , but during where it actually only use the constructor to new instance because relevent classes were already loaded.

For detail modification see the latest commit.

I recompile the modified source and test the situation mentioned in the issue(actually the issue is submitted by me through oracle bug submission because I am not openjdk author) and the normal situation, it successed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21997#discussion_r1850371330

From alanb at openjdk.org  Wed Nov 20 14:14:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 14:14:17 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
Message-ID: <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>

On Wed, 20 Nov 2024 14:04:54 GMT, jyxzwd <duke at openjdk.org> wrote:

>> Use the built-in file system provider rather than the custom file system provider.
>> Add "public static FileSystemProvider create" method in DefaultFileSystemProvider which is from java8API to be compatible against runtime.
>
> jyxzwd has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - 8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider
>  - Revert "8331467: Fix JDK-8331467 ImageReaderFactory can cause a ClassNotFoundException if the default FileSystemProvider is not the system-default provider"
>    
>    This reverts commit 318888339bdc2ee6a632e4850a980d91bff79e79.

I don't think we should be doing this. Did you try the direction of checking the defining class loader that I outlined in the previous comment?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2488690052

From aefimov at openjdk.org  Wed Nov 20 14:16:27 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 20 Nov 2024 14:16:27 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <5tT_WNZzZaDh-K5jUWrbGGsmPX3wMqUmfoXsLqg0-nM=.cb3da770-c85a-4fcd-96f6-f6396f29739f@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
 <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
 <5tT_WNZzZaDh-K5jUWrbGGsmPX3wMqUmfoXsLqg0-nM=.cb3da770-c85a-4fcd-96f6-f6396f29739f@github.com>
Message-ID: <NRgX5yiJGgaX_-b6ONKC-vP3oDoFOAumCPCJlObOdEc=.5f423c62-573e-4b94-9f78-b19822274cd9@github.com>

On Wed, 20 Nov 2024 11:33:19 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/jndi/ldap/Connection.java line 262:
>> 
>>> 260:         }
>>> 261: 
>>> 262:         worker = new Thread(this);
>> 
>> Rataining a static factory for thread may use useful to be able to customize thread behavior.
>> 
>> It should be considered that the new threads are Virtual threads:
>>  i.e.  `Thread.ofVirtual().startVirtualThread(Runnable)`
>
> This is a good point but orthogonal to the issue we're fixing here. If we decide to change the implementation to use VirtualThread it may have some impact, such as read/receive becoming interruptible. So I believe this kind of enhancement should be carried in their own PR.

That's a really good point - thank you. And a good suggestion for a future JNDI/LDAP client improvement, ie make it configurable to work with VTs. To make this work easier in a future PR - I have reverted the removal of `VersionHelper.createThread`: bd7e0b2acfccd7a296b30cf111e52ecdebc2615c

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850279135

From aefimov at openjdk.org  Wed Nov 20 14:16:31 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 20 Nov 2024 14:16:31 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
 <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
Message-ID: <JUQ7dqM8u09h5r3Z8Hx8H3YZPMuCTUM9Ja5k9mDyQfg=.4283b28f-04f4-4959-a471-e3f76cfd6c92@github.com>

On Tue, 19 Nov 2024 20:42:04 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   clarify factory location usages in NamingManager and jdk.naming.rmi module-info
>
> src/java.naming/share/classes/javax/naming/spi/NamingManager.java line 127:
> 
>> 125:      *    Return {@code refInfo} if the factory cannot be created.
>> 126:      *    Downloading a factory class from a location specified in the reference
>> 127:      *    is not supported out of the box.
> 
> "out of the box" seems a bit informal for the space.
> Perhaps...
> 
> Downloading a factory class from a location specified in the reference can be supported by a custom implementation of {@link ObjectFactoryBuilder}.
> 
> etc.

Thank you for the suggestion. Updated all places as suggested in 673bc73b67a1956da7feb7f1d212287a6aa1c701

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850278841

From dfuchs at openjdk.org  Wed Nov 20 14:16:32 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 14:16:32 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v4]
In-Reply-To: <BAQA7nkp3XVKrSteHNTrbFC1DnexNf0uzP82ILYMOss=.cd21ef03-c4d4-4a02-b4e7-75d1dafaa998@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <BAQA7nkp3XVKrSteHNTrbFC1DnexNf0uzP82ILYMOss=.cd21ef03-c4d4-4a02-b4e7-75d1dafaa998@github.com>
Message-ID: <FIoYx-I60Oa1eC3owgdgoaBkPSqtEeWzDdHf-gwS7zA=.509d4b73-3f95-4140-8be2-86f9fdeeda86@github.com>

On Wed, 20 Nov 2024 13:06:57 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>>     - `com.sun.jndi.rmi.object.trustURLCodebase`
>> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
>> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
>> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
>> 
>> These changes require a CSR that will be submitted soon.
>> 
>> ### Testing
>> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
>> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.
>
> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
> 
>  - Docs and comments update
>  - Revert VersionHelper.createThread removal

src/jdk.naming.rmi/share/classes/module-info.java line 63:

> 61:  * <p> Downloading a factory class from a {@linkplain javax.naming.Reference#getFactoryClassLocation()
> 62:  * location} specified in the reference can be supported by a custom implementation of {@link
> 63:  * javax.naming.spi.ObjectFactoryBuilder}. Unless an {@link javax.naming.spi.ObjectFactoryBuilder

Suggestion:

 * javax.naming.spi.ObjectFactoryBuilder}. If a location is specified, then 
 * unless an {@link javax.naming.spi.ObjectFactoryBuilder

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850391901

From duke at openjdk.org  Wed Nov 20 14:21:32 2024
From: duke at openjdk.org (David M. Lloyd)
Date: Wed, 20 Nov 2024 14:21:32 GMT
Subject: Integrated: 8333796: Add missing serialization functionality to
 sun.reflect.ReflectionFactory
In-Reply-To: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
References: <TuTQuOzR3XCSvoMEcWH8C2EihT2INuVLl3UkyklrWxY=.147f7d52-493f-4b86-8662-49c77c5ca699@github.com>
Message-ID: <IrH94285xBQKczjAq4uPRzVJSRDuDyTB4XiSbMHWkdk=.04aca1e1-483c-49e0-9195-39954278992b@github.com>

On Thu, 13 Jun 2024 14:31:06 GMT, David M. Lloyd <duke at openjdk.org> wrote:

> Issue [JDK-8164908](https://bugs.openjdk.org/browse/JDK-8164908) added support for functionality required to continue to support IIOP and custom serializers in light of additional module-based restrictions on reflection. It was expected that these libraries would use `sun.misc.Unsafe` in order to access fields of serializable classes. However, with JEP 471, the methods necessary to do this are being removed.
> 
> To allow these libraries to continue to function, it is proposed to add two methods to `sun.reflect.ReflectionFactory` which will allow serialization libraries to acquire a method handle to generated `readObject`/`writeObject` methods which set or get the fields of the serializable class using the serialization `GetField`/`PutField` mechanism. These generated methods should be used by serialization libraries to serialize and deserialize classes which do not have a `readObject`/`writeObject` method or which use `ObjectInputStream.defaultReadObject`/`ObjectOutputStream.defaultWriteObject` to supplement default serialization.
> 
> It is also proposed to add methods which allow for the reading of serialization-specific private static final fields from classes which have them.
> 
> With the addition of these methods, serialization libraries no longer need to rely on `Unsafe` for serialization/deserialization activities.
> cc: @AlanBateman

This pull request has now been integrated.

Changeset: e11d126a
Author:    David M. Lloyd <david.lloyd at redhat.com>
Committer: Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e11d126a8d50e8b3dce2fd02b263aba3b38b1172
Stats:     913 lines in 6 files changed: 911 ins; 1 del; 1 mod

8333796: Add missing serialization functionality to sun.reflect.ReflectionFactory

Reviewed-by: liach, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/19702

From rriggs at openjdk.org  Wed Nov 20 14:24:18 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Nov 2024 14:24:18 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v3]
In-Reply-To: <0GeqJaNQKdQbysUR5q6VH4Dz0wJnpMffPZgpXjKHpjI=.bb731579-a208-4852-a3d3-1dd6edbea12a@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <pFPcqthhAob5Yd0xC0efsekFB8pvvOc4mMZltDa1A2g=.1f5e0a9b-24fb-4b21-9c9f-fe51fa61b9b3@github.com>
 <lJI80C1M6-nCMT3lxAjUb87svBIwkTzXGrIiXwsaVH0=.d9cd9db1-afad-46a5-86bd-90aeeaee8180@github.com>
 <0GeqJaNQKdQbysUR5q6VH4Dz0wJnpMffPZgpXjKHpjI=.bb731579-a208-4852-a3d3-1dd6edbea12a@github.com>
Message-ID: <nFKVTdqS49tU6-4qgwmtipgAOSy09GzUjwWjsdHSloo=.1c807b95-a2f0-4759-8d2c-5afbfbd73855@github.com>

On Wed, 20 Nov 2024 11:38:35 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> src/java.naming/share/classes/com/sun/naming/internal/VersionHelper.java line 163:
>> 
>>> 161:     InputStream getJavaHomeConfStream(String filename) {
>>> 162:         try {
>>> 163:             String javahome = System.getProperty("java.home");
>> 
>> StaticProperty.javaHome() is available as a stable value for the property.
>
> Good point too - but that would require am additional qualified export of `jdk.internal.util` from `java.base` to `java.naming`. I'm not sure it's worth it. I mean - keeping qualified exports as few as possible is also a worthy goal.

Never mind, I forgot this isn't in java.base.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850406385

From sgehwolf at openjdk.org  Wed Nov 20 14:32:30 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 20 Nov 2024 14:32:30 GMT
Subject: RFR: 8344560: Add system property for patched runtime
Message-ID: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>

Please review this simple patch which adds a new external system property `jdk.patched` when the runtime has been patched with the `--patch-module` switch. This is useful for two reasons: 1) it allows one to determine at runtime whether or not `--patch-module` has been used (by querying the said property) 2) allows tools, such as `jlink` doing the same without exposing more of the internal properties the JVM sets on initialization.

CSR is forthcoming.

Testing:

- [x] GHA
- [x] New jtreg test 

Thoughts?

-------------

Commit messages:
 - 8344560: Add system property for patched runtime

Changes: https://git.openjdk.org/jdk/pull/22277/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22277&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344560
  Stats: 112 lines in 3 files changed: 111 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22277.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22277/head:pull/22277

PR: https://git.openjdk.org/jdk/pull/22277

From bkilambi at openjdk.org  Wed Nov 20 14:49:29 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 20 Nov 2024 14:49:29 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <eTKMPwhLWJ0JoFPKALSI7iMWsqhmEzYD4OG7sL-uRCs=.41a6b7b0-1045-40a3-b6b4-4adc6dfb31b0@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 44:

> 42:     @Test
> 43:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "avx512vl", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
> 44:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})

Wouldn't the Ideal transforms convert the IR for this test case to - 

ReinterpretS2HF     ReinterpretS2HF
                      \         /
                       AddHF
                            |
                       ReinterpretHF2S
                            |
                       ConvHF2F

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1850449500

From duke at openjdk.org  Wed Nov 20 14:58:33 2024
From: duke at openjdk.org (Sorna Sarathi)
Date: Wed, 20 Nov 2024 14:58:33 GMT
Subject: RFR: 8344611: Add missing classpath exception
Message-ID: <FUTNuOY1DeTlOxK39AqIkSqMM8WGv9rOXQ_o9_IFLc8=.30425bb6-9016-4abe-a297-a23176aa3a7a@github.com>

This PR adds missing Classpath exception in several files.

JBS Issue: [JDK-8334611](https://bugs.openjdk.org/browse/JDK-8344611)

-------------

Commit messages:
 - Added classpath exception for some additional files
 - Added missing classpath exception

Changes: https://git.openjdk.org/jdk/pull/22272/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22272&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344611
  Stats: 18 lines in 6 files changed: 12 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/22272.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22272/head:pull/22272

PR: https://git.openjdk.org/jdk/pull/22272

From amitkumar at openjdk.org  Wed Nov 20 14:58:34 2024
From: amitkumar at openjdk.org (Amit Kumar)
Date: Wed, 20 Nov 2024 14:58:34 GMT
Subject: RFR: 8344611: Add missing classpath exception
In-Reply-To: <FUTNuOY1DeTlOxK39AqIkSqMM8WGv9rOXQ_o9_IFLc8=.30425bb6-9016-4abe-a297-a23176aa3a7a@github.com>
References: <FUTNuOY1DeTlOxK39AqIkSqMM8WGv9rOXQ_o9_IFLc8=.30425bb6-9016-4abe-a297-a23176aa3a7a@github.com>
Message-ID: <QeLBlycU7Fv444qpWx_-AXn_BWbmEJkeOoibtwS4lKQ=.1a8eff7d-349e-4f56-890a-42ea9e05039f@github.com>

On Wed, 20 Nov 2024 10:46:54 GMT, Sorna Sarathi <duke at openjdk.org> wrote:

> This PR adds missing Classpath exception in several files.
> 
> JBS Issue: [JDK-8334611](https://bugs.openjdk.org/browse/JDK-8344611)

Do similar change for: 

src/java.base/share/native/libjava/ub.h
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java
src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourcePoolReader.java

Marked as reviewed by amitkumar (Committer).

-------------

Changes requested by amitkumar (Committer).

PR Review: https://git.openjdk.org/jdk/pull/22272#pullrequestreview-2448712572
PR Review: https://git.openjdk.org/jdk/pull/22272#pullrequestreview-2448863289

From duke at openjdk.org  Wed Nov 20 14:58:34 2024
From: duke at openjdk.org (Sorna Sarathi)
Date: Wed, 20 Nov 2024 14:58:34 GMT
Subject: RFR: 8344611: Add missing classpath exception
In-Reply-To: <QeLBlycU7Fv444qpWx_-AXn_BWbmEJkeOoibtwS4lKQ=.1a8eff7d-349e-4f56-890a-42ea9e05039f@github.com>
References: <FUTNuOY1DeTlOxK39AqIkSqMM8WGv9rOXQ_o9_IFLc8=.30425bb6-9016-4abe-a297-a23176aa3a7a@github.com>
 <QeLBlycU7Fv444qpWx_-AXn_BWbmEJkeOoibtwS4lKQ=.1a8eff7d-349e-4f56-890a-42ea9e05039f@github.com>
Message-ID: <b4-HePzs_0CFlJKbRFSddnyqjc69fud4pgUrFVcwUlc=.6e068e93-8987-44d3-a0d4-b2e4b399a13a@github.com>

On Wed, 20 Nov 2024 14:02:10 GMT, Amit Kumar <amitkumar at openjdk.org> wrote:

> Do similar change for:
> 
> ```
> src/java.base/share/native/libjava/ub.h
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/JimageDiffGenerator.java
> src/jdk.jlink/share/classes/jdk/tools/jlink/internal/runtimelink/ResourcePoolReader.java
> ```

Added the changes for the above files.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22272#issuecomment-2488724167

From jbhateja at openjdk.org  Wed Nov 20 15:00:38 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Wed, 20 Nov 2024 15:00:38 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <eTKMPwhLWJ0JoFPKALSI7iMWsqhmEzYD4OG7sL-uRCs=.41a6b7b0-1045-40a3-b6b4-4adc6dfb31b0@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <eTKMPwhLWJ0JoFPKALSI7iMWsqhmEzYD4OG7sL-uRCs=.41a6b7b0-1045-40a3-b6b4-4adc6dfb31b0@github.com>
Message-ID: <FQBwZ8Pf9R6SgItyUV-w8gawgcQrkk39rdWXBugyOwA=.693a153d-3a95-4542-9564-fe353ee11e82@github.com>

On Wed, 20 Nov 2024 14:46:46 GMT, Bhavana Kilambi <bkilambi at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 6. Auto-vectorization of newly supported scalar operations.
>> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
>> 9. Functional and Performance validation tests.
>> 
>> **Missing Pieces:-**
>> **-  AARCH64 Backend.**
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 44:
> 
>> 42:     @Test
>> 43:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "avx512vl", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
>> 44:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
> 
> Wouldn't the Ideal transforms convert the IR for this test case to - 
> 
> ReinterpretS2HF     ReinterpretS2HF
>                       \         /
>                        AddHF
>                             |
>                        ReinterpretHF2S
>                             |
>                        ConvHF2F
> 
> in which case, ConvF2HF won't match?

New transforms are guarded by target features checks, the IR test rules are enforced only on non AVX512_FP16 targets.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1850469049

From bkilambi at openjdk.org  Wed Nov 20 15:05:20 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Wed, 20 Nov 2024 15:05:20 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <FQBwZ8Pf9R6SgItyUV-w8gawgcQrkk39rdWXBugyOwA=.693a153d-3a95-4542-9564-fe353ee11e82@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <eTKMPwhLWJ0JoFPKALSI7iMWsqhmEzYD4OG7sL-uRCs=.41a6b7b0-1045-40a3-b6b4-4adc6dfb31b0@github.com>
 <FQBwZ8Pf9R6SgItyUV-w8gawgcQrkk39rdWXBugyOwA=.693a153d-3a95-4542-9564-fe353ee11e82@github.com>
Message-ID: <cPfOVQs02jWPlodST6iju6S78IovIFNeTgNXcCxBOKw=.6c784c81-31ac-422b-bc51-c7f6a21d251e@github.com>

On Wed, 20 Nov 2024 14:57:11 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorConvChain.java line 44:
>> 
>>> 42:     @Test
>>> 43:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "avx512vl", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
>>> 44:     @IR(applyIfCPUFeatureAnd = {"avx512_fp16", "false", "f16c", "true"}, counts = {IRNode.VECTOR_CAST_HF2F, IRNode.VECTOR_SIZE_ANY, ">= 1", IRNode.VECTOR_CAST_F2HF, IRNode.VECTOR_SIZE_ANY, " >= 1"})
>> 
>> Wouldn't the Ideal transforms convert the IR for this test case to - 
>> 
>> ReinterpretS2HF     ReinterpretS2HF
>>                       \         /
>>                        AddHF
>>                             |
>>                        ReinterpretHF2S
>>                             |
>>                        ConvHF2F
>> 
>> in which case, ConvF2HF won't match?
>
> New transforms are guarded by target features checks, the IR test rules are enforced only on non AVX512_FP16 targets.

Oh right! Sorry misread the IR test rules. Got it now. Thanks!

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1850477856

From ihse at openjdk.org  Wed Nov 20 16:24:30 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Nov 2024 16:24:30 GMT
Subject: RFR: 8344056: Use markdown format for man pages [v4]
In-Reply-To: <dSX5F0cz58F6KPMi0eaZDqRmHQTGA_hjJBGk9lJXqS4=.b1cbd6d0-9e9e-4166-905e-e59988720bd8@github.com>
References: <4IMAP2YybZ72bK3HxFTZJ4N5QenXeLQfoIkrjHmZWqg=.ffe66ac0-e675-44cf-bfde-7947f36c699b@github.com>
 <MFJE1GFfhbL6V-n8X7LqAYMOBKz9l6G3Kop8QwRPYSg=.bfe25f26-140c-4235-8686-85bbac7f6915@github.com>
 <dSX5F0cz58F6KPMi0eaZDqRmHQTGA_hjJBGk9lJXqS4=.b1cbd6d0-9e9e-4166-905e-e59988720bd8@github.com>
Message-ID: <Lm9JH4ilJQSzUz6NveUUZGWppeHKqun_9SXOSwcwhhs=.125acdbf-545e-4d79-aabf-da2bcdc0d6a6@github.com>

On Tue, 19 Nov 2024 16:27:54 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

>> Magnus Ihse Bursie has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   It's somewhat nicer to use \\s instead of space character in regex
>
> Is the warning log when pandoc is not installed a bit loud?
> 
> 
> % make images
> Building target 'images' in configuration 'macosx-x86_64-server-release'
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Warning: pandoc not found. Not generating man pages
> Finished building target 'images' in configuration 'macosx-x86_64-server-release'

@eirbjo Yes, that was not intentional. https://bugs.openjdk.org/browse/JDK-8344559.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22081#issuecomment-2489029819

From aefimov at openjdk.org  Wed Nov 20 16:25:56 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 20 Nov 2024 16:25:56 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v5]
In-Reply-To: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
Message-ID: <CaQNekGSc5fEwFObvrqo8wJu1Vj3gm7sO5PG6qrq07M=.8c8f8837-6daf-4e91-8448-1653ccea9359@github.com>

> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
> - The following two properties are removed:
>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>     - `com.sun.jndi.rmi.object.trustURLCodebase`
> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
> 
> These changes require a CSR that will be submitted soon.
> 
> ### Testing
> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.

Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:

  change jdk.naming.rmi per Daniel's suggestion

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22154/files
  - new: https://git.openjdk.org/jdk/pull/22154/files/673bc73b..991994da

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22154&range=03-04

  Stats: 3 lines in 1 file changed: 1 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22154.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22154/head:pull/22154

PR: https://git.openjdk.org/jdk/pull/22154

From aefimov at openjdk.org  Wed Nov 20 16:25:56 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 20 Nov 2024 16:25:56 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v4]
In-Reply-To: <FIoYx-I60Oa1eC3owgdgoaBkPSqtEeWzDdHf-gwS7zA=.509d4b73-3f95-4140-8be2-86f9fdeeda86@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <BAQA7nkp3XVKrSteHNTrbFC1DnexNf0uzP82ILYMOss=.cd21ef03-c4d4-4a02-b4e7-75d1dafaa998@github.com>
 <FIoYx-I60Oa1eC3owgdgoaBkPSqtEeWzDdHf-gwS7zA=.509d4b73-3f95-4140-8be2-86f9fdeeda86@github.com>
Message-ID: <GfJH-Lz0_Wj-i4nOFtujjD1yKz_jumLxCZDQAiX8mds=.c04849d2-f1a9-4952-9326-d0bdb1c73534@github.com>

On Wed, 20 Nov 2024 14:13:59 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with two additional commits since the last revision:
>> 
>>  - Docs and comments update
>>  - Revert VersionHelper.createThread removal
>
> src/jdk.naming.rmi/share/classes/module-info.java line 63:
> 
>> 61:  * <p> Downloading a factory class from a {@linkplain javax.naming.Reference#getFactoryClassLocation()
>> 62:  * location} specified in the reference can be supported by a custom implementation of {@link
>> 63:  * javax.naming.spi.ObjectFactoryBuilder}. Unless an {@link javax.naming.spi.ObjectFactoryBuilder
> 
> Suggestion:
> 
>  * javax.naming.spi.ObjectFactoryBuilder}. If a location is specified, then 
>  * unless an {@link javax.naming.spi.ObjectFactoryBuilder

Thank you changed in [991994d](https://github.com/openjdk/jdk/pull/22154/commits/991994da64bcc5c2f8bfb5cf8704e926948153f0)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850622248

From rriggs at openjdk.org  Wed Nov 20 16:27:08 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Nov 2024 16:27:08 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v3]
In-Reply-To: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
Message-ID: <2ec6djBJoEap8ekG_n-ZnL_h2pj0ltyRM2iOqWQDyZo=.af1a75c1-db43-4a96-9804-ffd229868cbb@github.com>

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains six additional commits since the last revision:

 - Merge branch '8344336-sm-lang-system-runtime' of https://github.com/RogerRiggs/jdk into 8344336-sm-lang-system-runtime
 - Review suggestions applied:
   Remove SecurityExceptions from LiveStackFrame
   Rename safeTrim to trimArray
 - 8344336: SM cleanup of java.lang.System, Runtime, String, StackWalker
   Removed use of SecurityManager to check permissions
   Relaxed defensive copying of byte arrays (due to lack of SM)
 - Refactor package private method `codeSource` into Module where it is used.
   Cleanup doPrivileged in LoggerFinder `accessProvider`, no longer needed.
 - Review suggestions applied:
   Remove SecurityExceptions from LiveStackFrame
   Rename safeTrim to trimArray
 - 8344336: SM cleanup of java.lang.System, Runtime, String, StackWalker
   Removed use of SecurityManager to check permissions
   Relaxed defensive copying of byte arrays (due to lack of SM)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22168/files
  - new: https://git.openjdk.org/jdk/pull/22168/files/b873e116..2c0f3a42

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22168&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22168&range=01-02

  Stats: 67633 lines in 827 files changed: 32743 ins; 31618 del; 3272 mod
  Patch: https://git.openjdk.org/jdk/pull/22168.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22168/head:pull/22168

PR: https://git.openjdk.org/jdk/pull/22168

From rriggs at openjdk.org  Wed Nov 20 16:27:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Nov 2024 16:27:09 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v2]
In-Reply-To: <w3R1Ab4uKMmtwnFN0UCWDAZwvKVsUR2qHrwCXtPoIgI=.1a7cb021-e8ca-43fe-889a-c414da3c0839@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
 <w3R1Ab4uKMmtwnFN0UCWDAZwvKVsUR2qHrwCXtPoIgI=.1a7cb021-e8ca-43fe-889a-c414da3c0839@github.com>
Message-ID: <AJhWzivWTJhDACgTq6tGYzj3vXlROnJ2kiICvi4yVPw=.113ca63a-57fa-46f9-89a9-962d2db937a7@github.com>

On Mon, 18 Nov 2024 19:22:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review suggestions applied:
>   Remove SecurityExceptions from LiveStackFrame
>   Rename safeTrim to trimArray

Blox'ed up this PR with duplicated Commits.  Will create a new PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22168#issuecomment-2489036002

From rriggs at openjdk.org  Wed Nov 20 16:27:10 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Nov 2024 16:27:10 GMT
Subject: Withdrawn: 8344336: SM cleanup of java.lang.System, Runtime, String, 
 StackWalker
In-Reply-To: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
References: <RgHAm4w-gws1iGaIN5NuE7hLj0vtat3PT77a9yscvGA=.173a9f6a-aa6c-4ddb-9de7-6c980a5725d9@github.com>
Message-ID: <_u5ZuR6QMoKKiVIjQiw0lRfiqjtpSo1f--ksCXUF2WE=.6e297c57-630e-4256-b316-6108a33cb7cc@github.com>

On Fri, 15 Nov 2024 22:11:17 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/22168

From ihse at openjdk.org  Wed Nov 20 16:29:23 2024
From: ihse at openjdk.org (Magnus Ihse Bursie)
Date: Wed, 20 Nov 2024 16:29:23 GMT
Subject: RFR: 8340133: Add concise usage message to the java executable
 [v9]
In-Reply-To: <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>
References: <VTBPzdQVEHoBgrEvU-ZKZ5nhJkJl0PXkDo5iaDt-UIw=.03cbbf88-811c-47e6-b158-13fda5c5ee51@github.com>
 <yDkpvJ9srwoSOIOwXwM-2rVKpbRqpjwYjeLjICtsXrc=.e6050fdf-7baf-4ba6-a402-5ef536d1e620@github.com>
Message-ID: <VGCD9HIOcJmHqx1MkBIVGgxW61ewMwvgGxQmXzZdh44=.d8fbe759-8871-4b96-864f-566fee1535b1@github.com>

On Mon, 18 Nov 2024 15:50:49 GMT, Jan Lahoda <jlahoda at openjdk.org> wrote:

>> Currently, running `java` without any parameters will lead to an output that is a full `--help`, which is over 100 lines (on my computer at least), and it feels overwhelming. And many people might actually want to run JShell/REPL, not the `java` executable, but it is difficult find out about JShell.
>> 
>> The proposal herein is to print a much shorter help, together with a pointer to JShell, when the executable does not know what to do. I.e. there is nothing specified to start, and no option like `--help` is specified. In particular, on my machine, it prints:
>> 
>> openjdk version "24-internal" 2025-03-18
>> 
>> Usage: java [java options...] <application> [application arguments...]
>> 
>> Where <application> is one of:
>>   <mainclass>                to execute the main method of a compiled main class
>>   -jar <jarfile>.jar         to execute the main class of a JAR archive
>>   -m <module>[/<mainclass>]  to execute the main class of a module
>>   <sourcefile>.java          to compile and execute a source-file program
>> 
>> Where key java options include:
>>   --class-path <class path>
>>     where <class path> is a list of directories and JAR archives to search for class files, separated by ":"
>>   --module-path <module path>
>>     where <module path> is a list of directories and JAR archives to search for modules, separated by ":"
>> 
>> For additional help on usage:           java --help
>> For an interactive Java environment:    jshell
>> 
>> 
>> The full `java -help` with these changes is as follows:
>> 
>> Usage: java [options] <mainclass> [args...]
>>            (to execute a class)
>>    or  java [options] -jar <jarfile>.jar [args...]
>>            (to execute a jar file)
>>    or  java [options] -m <module>[/<mainclass>] [args...]
>>        java [options] --module <module>[/<mainclass>] [args...]
>>            (to execute the main class in a module)
>>    or  java [options] <sourcefile>.java [args]
>>            (to execute a source-file program)
>> 
>>  Arguments following the main class, source file, -jar <jarfile>.jar,
>>  -m or --module <module>/<mainclass> are passed as the arguments to
>>  main class.
>> 
>>  where options include:
>> 
>>     -cp <class search path of directories and zip/jar files>
>>     -classpath <class search path of directories and zip/jar files>
>>     --class-path <class search path of directories and zip/jar files>
>>                   A ":"-separated list of directories, JAR archives,
>>                   and ZIP archives to search for class files.
>>   ...
>
> Jan Lahoda 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 'master' into JDK-8340133-2
>  - - suffixing <jarfile> and <sourcefile> with .jar and .java in both the concise and full help.
>    - using a stderr version instead of the stdout version.
>  - Reflecting review feedback:
>    - using "conciseVersionString" intead of "shortVersionString"
>    - using <jarfile>.jar <jarfile>
>  - Merge branch 'master' into JDK-8340133-2
>  - Using correct pplaceholders.
>  - Adjusting text as suggested.
>  - Cleaning up the concise message:
>    - using 2 spaces instead of 4,
>    - rewording the "for more use --help" part of the message as suggested to avoid the word "launcher".
>  - Using lowercase for the keys in the help, using 'source-file' program instead of 'single-file' program.
>  - Using an enum instead of booleans, as suggested.
>  - Adjusting the concise help as suggested: 'using main class of a JAR archive' and '<JarFile>.jar'/'<SourceFile>.java'
>  - ... and 4 more: https://git.openjdk.org/jdk/compare/dfddbcaa...439fa40f

Marked as reviewed by ihse (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21411#pullrequestreview-2449134166

From dfuchs at openjdk.org  Wed Nov 20 16:34:22 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 16:34:22 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v5]
In-Reply-To: <CaQNekGSc5fEwFObvrqo8wJu1Vj3gm7sO5PG6qrq07M=.8c8f8837-6daf-4e91-8448-1653ccea9359@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <CaQNekGSc5fEwFObvrqo8wJu1Vj3gm7sO5PG6qrq07M=.8c8f8837-6daf-4e91-8448-1653ccea9359@github.com>
Message-ID: <SrVrlh9xNcbFHAzFA7hb465r2sUMnbi_DVZafGf-Vnk=.d3406e22-1726-4a5d-8329-c8e9676a77cf@github.com>

On Wed, 20 Nov 2024 16:25:56 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>>     - `com.sun.jndi.rmi.object.trustURLCodebase`
>> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
>> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
>> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
>> 
>> These changes require a CSR that will be submitted soon.
>> 
>> ### Testing
>> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
>> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change jdk.naming.rmi per Daniel's suggestion

src/jdk.naming.rmi/share/classes/module-info.java line 64:

> 62:  * location} specified in the reference can be supported by a custom implementation of {@link
> 63:  * javax.naming.spi.ObjectFactoryBuilder}. If a location is specified, then
> 64:  * unless an {@link javax.naming.spi.ObjectFactoryBuilder} is installed a

Minor: I think you need:

unless an {@link javax.naming.spi.ObjectFactoryBuilder ObjectFactoryBuilder}

to avoid the uncertainty about whether this would be rendered as "an javax...." or "an Object..."

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850636984

From aefimov at openjdk.org  Wed Nov 20 16:43:16 2024
From: aefimov at openjdk.org (Aleksei Efimov)
Date: Wed, 20 Nov 2024 16:43:16 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v5]
In-Reply-To: <SrVrlh9xNcbFHAzFA7hb465r2sUMnbi_DVZafGf-Vnk=.d3406e22-1726-4a5d-8329-c8e9676a77cf@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <CaQNekGSc5fEwFObvrqo8wJu1Vj3gm7sO5PG6qrq07M=.8c8f8837-6daf-4e91-8448-1653ccea9359@github.com>
 <SrVrlh9xNcbFHAzFA7hb465r2sUMnbi_DVZafGf-Vnk=.d3406e22-1726-4a5d-8329-c8e9676a77cf@github.com>
Message-ID: <P3SaNBepSbdYEQYV1U1Uc1P8OMO3EzXcrpEBp7vI27g=.416f36d6-ef6f-455d-aa9c-3632823bd489@github.com>

On Wed, 20 Nov 2024 16:31:44 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   change jdk.naming.rmi per Daniel's suggestion
>
> src/jdk.naming.rmi/share/classes/module-info.java line 64:
> 
>> 62:  * location} specified in the reference can be supported by a custom implementation of {@link
>> 63:  * javax.naming.spi.ObjectFactoryBuilder}. If a location is specified, then
>> 64:  * unless an {@link javax.naming.spi.ObjectFactoryBuilder} is installed a
> 
> Minor: I think you need:
> 
> unless an {@link javax.naming.spi.ObjectFactoryBuilder ObjectFactoryBuilder}
> 
> to avoid the uncertainty about whether this would be rendered as "an javax...." or "an Object..."

I've checked the generated javadoc, and the link is rendered as:
  "If a location is specified, then unless an _ObjectFactoryBuilder_"

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850655143

From dfuchs at openjdk.org  Wed Nov 20 16:46:22 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 16:46:22 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v5]
In-Reply-To: <CaQNekGSc5fEwFObvrqo8wJu1Vj3gm7sO5PG6qrq07M=.8c8f8837-6daf-4e91-8448-1653ccea9359@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <CaQNekGSc5fEwFObvrqo8wJu1Vj3gm7sO5PG6qrq07M=.8c8f8837-6daf-4e91-8448-1653ccea9359@github.com>
Message-ID: <6pvggglWCy0H-YLvgx9H_fD7gx5JTZTfiVpSlE9N_s4=.b755b849-83a2-482b-b157-9362d1489a13@github.com>

On Wed, 20 Nov 2024 16:25:56 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> This PR permanently disable remote code downloading in JNDI/LDAP and JNDI/RMI JDK providers, and contains the following changes:
>> - The following two properties are removed:
>>     - `com.sun.jndi.ldap.object.trustURLCodebase`
>>     - `com.sun.jndi.rmi.object.trustURLCodebase`
>> - JNDIs object factories logic has been altered to make it possible to reconstruct object factories from remote locations when a custom [ObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/ObjectFactoryBuilder.html) is assigned via the [NamingManager#setObjectFactoryBuilder](https://docs.oracle.com/en/java/javase/23/docs/api/java.naming/javax/naming/spi/NamingManager.html#setObjectFactoryBuilder(javax.naming.spi.ObjectFactoryBuilder)) API.
>> - The `NamingManager` class-level documentation is edited to remove references to the `SecurityManager`. It was also revised to clarify a reconstruction mechanism of object factories from remote references in the presence of a custom `ObjectFactoriesBuilder`.
>> - Also, the modified classes have been cleaned-up from `SecurityManager`, `doPrivildged`, and `AccessController` usages.
>> 
>> These changes require a CSR that will be submitted soon.
>> 
>> ### Testing
>> - Added a new test to check if NamingManager#setObjectFactoryBuilder can be used to implement remote code downloading: `test/jdk/com/sun/jndi/rmi/registry/objects/ObjectFactoryBuilderCodebaseTest.java`
>> - `jdk-tier1` to `jdk-tier3` and other JNDI LDAP/RMI tests show no issue with the proposed changes.
>
> Aleksei Efimov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   change jdk.naming.rmi per Daniel's suggestion

Marked as reviewed by dfuchs (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22154#pullrequestreview-2449180456

From dfuchs at openjdk.org  Wed Nov 20 16:46:24 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 16:46:24 GMT
Subject: RFR: 8338536: Permanently disable remote code downloading in JNDI
 [v5]
In-Reply-To: <P3SaNBepSbdYEQYV1U1Uc1P8OMO3EzXcrpEBp7vI27g=.416f36d6-ef6f-455d-aa9c-3632823bd489@github.com>
References: <83_-JVFTvppgmExHQsyiJtC9YgUmeokWKiIo0-pqLZ0=.b560f0a7-1a83-4518-b1a4-e9de6dbaa71c@github.com>
 <CaQNekGSc5fEwFObvrqo8wJu1Vj3gm7sO5PG6qrq07M=.8c8f8837-6daf-4e91-8448-1653ccea9359@github.com>
 <SrVrlh9xNcbFHAzFA7hb465r2sUMnbi_DVZafGf-Vnk=.d3406e22-1726-4a5d-8329-c8e9676a77cf@github.com>
 <P3SaNBepSbdYEQYV1U1Uc1P8OMO3EzXcrpEBp7vI27g=.416f36d6-ef6f-455d-aa9c-3632823bd489@github.com>
Message-ID: <LzaaMau4ISfx-beVVtMdivQMJMHZymoYlunnBenhAH8=.cd732e4a-b340-4072-87a6-1fcb579daaa2@github.com>

On Wed, 20 Nov 2024 16:40:43 GMT, Aleksei Efimov <aefimov at openjdk.org> wrote:

>> src/jdk.naming.rmi/share/classes/module-info.java line 64:
>> 
>>> 62:  * location} specified in the reference can be supported by a custom implementation of {@link
>>> 63:  * javax.naming.spi.ObjectFactoryBuilder}. If a location is specified, then
>>> 64:  * unless an {@link javax.naming.spi.ObjectFactoryBuilder} is installed a
>> 
>> Minor: I think you need:
>> 
>> unless an {@link javax.naming.spi.ObjectFactoryBuilder ObjectFactoryBuilder}
>> 
>> to avoid the uncertainty about whether this would be rendered as "an javax...." or "an Object..."
>
> I've checked the generated javadoc, and the link is rendered as:
>   "If a location is specified, then unless an _ObjectFactoryBuilder_"

Good, thanks for double checking :-)

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22154#discussion_r1850659717

From asemenyuk at openjdk.org  Wed Nov 20 16:57:27 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 20 Nov 2024 16:57:27 GMT
Subject: Integrated: 8289771: jpackage: ResourceEditor error when path is
 overly long on Windows
In-Reply-To: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
References: <wv83C96SQoWLKyLX0momThKHpBTqBIeFSrW728Zeh6Q=.ddfd0ef4-d85a-4a64-bfc0-0cd0b3a69ba2@github.com>
Message-ID: <bgIeS0nNRNfQpxI-QdLBrU4AeZC7shkrasgiyi53ZGQ=.976070e9-0dff-4b06-955c-13176805080c@github.com>

On Thu, 14 Nov 2024 04:40:37 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Fix `ResourceEditor` class to handle long paths.
> 
> Based on https://github.com/openjdk/jdk/pull/9384 PR.
> 
> This repairs app image building on Windows if the path to jpackage temp directory exceeds 260 (`MAX_PATH`) characters. MSI building is still broken and can NOT be repaired due to WiX's limitations.
> 
> Repaired scenario when the `--dest` option references a long path on Windows. Previously jpackage would have failed to build MSI package.
> 
> Other changes:
>  - Rename `Executor.setRemovePath()` into `Executor.setRemovePathEnvVar()` to make the method name match the implementation.
>  - Move the mutable part of `WixPipeline` class into `WixPipeline.Builder` class.
>  - Fixed minor flaws in "WinL10nTest.java"

This pull request has now been integrated.

Changeset: 080f1cc8
Author:    Alexey Semenyuk <asemenyuk at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/080f1cc8cd0500c254debec3198dc187bd41c3e8
Stats:     512 lines in 18 files changed: 415 ins; 12 del; 85 mod

8289771: jpackage: ResourceEditor error when path is overly long on Windows

Reviewed-by: almatvee

-------------

PR: https://git.openjdk.org/jdk/pull/22092

From sgehwolf at openjdk.org  Wed Nov 20 17:03:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 20 Nov 2024 17:03:00 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early [v2]
In-Reply-To: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
Message-ID: <F8-O1Ck-VKS_ukheddjwVFTiHWQ1-f00EOyjHLSreTs=.9870341a-2cce-4a35-a096-b5d5eaf31685@github.com>

> Please review this fix to how patched modules are being handled when linking from the run-time image. During review of [JDK-8311302](https://bugs.openjdk.org/browse/JDK-8311302) it was pointed out that module patching should be detected earlier and the link should get aborted in that case.
> 
> This patch implements it, by looking at the `jdk.module.patch.0` property like [other code in the JDK](https://github.com/openjdk/jdk/blob/2c1e4c381615ce52276f4bf331a1e7a845af4b6e/src/hotspot/share/cds/cdsConfig.cpp#L282) does. After this patch module patching is being detected before any archives are being read or the actual linking process starts (contrary to the previous solution).
> 
> Testing:
> - [x] GHA testing (mac aarch64 test failures are infra related)
> - [x] Local testing of existing test, which covers it
> 
> Thoughts?

Severin Gehwolf has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains four additional commits since the last revision:

 - Revert module export to jdk.jlink
 - Review feedback and depend on JDK-8344560
 - Merge branch 'jdk-8344560-jdk.patched-property' into jdk-8343839-detect-patch-module
 - 8343839: Detect patched modules and abort run-time image link early

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22037/files
  - new: https://git.openjdk.org/jdk/pull/22037/files/2d6d1f40..81917340

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22037&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22037&range=00-01

  Stats: 164100 lines in 3375 files changed: 50017 ins; 102678 del; 11405 mod
  Patch: https://git.openjdk.org/jdk/pull/22037.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22037/head:pull/22037

PR: https://git.openjdk.org/jdk/pull/22037

From sgehwolf at openjdk.org  Wed Nov 20 17:03:00 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 20 Nov 2024 17:03:00 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early [v2]
In-Reply-To: <REaAODrWKvg4KtWt98si_j-Wifm9sdcZDGyLx81eoZs=.9ecd938d-34b7-46ae-bcc5-eb3025e3d407@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
 <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
 <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
 <xN7uGi3rA6o-GskzEnRHsyR6iIOplY6lfMi-FIIdjiI=.b61ac634-ceb2-49ec-a7cb-94676afe4aec@github.com>
 <REaAODrWKvg4KtWt98si_j-Wifm9sdcZDGyLx81eoZs=.9ecd938d-34b7-46ae-bcc5-eb3025e3d407@github.com>
Message-ID: <0bVSpf2WtyqqnXuluIoOTLKrq7e6RgJJ8cpTqm3h30M=.af061aa8-f741-496a-9f07-0ab43d164f5b@github.com>

On Thu, 14 Nov 2024 16:11:13 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> Yes, I'm wondering if a JDK-specific (rather than standard) property could be more widely useful as it would allow observability tools to know that the JDK has been patched. It would be good to get wider input on this.
>
> @AlanBateman The discussion doesn't see to gain much traction. Should I go ahead and propose a bug/patch - with CSR -  which adds the JDK specific property and make it dependent on this fix? Thoughts?

I've now proposed a property in [JDK-8344560](https://bugs.openjdk.org/browse/JDK-8344560) and based this patch on it.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1850676506

From sgehwolf at openjdk.org  Wed Nov 20 17:03:01 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 20 Nov 2024 17:03:01 GMT
Subject: RFR: 8343839: Detect patched modules and abort run-time image link
 early [v2]
In-Reply-To: <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
References: <zk9csIbHZtyfpiQuXYhVFgyMzem46SKqs6iVYt6bCu8=.ef46c7a8-5f60-42db-bd72-121a87baf23d@github.com>
 <gARcaXiOcj6JdWFuj4KDLarQxGkk4bySPNKshrwNaQ4=.7bc86fb5-70df-4e6b-838d-61e6091db5c8@github.com>
 <ioe_ifVChR3dxkdGgNSRhjFXFgpZPSdHdWdoBe9qQ6c=.039aa38f-7d0f-4a9c-baa2-9200e8b5ec87@github.com>
Message-ID: <9QMiyq3-YUIDRxdtJyidPDW8oPeJMUyBIkNyN3bUSH8=.5d6650fd-4e2a-4be1-a4df-97290552c933@github.com>

On Tue, 12 Nov 2024 13:52:12 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

>> src/jdk.jlink/share/classes/jdk/tools/jlink/resources/jlink.properties line 128:
>> 
>>> 126: \ --keep-packaged-modules is not supported
>>> 127: err.runtime.link.modified.file={0} has been modified
>>> 128: err.runtime.link.patched.module=The current runtime includes module patches.\
>> 
>> Not sure about "module patches", its more that the current runtime has been patched with --patch-module.
>
> OK.

Updated in the latest version.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22037#discussion_r1850677603

From iris at openjdk.org  Wed Nov 20 17:15:14 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 20 Nov 2024 17:15:14 GMT
Subject: RFR: 8344524: Remove SecurityManager related code from jdk.jlink
 module
In-Reply-To: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
References: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
Message-ID: <ddke4Wt5IMgJz8QpRjfQ0gH3yzzYWngyctqUqmMpTcE=.42e2468b-1f1a-4a73-a4e7-0d1b544b9dc6@github.com>

On Wed, 20 Nov 2024 09:38:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which removes SecurityManager usages from `jdk.jlink` module? This addresses https://bugs.openjdk.org/browse/JDK-8344524.
> 
> The internal class `jdk.tools.jlink.internal.JlinkPermission` too has been removed as part of this change.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22268#pullrequestreview-2449253986

From duke at openjdk.org  Wed Nov 20 17:30:17 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 17:30:17 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
Message-ID: <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>

On Wed, 20 Nov 2024 14:11:51 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I don't think we should be doing this. Did you try the direction of checking the defining class loader that I outlined in the previous comment?

yeah,I tested it a few mins ago.It works well in the situation mentioned in the issue and in the normal situation, also when a remote/target jdk is set. But I have a doubt, when only using the local jdk, no remote/targetjdk, that is, ImageReaderFactory.class.getClassLoader() will be null, when loading any class located in the runtime image, BOOT_MODULES_JIMAGE will always be the path provided by the built-in default FileSystemProvider. The user-defined FileSystemProvider will make no contribution to loading the classes that exist in the image in this case.Although the built-in default FileSystemProvider is sufficient, are my concerns redundant?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489173647

From alanb at openjdk.org  Wed Nov 20 17:48:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 17:48:14 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
Message-ID: <Nl80cozOc5SpANdrtEnhpc5JgnxKf6HkoVQ_oXHBYwI=.be23587d-c0f2-421f-8a47-260f080be1c8@github.com>

On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple patch which adds a new external system property `jdk.patched` when the runtime has been patched with the `--patch-module` switch. This is useful for two reasons: 1) it allows one to determine at run-time whether or not `--patch-module` has been used (by querying the said property) 2) allows tools, such as `jlink` doing the same without needing to expose internal properties the JVM sets on initialization.
> 
> Testing:
> 
> - [x] GHA (includes new test)
> - [x] New jtreg test 
> 
> Thoughts?

I had hoped you would get more feedback on the proposal. If we do expose the property then I'm wondering about the JDK-specific properties documented in System.getProperties, and also thinking about java -XshowSettings output.

test/jdk/java/lang/System/patchedModule/ModulePatcherTest.java line 39:

> 37:  * @run main/othervm --patch-module=java.base=${test.classes} ModulePatcherTest true
> 38:  */
> 39: public class ModulePatcherTest {

The existing tests for --patch-module are in test/jdk/tools/launcher/modules/patch, we might want to see if we should just update one of the existing tests or move the new test with a name that makes it clear it's testing the property.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2489206819
PR Review Comment: https://git.openjdk.org/jdk/pull/22277#discussion_r1850743894

From jlu at openjdk.org  Wed Nov 20 17:57:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Wed, 20 Nov 2024 17:57:19 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <wHmw4bi338AdR6fsLyLk2V4UOZmALKvIOOJhiG1Ngos=.e18a9038-5faa-4b28-aa29-ed6543c8e00c@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
 <wHmw4bi338AdR6fsLyLk2V4UOZmALKvIOOJhiG1Ngos=.e18a9038-5faa-4b28-aa29-ed6543c8e00c@github.com>
Message-ID: <_uiPNkjyjyYAV1ctBsY64m1j07SEmypyIpxKpe_Uyx4=.7f96d8fc-b45b-4324-9ac2-ff5056d15d3a@github.com>

On Wed, 20 Nov 2024 07:20:32 GMT, Laurent Bourg?s <lbourges at openjdk.org> wrote:

> I will check today if any 'bad' pattern is remaining in the openjdk master source folder... to be sure.
> 
> Maybe improving jni documentation would be great in another issue...

Thanks for checking @bourgesl. The JNI docs did in fact get an update as well in [JDK-8341799](https://bugs.openjdk.org/browse/JDK-8341799).

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22266#issuecomment-2489223014

From naoto at openjdk.org  Wed Nov 20 18:03:18 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 18:03:18 GMT
Subject: RFR: 8344589: Update IANA Language Subtag Registry to Version
 2024-11-19
In-Reply-To: <gAQGUkG03O5urb6kto7g-kg9mTz0SrDPLfJj57oky8g=.1f7918c0-7edf-43c8-bd97-4bf050d8f034@github.com>
References: <gAQGUkG03O5urb6kto7g-kg9mTz0SrDPLfJj57oky8g=.1f7918c0-7edf-43c8-bd97-4bf050d8f034@github.com>
Message-ID: <lr1hr1fF3lcdGRUwW5FM0Y99t27hhomnzU9QN_dU8eI=.180a49b2-f31a-4356-bdb8-3d46078498bb@github.com>

On Wed, 20 Nov 2024 02:59:54 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which keeps the IANA language subtag registry data up to date with release _2024-11-19_.
> 
> The changes are trivial and Locale tests pass as expected.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22265#pullrequestreview-2449347637

From bchristi at openjdk.org  Wed Nov 20 18:03:53 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 20 Nov 2024 18:03:53 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs [v4]
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <mS4r8sOV8zEIlo1XkwszHNt7w5hGdl9UkPxEYfP7_fI=.1ae55c11-11f0-46a1-9010-9bcc4ac9aa8a@github.com>

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  fix indentation, add braces

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22252/files
  - new: https://git.openjdk.org/jdk/pull/22252/files/452db4e4..a532f8a2

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=02-03

  Stats: 15 lines in 1 file changed: 1 ins; 0 del; 14 mod
  Patch: https://git.openjdk.org/jdk/pull/22252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22252/head:pull/22252

PR: https://git.openjdk.org/jdk/pull/22252

From alanb at openjdk.org  Wed Nov 20 18:05:22 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 18:05:22 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
Message-ID: <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>

On Wed, 20 Nov 2024 17:27:18 GMT, jyxzwd <duke at openjdk.org> wrote:

> yeah,I tested it a few mins ago.It works well in the situation mentioned in the issue and in the normal situation, also when a remote/target jdk is set. But I have a doubt, when only using the local jdk, no remote/targetjdk, that is, ImageReaderFactory.class.getClassLoader() will be null, when loading any class located in the runtime image, BOOT_MODULES_JIMAGE will always be the path provided by the built-in default FileSystemProvider. The user-defined FileSystemProvider will make no contribution to loading the classes that exist in the image in this case.Although the built-in default FileSystemProvider is sufficient, are my concerns redundant?

If a tool is using jrtfs to get at the classes/resources in another run-time image then you'll have two versions of the jrt FileSystemProvider and the support jimage support in use. For the local case (current runtime), the classes comes from java.base and be defined to the boot module. For the remote case, the classes will be loaded from the remote jrt-fs.jar and defined to custom class loader (see JrtFsLoader in JrtFileSystemProvider).

It gets complicated once you replace the default file system provider. The change means the "local" provider and image reader won't go through the custom file system provider. The "remote" provider and image reader will have their I/O intercepted by the custom file system provider.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489237978

From naoto at openjdk.org  Wed Nov 20 18:06:14 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 18:06:14 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <fmMbpUFvBu7fVxIm6c2TuXsEwzg0Ckl6ux5W_SAJsGg=.33ea7435-8048-4d6c-a4fa-aecef0f90c4a@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

Marked as reviewed by naoto (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2449357730

From bchristi at openjdk.org  Wed Nov 20 18:07:20 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 20 Nov 2024 18:07:20 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs moduleRemove
 SecMgr, etc usage from java.prefs [v3]
In-Reply-To: <gAx6LiDB7VIX8Sg5B6gGdwjhtJUYo1u1UFQpEQr_lQo=.c2541bc5-952d-4700-897e-25504cee2a10@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <yPUx983DZfehEsGqvS2VcBYlr1hFWn9FOpua6L-K9IA=.c778f275-7225-422e-8178-7f054eec2f8b@github.com>
 <gAx6LiDB7VIX8Sg5B6gGdwjhtJUYo1u1UFQpEQr_lQo=.c2541bc5-952d-4700-897e-25504cee2a10@github.com>
Message-ID: <i1jy2kGlXp79DzT_GTEN5BTSUOUu0pFze_863xTZ-Gs=.c86ec739-ecee-4cdc-abb3-1588f63927bd@github.com>

On Tue, 19 Nov 2024 23:37:00 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> I think the try-block at line 137 in FileSystemPreferences would be more readable if it were indented. I know it was not indented in the original, either.

Oh, yeah, I don't like that either. :(
Fixed; also added {}s.
Thanks.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22252#issuecomment-2489242403

From asemenyuk at openjdk.org  Wed Nov 20 18:33:04 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Wed, 20 Nov 2024 18:33:04 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v4]
In-Reply-To: <5Y0MQng8FBGkm4iUYrEucI2hRz459l8DeN_iBN9Am94=.074c220f-cbf6-4410-a05f-6810397ccc3b@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <5Y0MQng8FBGkm4iUYrEucI2hRz459l8DeN_iBN9Am94=.074c220f-cbf6-4410-a05f-6810397ccc3b@github.com>
Message-ID: <yGwlKvIpzTL673rShlvxLRqnarQWNeWIWyUhwUfqKfk=.3a61ebe3-3073-419c-bf00-f5f3235387ab@github.com>

On Wed, 20 Nov 2024 04:22:48 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

>> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 437". This ensures that the English message "No Instance(s) Available." is output on localized windows platforms.
>> 
>> I have referred to the following for how to use chcp:
>> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
>> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
>> 
>> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
>> 
>> Thanks
>
> Taizo Kurashige has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix about size of cmdline

Marked as reviewed by asemenyuk (Reviewer).

Thank you for working on this patch!

-------------

PR Review: https://git.openjdk.org/jdk/pull/22142#pullrequestreview-2449371963
PR Comment: https://git.openjdk.org/jdk/pull/22142#issuecomment-2489257196

From duke at openjdk.org  Wed Nov 20 18:33:27 2024
From: duke at openjdk.org (jyxzwd)
Date: Wed, 20 Nov 2024 18:33:27 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
 <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
Message-ID: <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>

On Wed, 20 Nov 2024 18:02:35 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > yeah,I tested it a few mins ago.It works well in the situation mentioned in the issue and in the normal situation, also when a remote/target jdk is set. But I have a doubt, when only using the local jdk, no remote/targetjdk, that is, ImageReaderFactory.class.getClassLoader() will be null, when loading any class located in the runtime image, BOOT_MODULES_JIMAGE will always be the path provided by the built-in default FileSystemProvider. The user-defined FileSystemProvider will make no contribution to loading the classes that exist in the image in this case.Although the built-in default FileSystemProvider is sufficient, are my concerns redundant?
> 
> If a tool is using jrtfs to get at the classes/resources in another run-time image then you'll have two versions of the jrt FileSystemProvider and the support jimage support in use. For the local case (current runtime), the classes comes from java.base and be defined to the boot module. For the remote case, the classes will be loaded from the remote jrt-fs.jar and defined to custom class loader (see JrtFsLoader in JrtFileSystemProvider).
> 
> It gets complicated once you replace the default file system provider. The change means the "local" provider and image reader won't go through the custom file system provider. The "remote" provider and image reader will have their I/O intercepted by the custom file system provider.

I see, thank you for your detailed explanation! Should I submit the modifications mentioned above to a commit, or should I conduct further testing first?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2489269311

From sgehwolf at openjdk.org  Wed Nov 20 18:33:33 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Wed, 20 Nov 2024 18:33:33 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <Nl80cozOc5SpANdrtEnhpc5JgnxKf6HkoVQ_oXHBYwI=.be23587d-c0f2-421f-8a47-260f080be1c8@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
 <Nl80cozOc5SpANdrtEnhpc5JgnxKf6HkoVQ_oXHBYwI=.be23587d-c0f2-421f-8a47-260f080be1c8@github.com>
Message-ID: <E4Qx7K6295aLj369R3EAxUXnqEClsNNhJ5JtELYMPZY=.8d676e9b-f967-4164-8650-9a5bbb82a8a2@github.com>

On Wed, 20 Nov 2024 17:45:18 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> I had hoped you would get more feedback on the proposal.

Sorry about that. There weren't any major objections, so I moved forward as there was radio-silence for a while:
https://mail.openjdk.org/pipermail/core-libs-dev/2024-November/134623.html

We can discuss more details here, perhaps? I can withdraw the proposal as well.

> If we do expose the property then I'm wondering about the JDK-specific properties documented in System.getProperties, and also thinking about java -XshowSettings output.

Makes sense. Some comments:

- `System.getProperties()` doesn't list all JDK specific properties currently. `jdk.debug` is one. It lists some others, like `jdk.module.path`. So I wasn't sure if it needed to be mentioned in `@implNote`.
- `-XshowSettings` output changes in the same way as the property is being set. I.e. on a `--patch-module`-including invocation it would show it. Similar to `jdk.module.path` (when not set it's not there, when set it shows up).

> test/jdk/java/lang/System/patchedModule/ModulePatcherTest.java line 39:
> 
>> 37:  * @run main/othervm --patch-module=java.base=${test.classes} ModulePatcherTest true
>> 38:  */
>> 39: public class ModulePatcherTest {
> 
> The existing tests for --patch-module are in test/jdk/tools/launcher/modules/patch, we might want to see if we should just update one of the existing tests or move the new test with a name that makes it clear it's testing the property.

Thanks. Couldn't find the place where existing tests were (I tried to look). I'll take a look and will adjust.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2489262194
PR Review Comment: https://git.openjdk.org/jdk/pull/22277#discussion_r1850782371

From naoto at openjdk.org  Wed Nov 20 18:33:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 18:33:35 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v3]
In-Reply-To: <vE7O7eohfvzyh6dyKqtUwNl2MgZutk8iz79kckxSttY=.762a5087-9176-4d8d-8bcc-a205d545034f@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <vE7O7eohfvzyh6dyKqtUwNl2MgZutk8iz79kckxSttY=.762a5087-9176-4d8d-8bcc-a205d545034f@github.com>
Message-ID: <sRqt5oxkg9xl7W2Pxwnz0CtKbqJpMNjZ8c996a84CBQ=.67c3ab45-f6c2-496a-95cd-be406ac0f194@github.com>

On Wed, 20 Nov 2024 03:03:22 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change.
>> 
>> APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
>> Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   address Naoto's comments

Thanks for the changes. A couple of minor comments

src/java.base/share/classes/java/util/Locale.java line 1256:

> 1254: 
> 1255:     /**
> 1256:      * {@return an array of deployed locales}

Since "deployed" is the term from ServiceLoader, it might mean only referring to SPI impls, so how about simply "available"?

-------------

PR Review: https://git.openjdk.org/jdk/pull/22192#pullrequestreview-2449377299
PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1850787428

From naoto at openjdk.org  Wed Nov 20 18:33:36 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 18:33:36 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v3]
In-Reply-To: <Y9OuBynI-KIhZQ_il_zV0csS7SxtBBPN62SFaMf1nJs=.f91540a0-740e-4ded-896c-6f50959e8c5c@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <8W7-Y64Rn1pVLuPfLoAktG-ekfebPelcoWQbxxiEMjE=.f07e118b-99ea-4ef0-909d-6141b08e4a55@github.com>
 <SrzJo73RPFigmAaiueCT3eIwWsTGihps9ScE0I_kuXw=.67aa29f8-d82e-4d67-8e24-415da708d173@github.com>
 <Y9OuBynI-KIhZQ_il_zV0csS7SxtBBPN62SFaMf1nJs=.f91540a0-740e-4ded-896c-6f50959e8c5c@github.com>
Message-ID: <0i1cQoY85au5SjDgWicrVBvwWQrSDR-ju3sCVNFxZRU=.da84ec2a-47b8-4f75-ad28-38811223b7b9@github.com>

On Wed, 20 Nov 2024 02:58:45 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> src/java.base/share/classes/java/util/Locale.java line 144:
>> 
>>> 142:  *   each indicating its own semantics, these values should be ordered
>>> 143:  *   by importance, with most important first, separated by
>>> 144:  *   underscore('_').  The variant field is case sensitive.</dd>
>> 
>> This part "separated by underscore('_')" is missing in the revised doc
>
> I intentionally omitted this because
> 
> - I thought it was redundant as the syntax already follows a few lines below.
> - The `Locale` syntax allows both `_` and  `-`, not just `_`.
> 
> However, if you think it should remain, I'll restore it as `separated by ('_'|'-')`.

I was thinking how to parse "XX_YY-Z" variant. Since it is not well-formed subtags in BCP 47 definition, it should be delimited by `_` so there would be two values, "XX" and "YY-Z" according to the current spec. However, I understand that the implementation treats '_' and '-' equally both for well-formed and ill-formed variant values, I think it's better to put `separated by ('_'|'-')` to remedy the spec.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1850781651

From alanb at openjdk.org  Wed Nov 20 18:37:26 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 18:37:26 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <E4Qx7K6295aLj369R3EAxUXnqEClsNNhJ5JtELYMPZY=.8d676e9b-f967-4164-8650-9a5bbb82a8a2@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
 <Nl80cozOc5SpANdrtEnhpc5JgnxKf6HkoVQ_oXHBYwI=.be23587d-c0f2-421f-8a47-260f080be1c8@github.com>
 <E4Qx7K6295aLj369R3EAxUXnqEClsNNhJ5JtELYMPZY=.8d676e9b-f967-4164-8650-9a5bbb82a8a2@github.com>
Message-ID: <jR29J8pK3JUAgb3xSItXhm2UO0wUR_A09mlJeBzgFGw=.16ebbfd1-225e-4f74-8a03-08d7aab5dd23@github.com>

On Wed, 20 Nov 2024 18:16:22 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Sorry about that. There weren't any major objections, so I moved forward as there was radio-silence for a while:

That's okay, my comment wasn't aimed at you, it was instead just observing that there wasn't much feedback.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2489293392

From mbalao at openjdk.org  Wed Nov 20 18:40:51 2024
From: mbalao at openjdk.org (Martin Balao)
Date: Wed, 20 Nov 2024 18:40:51 GMT
Subject: RFR: 8315487: Security Providers Filter [v10]
In-Reply-To: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
References: <NJxsscjvpzhjYrr9cmC7YtGXG-mVr3naI8u071Ih1KY=.4dd2a0e2-a917-4ffe-b150-dd5e6fbfd6cf@github.com>
Message-ID: <UkuWwoWl5kl4jVT8Wmm6js5rbzPDMtkdvQHM9Tutays=.4b653dd4-8493-4a99-8a19-19eb9b071534@github.com>

> In addition to the goals, scope, motivation, specification and requirement notes in [JDK-8315487](https://bugs.openjdk.org/browse/JDK-8315487), we would like to describe the most relevant decisions taken during the implementation of this enhancement. These notes are organized by feature, may encompass more than one file or code segment, and are aimed to provide a high-level view of this PR.
> 
> ## ProvidersFilter
> 
> ### Filter construction (parser)
> 
> The providers filter is constructed from a string value, taken from either a system or a security property with name "jdk.security.providers.filter". This process occurs at sun.security.jca.ProvidersFilter class ?simply referred as ProvidersFilter onward? static initialization. Thus, changes to the filter's overridable property are not effective afterwards and no assumptions should be made regarding when this class gets initialized.
> 
> The filter's string value is processed with a custom parser of order 'n', being 'n' the number of characters. The parser, represented by the ProvidersFilter.Parser class, can be characterized as a Deterministic Finite Automaton (DFA). The ProvidersFilter.Parser::parse method is the starting point to get characters from the filter's string value and generate state transitions in the parser's internal state-machine. See ProvidersFilter.Parser::nextState for more details about the parser's states and both valid and invalid transitions. The ParsingState enum defines valid parser states and Transition the reasons to move between states. If a filter string cannot be parsed, a ProvidersFilter.ParserException exception is thrown, and turned into an unchecked IllegalArgumentException in the ProvidersFilter.Filter constructor.
> 
> While we analyzed ?and even tried, at early stages of the development? the use of regular expressions for filter parsing, we discarded the approach in order to get maximum performance, support a more advanced syntax and have flexibility for further extensions in the future.
> 
> ### Filter (structure and behavior)
> 
> A filter is represented by the ProvidersFilter.Filter class. It consists of an ordered list of rules, returned by the parser, that represents filter patterns from left to right (see the filter syntax for reference). At the end of this list, a match-all and deny rule is added for default behavior. When a service is evaluated against the filter, each filter rule is checked in the ProvidersFilter.Filter::apply method. The rule makes an allow or deny decision if the ser...

Martin Balao has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains nine commits:

 - Merge 'openjdk/master' into JDK-8315487
   
   Below is a conflicts resolution summary.
   
   Trivial conflict, caused by 2a1ae0ff89a8ac364206b09059d9dc884adcc5ac:
     src/java.base/share/classes/java/security/Provider.java
   
   Drop unnecessary change after db85090553ab14a84c3ed0a2604dd56c5b6e6982:
     src/java.base/share/lib/security/default.policy
   
   Trivial conflict, caused by 0329855831102a48abf14b5befc933f84dfd3460:
     test/jdk/tools/launcher/Settings.java
 - Remove -Xdebug from commented-out debug command
   
   This is unnecessary, see 842d6329cf5a3da8df7eddb195b5fcb7baadbdc3.
 - Merge 'openjdk/master' into JDK-8315487
   
   Resolved conflicts:
     src/java.base/share/classes/java/security/Provider.java
     src/java.base/share/classes/javax/crypto/Cipher.java
     src/java.base/share/classes/sun/security/jca/ProviderList.java
     src/java.base/share/conf/security/java.security
     src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java
   
   Additional fixes:
     src/java.base/share/classes/java/security/Security.java
       Import sun.security.jca.ProvidersFilter, since the sun.security.jca.*
       import was removed in c6f1d5f374bfa9bde75765391d5dae0e8e28b4ab.
     src/java.base/share/classes/sun/security/jca/GetInstance.java
       Adjust GetInstance::getCipherServices return type to Iterator<Service>.
     src/java.base/share/classes/sun/security/jca/ProvidersFilter.java
       Rename CipherServiceList to CipherServiceIterator in comment.
 - Minor changes to align with the JEP.
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - ProvidersFilterTest extended to cover all JCA service types.
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at openjdk.org>
 - Support for cipher transformations and JEP alignment
   of the java.security documentation.
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>
 - Copyright dates update.
 - More clear text in invalid pattern exception.
 - 8315487: Security Providers Filter
   
   Co-authored-by: Francisco Ferrari Bihurriet <fferrari at redhat.com>
   Co-authored-by: Martin Balao <mbalao at redhat.com>

-------------

Changes: https://git.openjdk.org/jdk/pull/15539/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=15539&range=09
  Stats: 5224 lines in 24 files changed: 4596 ins; 353 del; 275 mod
  Patch: https://git.openjdk.org/jdk/pull/15539.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/15539/head:pull/15539

PR: https://git.openjdk.org/jdk/pull/15539

From bpb at openjdk.org  Wed Nov 20 18:49:21 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 18:49:21 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v4]
In-Reply-To: <mS4r8sOV8zEIlo1XkwszHNt7w5hGdl9UkPxEYfP7_fI=.1ae55c11-11f0-46a1-9010-9bcc4ac9aa8a@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <mS4r8sOV8zEIlo1XkwszHNt7w5hGdl9UkPxEYfP7_fI=.1ae55c11-11f0-46a1-9010-9bcc4ac9aa8a@github.com>
Message-ID: <rQrkrAPBWvcOZIqdRo42_-jSnJ2-XBUkGxBBsmtFEwg=.ad6143e4-23c6-4e88-988d-e89826ee3f82@github.com>

On Wed, 20 Nov 2024 18:03:53 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   fix indentation, add braces

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 127:

> 125:                 getLogger().info("Created user preferences directory.");
> 126:             }
> 127:             else

It seems odd that `else` is not on line 126 after the bracket. If putting it on the same line makes it  less readable, then maybe add a pair of brackets for the `else`.

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 586:

> 584:                 m = new TreeMap<>();
> 585:             } else if (e instanceof FileNotFoundException) {
> 586:             getLogger().warning("Prefs file removed in background "

This could be indented.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1850819795
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1850816922

From iris at openjdk.org  Wed Nov 20 18:57:13 2024
From: iris at openjdk.org (Iris Clark)
Date: Wed, 20 Nov 2024 18:57:13 GMT
Subject: RFR: 8344525: Fix leftover ExceptionOccurred in java.base
In-Reply-To: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
References: <8t6Z0tkNwMZDVXiZ5HfVa_edomt1ZrqcXLybOS-PaXw=.45296e26-ba08-4c7e-9000-068d869bc267@github.com>
Message-ID: <cp2GBR7hb6E-Va1wEaSuUlSZWaznWNA-u-y9vglMG4c=.975f8c0b-4328-45a0-9e1f-f4de64f6d5d0@github.com>

On Wed, 20 Nov 2024 03:02:39 GMT, Justin Lu <jlu at openjdk.org> wrote:

> Please review this PR which removes the leftover ocurrences of incorrect JNI `ExceptionOccurred(env)` usage within _java.base_. 
> 
> This PR also includes 9 cases of `if (ExceptionOccurred(env) == NULL)`. While these occurrences are fine and were intentionally not removed during the first pass, it would be consistent with the other related JNI ExceptionOccurred cleanups to include them here as well. Making the swap also avoids creating the `jthrowable` reference in the first place (even if automatically freed later).
> 
> After this patch, the remaining instances of `ExceptionOccurred(env)` within _j.base_ are used with intent to create the `jthrowable` reference.

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22266#pullrequestreview-2449454066

From naoto at openjdk.org  Wed Nov 20 19:03:35 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 19:03:35 GMT
Subject: RFR: 8319993: Update Unicode Data Files to 16.0.0
Message-ID: <lhjftuxraeNfYcmqtLlHjH0COs5-oyjaZlz_oMsoUG0=.5c1fc0e0-781d-4610-ab0c-6ed8fd4b525c@github.com>

Updates the JDK to use the latest Unicode 16.0.0, which also updates the ICU4J along with it (8319992: Update ICU4J to Version 76.1). The corresponding CSR has already been approved.

-------------

Commit messages:
 - icu.md changes
 - Merge branch 'master' into JDK-8319993-Unicode-16
 - Merge branch 'master' into JDK-8319993-Unicode-16
 - Merge branch 'master' into JDK-8319993-Unicode-16
 - Fixing UnicodeBlock aliases for TULU_TIGALARI
 - ICU4J 76.1 release
 - .md files
 - ICU4J changes
 - iniital commit

Changes: https://git.openjdk.org/jdk/pull/21771/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=21771&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8319993
  Stats: 8442 lines in 29 files changed: 7542 ins; 296 del; 604 mod
  Patch: https://git.openjdk.org/jdk/pull/21771.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21771/head:pull/21771

PR: https://git.openjdk.org/jdk/pull/21771

From jvernee at openjdk.org  Wed Nov 20 19:15:27 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 20 Nov 2024 19:15:27 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v17]
In-Reply-To: <QNztJmsbdKcFfTnxsaFtSge7UUN_rISWqjomeR-_Hro=.599db9bc-8ff9-4b02-8ee8-06d351ce2a2b@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <QNztJmsbdKcFfTnxsaFtSge7UUN_rISWqjomeR-_Hro=.599db9bc-8ff9-4b02-8ee8-06d351ce2a2b@github.com>
Message-ID: <VsJnhjSwEoL3yg7dqZeOypEBPN0EjF7Uh25KDPUeYWA=.7fb097e7-1863-47ff-87fb-eab0bb43c000@github.com>

On Wed, 20 Nov 2024 13:46:49 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 36 additional commits since the last revision:
> 
>  - Update after comments
>  - Merge branch 'master' into linker-padding-layout-only
>  - Fix failing test
>  - Merge branch 'master' into linker-padding-layout-only
>  - Update after comments
>  - Merge branch 'master' into linker-padding-layout-only
>  - Simplify exception testing
>  - Merge branch 'master' into linker-padding-layout-only
>  - Remove redundant check
>  - Rephrase doc
>  - ... and 26 more: https://git.openjdk.org/jdk/compare/2f4888ed...28b3ad6d

Could you also add test cases for the other two unions I mentioned?


MemoryLayout.unionLayout(MemoryLayout.paddingLayout(4), ValueLayout.JAVA_INT);
MemoryLayout.unionLayout(MemoryLayout.paddingLayout(5), ValueLayout.JAVA_INT):


Both of those should be rejected.

src/java.base/share/classes/jdk/internal/foreign/abi/AbstractLinker.java line 222:

> 220:                 if (!(member instanceof PaddingLayout pl)) {
> 221:                     maxUnpaddedLayout = Long.max(maxUnpaddedLayout, member.byteSize());
> 222:                 } else {

I think we're still missing a check here to see if a union contains at most 1 padding layout?

Something like this:


MemoryLayout.unionLayout(
    MemoryLayout.sequenceLayout(3, ValueLayout.JAVA_INT),
    ValueLayout.JAVA_LONG,
    MemoryLayout.paddingLayout(16),
    MemoryLayout.paddingLayout(16)):


Should be rejected.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21041#pullrequestreview-2449463637
PR Review Comment: https://git.openjdk.org/jdk/pull/21041#discussion_r1850835087

From jvernee at openjdk.org  Wed Nov 20 19:18:19 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 20 Nov 2024 19:18:19 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v13]
In-Reply-To: <iPnni7OibP4hXdq5zUM7SEtkugZcE4LnZHF3R_Gj6N8=.9a6df19f-80f8-4ca1-ba57-c63cffb75f7a@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <e5AoQnwnl2vLztV4xKNjhSxusEDjOk7cCb_4RwVdVk4=.003bb6ac-f1eb-40ed-a25c-dae005cbc727@github.com>
 <LawuEa23JaOsGyhzvMd2OBz8CsLM9svCKcIRvPANiMk=.3f16cca7-2188-4cd5-8045-fdd19f5fb965@github.com>
 <USOSWDBf9RVnSHwWTBLioLapegwVCQDYJ6N25uFTOXk=.2601aac7-1bc3-45aa-bc36-30e01f900961@github.com>
 <iPnni7OibP4hXdq5zUM7SEtkugZcE4LnZHF3R_Gj6N8=.9a6df19f-80f8-4ca1-ba57-c63cffb75f7a@github.com>
Message-ID: <NLAtK0ceKW46Xw1LCxDwF-sOP5HGoxndTHeo0wX96pM=.a2b069ae-0f60-461b-b866-f7aba435a67c@github.com>

On Mon, 11 Nov 2024 17:28:34 GMT, Maurizio Cimadamore <mcimadamore at openjdk.org> wrote:

> > Maybe we should also check that padding layouts have natural alignment? The alignment of padding layouts can affect the alignment of the enclosing container.
> 
> This makes sense, but I wonder if that would require a change in the javadoc?

Also, we should decide if we want to include this or not. I think this can help prevent silly things like:


MemoryLayout.unionLayout(
    ValueLayout.JAVA_INT,
    MemoryLayout.paddingLayout(8).withByteAlignment(8)):


from being accepted by the check in `checkGroup`.

A single bullet in the criteria for well-formed layouts stating that padding layouts must be naturally aligned seems enough? (And the check in the implementation should be simple as well).

Though, I'm still wondering if we don't want to reject that at the layout API level instead. i.e. have `withByteAlignment` throw an exception for `PaddingLayout`.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2489360595

From dfuchs at openjdk.org  Wed Nov 20 19:44:27 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 19:44:27 GMT
Subject: RFR: 8344235: Revisit SecurityManager usage in java.logging after JEP
 486 integration
Message-ID: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>

This PR remove usage of SecurityManager, doPrivileges, etc... from `java.logging` and `java.base/jdk.internal.logger`

Only notable hack - Logger.checkPermission() no longer checks permissions, but has been renamed into `ensureLogManagerInitialized()` in order to avoid disturbing the initialization sequence of Logger/LogManager.

I am not 100% sure this is still needed - but I remember we had some entanglement issues in the past that had been hard to solve, so it seemed prudent to keep the call:


    if (manager == null) {
        manager = LogManager.getLogManager();
    }


where `manager` is a private volatile field in Logger.

-------------

Commit messages:
 - 8344235: Revisit SecurityManager usage in java.logging after JEP 486 integration
 - 8344235: Revisit SecurityManager usage in java.logging after JEP 486 integration

Changes: https://git.openjdk.org/jdk/pull/22281/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22281&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344235
  Stats: 953 lines in 17 files changed: 47 ins; 746 del; 160 mod
  Patch: https://git.openjdk.org/jdk/pull/22281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22281/head:pull/22281

PR: https://git.openjdk.org/jdk/pull/22281

From eirbjo at openjdk.org  Wed Nov 20 19:47:32 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Wed, 20 Nov 2024 19:47:32 GMT
Subject: Withdrawn: 8340887: Add micro benchmark comparing input stream
 performance of ZipFile vs ZipInputStream
In-Reply-To: <yrTkspfd60XRlM8J2fdlf55HuooLh9vfqw_p9AMRFIY=.75bf052d-3086-4f79-8441-c84b514e7260@github.com>
References: <yrTkspfd60XRlM8J2fdlf55HuooLh9vfqw_p9AMRFIY=.75bf052d-3086-4f79-8441-c84b514e7260@github.com>
Message-ID: <2WGukzoa9tOeby9z6jbGCpAE4K-fLShUb59cB3ElNA0=.b73c1cf0-1055-47df-bd1f-a0c11c4e1316@github.com>

On Wed, 25 Sep 2024 10:28:02 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this test-only PR which adds a micro benchmark exploring performance differences between reading entry data sequentially from a `ZipFile` and reading the same entries using `ZipInputStream` wrapping a `BufferedInputStream`.
> 
> Spoiler alert: `ZipFile` streams are ~1.8 X slower on my machine compared to `ZipInputStream`:
> 
> 
> Benchmark                               (buffered)  (method)  (size)  Mode  Cnt     Score     Error  Units
> ReadZipStreams.zipFile                        true  DEFLATED    1024  avgt   15  7871.679 ? 278.719  us/op
> ReadZipStreams.zipFile                        true    STORED    1024  avgt   15  4976.571 ?  87.311  us/op
> ReadZipStreams.zipInputStream                 true  DEFLATED    1024  avgt   15  4345.494 ?  40.628  us/op
> ReadZipStreams.zipInputStream                 true    STORED    1024  avgt   15  2652.063 ?  13.617  us/op
> 
> 
>  When not using `BufferedInputStream`, most of the difference disappears, so this is probably related to `ZipFileInputStream`'s lack of buffering:
> 
> 
> ReadZipStreams.zipFile                       false  DEFLATED    1024  avgt   15  7980.705 ? 490.846  us/op
> ReadZipStreams.zipFile                       false    STORED    1024  avgt   15  4994.301 ?  52.762  us/op
> ReadZipStreams.zipInputStream                false  DEFLATED    1024  avgt   15  8367.171 ?  81.631  us/op
> ReadZipStreams.zipInputStream                false    STORED    1024  avgt   15  4811.824 ?  47.859  us/op

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/21178

From rriggs at openjdk.org  Wed Nov 20 19:47:36 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Nov 2024 19:47:36 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
Message-ID: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>

Removed use of SecurityManager to check permissions.
Relaxed defensive copying of byte arrays (due to lack of SM)

Refresh of PR#22168 Including review comments made there.

-------------

Commit messages:
 - Refactor package private method `codeSource` into Module where it is used.
 - Review suggestions applied:
 - 8344336: SM cleanup of java.lang.System, Runtime, String, StackWalker

Changes: https://git.openjdk.org/jdk/pull/22282/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22282&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344336
  Stats: 208 lines in 6 files changed: 5 ins; 194 del; 9 mod
  Patch: https://git.openjdk.org/jdk/pull/22282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22282/head:pull/22282

PR: https://git.openjdk.org/jdk/pull/22282

From duke at openjdk.org  Wed Nov 20 19:50:20 2024
From: duke at openjdk.org (duke)
Date: Wed, 20 Nov 2024 19:50:20 GMT
Subject: RFR: 8344595: State transitions in internal VirtualThread comment
 needs to be updated
In-Reply-To: <o2GTTWzwJoKfc5yzzqCPasvgpeMOAVrI8OInUTIYLy4=.77ff531b-68b5-4f27-b4d6-2cdc119cde53@github.com>
References: <o2GTTWzwJoKfc5yzzqCPasvgpeMOAVrI8OInUTIYLy4=.77ff531b-68b5-4f27-b4d6-2cdc119cde53@github.com>
Message-ID: <m_Y_gjjvGRqcZ9ujf_FZclEnskwDkH9gGCURe_cJtz8=.c5e6df9d-dc38-4b5f-b7f9-7c3948fe337e@github.com>

On Tue, 19 Nov 2024 19:33:18 GMT, kabutz <duke at openjdk.org> wrote:

> See internal bug review 9077848
> 
> This is a very small unimportant mistake in the naming of the documentation that does not match the code.

@kabutz 
Your change (at version 2817981d67c561580f262c049384be6f7fe6520f) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22253#issuecomment-2489417374

From dfuchs at openjdk.org  Wed Nov 20 20:00:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Wed, 20 Nov 2024 20:00:14 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
References: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
Message-ID: <RDyTUcftWatL0wQbIC2O5m_2z96wP1tt2ckdzSLfrF4=.575cc4de-631e-44ed-a565-bdabb6cf4271@github.com>

On Wed, 20 Nov 2024 19:42:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)
> 
> Refresh of PR#22168 Including review comments made there.

The changes to SystemLogger looks OK to me. Maybe you could get rid of the LoggerFinder `private static Void checkPermission()` method altogether?

And also of the associated private constructor `LoggerFinder(Void)` as well as the 

static final RuntimePermission LOGGERFINDER_PERMISSION =
new RuntimePermission("loggerFinder");

constant (which should no longer be needed now?)

Note: I am taking care of the System.Logger default implementation classes in https://github.com/openjdk/jdk/pull/22281.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22282#pullrequestreview-2449564572
PR Review: https://git.openjdk.org/jdk/pull/22282#pullrequestreview-2449568644
PR Comment: https://git.openjdk.org/jdk/pull/22282#issuecomment-2489432747

From duke at openjdk.org  Wed Nov 20 20:04:18 2024
From: duke at openjdk.org (kabutz)
Date: Wed, 20 Nov 2024 20:04:18 GMT
Subject: Integrated: 8344595: State transitions in internal VirtualThread
 comment needs to be updated
In-Reply-To: <o2GTTWzwJoKfc5yzzqCPasvgpeMOAVrI8OInUTIYLy4=.77ff531b-68b5-4f27-b4d6-2cdc119cde53@github.com>
References: <o2GTTWzwJoKfc5yzzqCPasvgpeMOAVrI8OInUTIYLy4=.77ff531b-68b5-4f27-b4d6-2cdc119cde53@github.com>
Message-ID: <W5mH0sI47qbIBjybJ8I-5WtazHqy2vwxVl1Vfe3Fwwc=.52ec3eda-a3e7-4ed3-85ff-cac3de88aea8@github.com>

On Tue, 19 Nov 2024 19:33:18 GMT, kabutz <duke at openjdk.org> wrote:

> See internal bug review 9077848
> 
> This is a very small unimportant mistake in the naming of the documentation that does not match the code.

This pull request has now been integrated.

Changeset: da2d7a09
Author:    Dr Heinz M. Kabutz <heinz at javaspecialists.eu>
Committer: Alan Bateman <alanb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/da2d7a09f92df547661587348f768f69f0e5a23b
Stats:     6 lines in 1 file changed: 0 ins; 0 del; 6 mod

8344595: State transitions in internal VirtualThread comment needs to be updated

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22253

From alanb at openjdk.org  Wed Nov 20 20:21:58 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Wed, 20 Nov 2024 20:21:58 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker
In-Reply-To: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
References: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
Message-ID: <39dW9bP-T2eqDfRFykaYjXtVK2ev7kAowGgevih42OM=.ee1bf31a-049c-4903-92da-359e2478ec7c@github.com>

On Wed, 20 Nov 2024 19:42:58 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)
> 
> Refresh of PR#22168 Including review comments made there.

I agree with Daniel that LOGGERFINDER_PERMISSION and the special constructor to ensure the permission check can be removed. I skimmed through the rest, including the change to Module since the other PR, and it looks fine.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22282#issuecomment-2489468887

From rriggs at openjdk.org  Wed Nov 20 20:53:09 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Nov 2024 20:53:09 GMT
Subject: RFR: 8344235: Revisit SecurityManager usage in java.logging after
 JEP 486 integration
In-Reply-To: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
References: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
Message-ID: <gGR8r4gr9nKfZvAVhHdh_cJ2vlFAaJEFxGMb2Lo3lbU=.08cc03a8-0754-4d56-aa48-8c1a5bc28ba7@github.com>

On Wed, 20 Nov 2024 19:39:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This PR remove usage of SecurityManager, doPrivileges, etc... from `java.logging` and `java.base/jdk.internal.logger`
> 
> Only notable hack - Logger.checkPermission() no longer checks permissions, but has been renamed into `ensureLogManagerInitialized()` in order to avoid disturbing the initialization sequence of Logger/LogManager.
> 
> I am not 100% sure this is still needed - but I remember we had some entanglement issues in the past that had been hard to solve, so it seemed prudent to keep the call:
> 
> 
>     if (manager == null) {
>         manager = LogManager.getLogManager();
>     }
> 
> 
> where `manager` is a private volatile field in Logger.

Looks good

src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 114:

> 112: 
> 113:     private static Iterator<System.LoggerFinder> findLoggerFinderProviders() {
> 114:         final Iterator<System.LoggerFinder> iterator =

Could be simply be `return ` ... no need for a local var.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22281#pullrequestreview-2449637768
PR Review Comment: https://git.openjdk.org/jdk/pull/22281#discussion_r1850942628

From rriggs at openjdk.org  Wed Nov 20 21:03:33 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Wed, 20 Nov 2024 21:03:33 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v2]
In-Reply-To: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
References: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
Message-ID: <F0UOh57K-vnzYfmMdk-RxCCD-7WIkFWgRSmNU_ZKsVM=.2529c11c-1138-4b54-b973-0a93e37cbe34@github.com>

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)
> 
> Refresh of PR#22168 Including review comments made there.

Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:

  Remove latent permission and checkPermission.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22282/files
  - new: https://git.openjdk.org/jdk/pull/22282/files/d9b01840..a6e71664

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22282&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22282&range=00-01

  Stats: 16 lines in 1 file changed: 0 ins; 16 del; 0 mod
  Patch: https://git.openjdk.org/jdk/pull/22282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22282/head:pull/22282

PR: https://git.openjdk.org/jdk/pull/22282

From dholmes at openjdk.org  Wed Nov 20 21:22:27 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Nov 2024 21:22:27 GMT
Subject: RFR: 8344646: The libjsig deprecation warning should go to stderr not
 stdout
Message-ID: <r4C6D0qAUwFsILFtI6rMOEq4uqgpgUjoAUoxVhKO76I=.20a4dd98-931d-4ecc-b90e-4d1a117afab1@github.com>

In JDK 16 we deprecated the old signal and sigset signal-chaining interfaces under [JDK-8257572](https://bugs.openjdk.org/browse/JDK-8257572). The deprecation warning was written to stdout but all other warnings go to stderr. Having the warning be on stdout causes interference with application output so we change it to stderr.

Testing
 - examined signal test output (see JBS issue)
 - tiers 1-3 sanity

Thanks

-------------

Commit messages:
 - 8344646: The libjsig deprecation warning should go to stderr not stdout

Changes: https://git.openjdk.org/jdk/pull/22283/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22283&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344646
  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22283.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22283/head:pull/22283

PR: https://git.openjdk.org/jdk/pull/22283

From mikael at openjdk.org  Wed Nov 20 21:33:14 2024
From: mikael at openjdk.org (Mikael Vidstedt)
Date: Wed, 20 Nov 2024 21:33:14 GMT
Subject: RFR: 8344646: The libjsig deprecation warning should go to stderr
 not stdout
In-Reply-To: <r4C6D0qAUwFsILFtI6rMOEq4uqgpgUjoAUoxVhKO76I=.20a4dd98-931d-4ecc-b90e-4d1a117afab1@github.com>
References: <r4C6D0qAUwFsILFtI6rMOEq4uqgpgUjoAUoxVhKO76I=.20a4dd98-931d-4ecc-b90e-4d1a117afab1@github.com>
Message-ID: <AoJahWdF1goeGfLYxEdY4_deL4EAgdTqwyvvOlvX0Hw=.69a502fb-23bc-4a5a-b292-61d4e3913ce8@github.com>

On Wed, 20 Nov 2024 21:18:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In JDK 16 we deprecated the old signal and sigset signal-chaining interfaces under [JDK-8257572](https://bugs.openjdk.org/browse/JDK-8257572). The deprecation warning was written to stdout but all other warnings go to stderr. Having the warning be on stdout causes interference with application output so we change it to stderr.
> 
> Testing
>  - examined signal test output (see JBS issue)
>  - tiers 1-3 sanity
> 
> Thanks

Marked as reviewed by mikael (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22283#pullrequestreview-2449737389

From dholmes at openjdk.org  Wed Nov 20 21:33:14 2024
From: dholmes at openjdk.org (David Holmes)
Date: Wed, 20 Nov 2024 21:33:14 GMT
Subject: RFR: 8344646: The libjsig deprecation warning should go to stderr
 not stdout
In-Reply-To: <AoJahWdF1goeGfLYxEdY4_deL4EAgdTqwyvvOlvX0Hw=.69a502fb-23bc-4a5a-b292-61d4e3913ce8@github.com>
References: <r4C6D0qAUwFsILFtI6rMOEq4uqgpgUjoAUoxVhKO76I=.20a4dd98-931d-4ecc-b90e-4d1a117afab1@github.com>
 <AoJahWdF1goeGfLYxEdY4_deL4EAgdTqwyvvOlvX0Hw=.69a502fb-23bc-4a5a-b292-61d4e3913ce8@github.com>
Message-ID: <fTUpULtBLdwZjUx70TUiG7ut3GgHNrNaSpXXUltylOU=.fecc178c-425f-4538-80e6-15405c3509db@github.com>

On Wed, 20 Nov 2024 21:30:32 GMT, Mikael Vidstedt <mikael at openjdk.org> wrote:

>> In JDK 16 we deprecated the old signal and sigset signal-chaining interfaces under [JDK-8257572](https://bugs.openjdk.org/browse/JDK-8257572). The deprecation warning was written to stdout but all other warnings go to stderr. Having the warning be on stdout causes interference with application output so we change it to stderr.
>> 
>> Testing
>>  - examined signal test output (see JBS issue)
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> Marked as reviewed by mikael (Reviewer).

Thanks for the review @vidmik !

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22283#issuecomment-2489580391

From bchristi at openjdk.org  Wed Nov 20 22:43:44 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Wed, 20 Nov 2024 22:43:44 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v5]
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  indentation fixes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22252/files
  - new: https://git.openjdk.org/jdk/pull/22252/files/a532f8a2..cddc4e2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=03-04

  Stats: 6 lines in 1 file changed: 1 ins; 1 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22252/head:pull/22252

PR: https://git.openjdk.org/jdk/pull/22252

From bpb at openjdk.org  Wed Nov 20 22:49:16 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 22:49:16 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v5]
In-Reply-To: <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
Message-ID: <w_N-X0kaPlRAkRq6kulrKgC1VSgd-Yjd9AMBO5TM_c4=.1dd21e12-3427-49e5-ba8d-ac3efa13bbde@github.com>

On Wed, 20 Nov 2024 22:43:44 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation fixes

Looks all right to me now, but you might want also to get a second opinion.

-------------

Marked as reviewed by bpb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22252#pullrequestreview-2449850320

From jvernee at openjdk.org  Wed Nov 20 22:53:15 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Wed, 20 Nov 2024 22:53:15 GMT
Subject: RFR: 8331735: UpcallLinker::on_exit races with GC when copying
 frame anchor
In-Reply-To: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>
References: <4Q4duvOf_UPZkpps6YI0SvRcYYQkG4b7ckTUUTVB494=.9fa7eaec-73fc-43c8-9f69-133630235b2b@github.com>
Message-ID: <Y1PUBIPTLP9ljjZ9Ok5Qd8YXAce7H5o6BKTsfJ7T63w=.425eabc9-3c2a-4c67-aa12-73481fd384cb@github.com>

On Mon, 28 Oct 2024 13:53:58 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> There is a subtle race in `UpcallLinker::on_exit` between copying of the old frame anchor back into place, and the GC. Since this copy is not atomic, it may briefly appear as if a thread has no last Java frame, while still in the `_thread_in_native` state, which leads to the GC skipping processing of any active Java frames.
> 
> This code was originally adapted from `JavaCallWrapper::!JavaCallWrapper` - the JNI mechanism for upcalls - but in that case the frame anchor copy happens in the `_thread_in_vm` state, which means the GC will wait for the thread to get to a safepoint.
> 
> The solution proposed here is to do the frame anchor copy in the java thread state, before transitioning  back to the native state. The java thread state, like the vm thread state, is also 'safe' i.e. the GC will wait for the thread to get to a safepoint, so we can safely do our non-atomic copy of the frame anchor.
> 
> Additionally, this PR resolves a similar issue in `on_entry`, by moving the clearing of the pending exception (in case native code use a JNI API and didn't handle the exception afterwards). We now also skip checking for async exceptions when transitioning from native to java, so we don't immediately clear them. Any async exceptions will be picked up at the next safepoint instead.
> 
> Special thanks to @stefank and @fisk for finding the root cause, and @jaikiran for testing and debugging.
> 
> Testing: tier 1-4, 20k runs of the failing test on linux-aarch64.

> > I wonder if we can assert we are in a safepoint-safe state when doing so?
> 
> I think we can do this. I've prototyped this here: [pr/21742...JornVernee:jdk:SafeFrameAnchor+assert](https://github.com/openjdk/jdk/compare/pr/21742...JornVernee:jdk:SafeFrameAnchor+assert)
> 
> This catches the issue fixed by this patch, and it passes at least tier 1. We'd need something similar in assembly where we touch the frame anchor, is `MacroAssembler::set_last_Java_frame` and `MacroAssembler::reset_last_Java_frame`.

Thinking some more about this: there might be other instances of `JavaFrameAnchor` that are fine to touch when the thread is in the native state. It's just the frame anchor inside a `JavaThread` that can not be touched if that thread is in a certain state. It might be possible to encapsulate the `JavaFrameAnchor` instance inside the thread, and then guard any accesses to it. But, that seems like a much more invasive change, so I'll hold off on that and focus this PR on fixing the issue.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21742#issuecomment-2489692928

From liach at openjdk.org  Wed Nov 20 23:03:43 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Nov 2024 23:03:43 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v4]
In-Reply-To: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
Message-ID: <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>

> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
> 
> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with four additional commits since the last revision:

 - typo
 - More cleanup
 - Remove a few confusions around bad modeling, some missing exceptions, also the labelless info models
 - Non-int constant values

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21625/files
  - new: https://git.openjdk.org/jdk/pull/21625/files/4a92d724..2dab7a2f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21625&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21625&range=02-03

  Stats: 1029 lines in 36 files changed: 380 ins; 355 del; 294 mod
  Patch: https://git.openjdk.org/jdk/pull/21625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21625/head:pull/21625

PR: https://git.openjdk.org/jdk/pull/21625

From liach at openjdk.org  Wed Nov 20 23:03:44 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Nov 2024 23:03:44 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v3]
In-Reply-To: <a-AwMSzRkwTtZKSs8JspUoj5jfVH2OzgZXTE2VP22Z0=.6c43801d-d04e-4a1f-8cf8-c0ad6b1f08a0@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <U6e2Ri8Y4Ph7v6XB30ZG_P1ekP3-b36ad5VT8D6S9Vc=.3a80204a-4ca8-4be9-aa86-d73a0bd9e813@github.com>
 <a-AwMSzRkwTtZKSs8JspUoj5jfVH2OzgZXTE2VP22Z0=.6c43801d-d04e-4a1f-8cf8-c0ad6b1f08a0@github.com>
Message-ID: <gGSnUAsWXfFJ7MInC-oCt_9J9E_7ZWva-vjk-_f9BCc=.4de4fe31-6499-46ae-b810-158f000a0d36@github.com>

On Tue, 19 Nov 2024 09:40:25 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Further facelift
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>>  - Merge branch 'master' of https://github.com/openjdk/jdk into docs/cf-instruction
>>  - Typos, long lines
>>  - Labels
>>  - Wip instr
>
> src/java.base/share/classes/java/lang/classfile/instruction/CharacterRange.java line 62:
> 
>> 60:  * <p>
>> 61:  * Physically, a character range has the same structure; it is modeled by a
>> 62:  * {@link CharacterRangeInfo}.
> 
> I'm not sure how to explain "Physically" and "it is modeled by".
> If "Physically" means specific byte serialization, then it is an entry in a CRT attribute with BCIs instead of labels.
> 
> "it is modeled by a CharacterRangeInfo" seems to me very confusing as this class (CharacterRange) is the primary model class. 
> 
> Maybe we should explain the duplicity of some classfile structures accessible as attributes internal raw structures (CharacterRangeInfo) versus preferred primary models as labeled pseudo instructions (CharacterRange).

Done. I have simplified the record model and added dedicated info about CRI being independent from Code so it's used in the attribute. Same for LineNumber etc.

> src/java.base/share/classes/java/lang/classfile/instruction/ConstantInstruction.java line 58:
> 
>> 56:  * <p>
>> 57:  * Physically, a constant-load instruction is polymorphic; nested interfaces in
>> 58:  * this interface model different constant instructions as records.
> 
> I'm not sure what the sentence "nested interfaces in this interface model different constant instructions as records" gives to users and on the other side what obligation does it mean from the JCK perspective?

Removed this confusing and meaningless sentence.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1851092390
PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1851092682

From liach at openjdk.org  Wed Nov 20 23:07:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Wed, 20 Nov 2024 23:07:15 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v4]
In-Reply-To: <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
Message-ID: <S7BX-EyivcUSmVaatW05Z3KSm98IOLSbD_SaLXOBlAU=.dd6c0bb4-82a4-4fce-8b34-b943661a8ce3@github.com>

On Wed, 20 Nov 2024 23:03:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - typo
>  - More cleanup
>  - Remove a few confusions around bad modeling, some missing exceptions, also the labelless info models
>  - Non-int constant values

I used the term "record" because they are something that may be pattern-matchable in the future; they are plain data objects. Similar representation is used in data model section of the java.lang.classfile package-level documentation.

Pushed another iteration (also updated CR) that solved some of the issues, including the constant format problems. I still think it is meaningful to move the huge data model from root package doc to individual model classes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21625#issuecomment-2489710019

From bpb at openjdk.org  Wed Nov 20 23:12:43 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Wed, 20 Nov 2024 23:12:43 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
Message-ID: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>

Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

-------------

Commit messages:
 - 8344659: Some uses of GetPropertyAction were not removed from java.io and java.nio

Changes: https://git.openjdk.org/jdk/pull/22285/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22285&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344659
  Stats: 25 lines in 9 files changed: 0 ins; 9 del; 16 mod
  Patch: https://git.openjdk.org/jdk/pull/22285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22285/head:pull/22285

PR: https://git.openjdk.org/jdk/pull/22285

From lancea at openjdk.org  Wed Nov 20 23:17:13 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Wed, 20 Nov 2024 23:17:13 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <pGSQzaZ9_0tOTIWT96ZNwZ55EGxFWW4zx908IkLHStw=.65470cad-ec64-4aca-af7c-67819e0324ff@github.com>

On Wed, 20 Nov 2024 22:36:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

LGTM

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2449890758

From naoto at openjdk.org  Wed Nov 20 23:37:16 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Wed, 20 Nov 2024 23:37:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <lPPC__3jZaSHsAG5ly8ulPC-vTpDMmi9ntFUjrvvH6I=.cab9c44c-d2a2-480b-ba60-2c18263379b0@github.com>

On Wed, 20 Nov 2024 22:36:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

Changes in `java.io.Console` and `sun.nio.cs.GB18030` look good.

src/java.base/share/classes/sun/nio/fs/Util.java line 40:

> 38: 
> 39:     private static final Charset jnuEncoding = Charset.forName(
> 40:         System.getProperty("sun.jnu.encoding"));

`StaticProperty.jnuEncoding()` can be used

-------------

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2449920128
PR Review Comment: https://git.openjdk.org/jdk/pull/22285#discussion_r1851119973

From ascarpino at openjdk.org  Thu Nov 21 00:38:22 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 21 Nov 2024 00:38:22 GMT
Subject: RFR: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules
In-Reply-To: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
References: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
Message-ID: <4XZLPmkW6MImIxrQYOkNQ0fepMN-BEoqaHFete3Jkqw=.5fb0fd56-78f7-4ca7-af1a-f110070b3808@github.com>

On Tue, 19 Nov 2024 20:43:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Now that JEP 486 has been integrated, `java.security.jgss` and `jdk.security.jgss` module dependencies on `System.getSecurityManager` and `AccessController.doPrivileged*` can be removed.
> 
> There is an undocumented property named "sun.security.krb5.autodeducerealm" that can probably be removed as it only affected behavior when an SM was enabled; however I have left the code that reads the property as-is (see sun/security/krb5/Realm.java) and have opened a separate issue to determine if it can be safely removed.

The changes look good.

-------------

Marked as reviewed by ascarpino (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22256#pullrequestreview-2449989796

From psandoz at openjdk.org  Thu Nov 21 00:42:27 2024
From: psandoz at openjdk.org (Paul Sandoz)
Date: Thu, 21 Nov 2024 00:42:27 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <OeWsPce9kf9hCaJNQUxrnkzujwX9a26psTDIL0ftEuw=.16292781-930b-43e2-9f14-effe372768ab@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

To make it easier to review this large change i recommend that the aarch64 changes be separated into a dependent PR.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2489828972

From jpai at openjdk.org  Thu Nov 21 01:00:25 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 01:00:25 GMT
Subject: RFR: 8344524: Remove SecurityManager related code from jdk.jlink
 module
In-Reply-To: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
References: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
Message-ID: <4iIBlfs-1OgjEAq47ui1qLoyCyRbNHREdshsjTq-nP0=.d3ff6afe-19c7-475d-87bc-f2f49d95554a@github.com>

On Wed, 20 Nov 2024 09:38:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which removes SecurityManager usages from `jdk.jlink` module? This addresses https://bugs.openjdk.org/browse/JDK-8344524.
> 
> The internal class `jdk.tools.jlink.internal.JlinkPermission` too has been removed as part of this change.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

Thank you all for the reviews.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22268#issuecomment-2489844310

From jpai at openjdk.org  Thu Nov 21 01:00:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 01:00:26 GMT
Subject: Integrated: 8344524: Remove SecurityManager related code from
 jdk.jlink module
In-Reply-To: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
References: <joXC2HEa981HaQw5hHH4_dViMpB910cMqGRcse64NTk=.59cecc12-af9a-4a44-bb7d-24b93e3910ab@github.com>
Message-ID: <JBbLiQSDDbKD_-_oo2upTtAn2R_vjziyfEF0ijisy5g=.fbda6c09-cf95-4aa2-a790-197d894ef6f9@github.com>

On Wed, 20 Nov 2024 09:38:05 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Can I please get a review for this change which removes SecurityManager usages from `jdk.jlink` module? This addresses https://bugs.openjdk.org/browse/JDK-8344524.
> 
> The internal class `jdk.tools.jlink.internal.JlinkPermission` too has been removed as part of this change.
> 
> No new tests have been added and existing tier1, tier2 and tier3 tests continue to pass with this change.

This pull request has now been integrated.

Changeset: 400eb9b1
Author:    Jaikiran Pai <jpai at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/400eb9b10ae0e53e58893b7ea5233d2d2e4046b6
Stats:     61 lines in 3 files changed: 0 ins; 60 del; 1 mod

8344524: Remove SecurityManager related code from jdk.jlink module

Reviewed-by: alanb, lancea, iris

-------------

PR: https://git.openjdk.org/jdk/pull/22268

From bpb at openjdk.org  Thu Nov 21 01:22:20 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 01:22:20 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio
In-Reply-To: <pGSQzaZ9_0tOTIWT96ZNwZ55EGxFWW4zx908IkLHStw=.65470cad-ec64-4aca-af7c-67819e0324ff@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <pGSQzaZ9_0tOTIWT96ZNwZ55EGxFWW4zx908IkLHStw=.65470cad-ec64-4aca-af7c-67819e0324ff@github.com>
Message-ID: <Mvi9FGKhkFnDSb_YS1asaEdf2lZ9DFs3MQu__2azenU=.12a84872-d47c-4f6a-b060-9a32ea082376@github.com>

On Wed, 20 Nov 2024 23:14:30 GMT, Lance Andersen <lancea at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> LGTM

@LanceAndersen , @naotoj Thanks for the reviews. I'll fiix Util.java and hold off integrating until tomorrow.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22285#issuecomment-2489870120

From bpb at openjdk.org  Thu Nov 21 01:45:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 01:45:56 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:

  8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22285/files
  - new: https://git.openjdk.org/jdk/pull/22285/files/cbd5232b..791663e3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22285&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22285&range=00-01

  Stats: 2 lines in 1 file changed: 1 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22285.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22285/head:pull/22285

PR: https://git.openjdk.org/jdk/pull/22285

From bpb at openjdk.org  Thu Nov 21 01:45:56 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 01:45:56 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <lPPC__3jZaSHsAG5ly8ulPC-vTpDMmi9ntFUjrvvH6I=.cab9c44c-d2a2-480b-ba60-2c18263379b0@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <lPPC__3jZaSHsAG5ly8ulPC-vTpDMmi9ntFUjrvvH6I=.cab9c44c-d2a2-480b-ba60-2c18263379b0@github.com>
Message-ID: <4TyPpNOMTozlNQWOJJgEjN3lXot4z50TkcAtFcCf-DI=.1334e598-e844-460b-b375-ae9d732cced4@github.com>

On Wed, 20 Nov 2024 23:34:22 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()
>
> src/java.base/share/classes/sun/nio/fs/Util.java line 40:
> 
>> 38: 
>> 39:     private static final Charset jnuEncoding = Charset.forName(
>> 40:         System.getProperty("sun.jnu.encoding"));
> 
> `StaticProperty.jnuEncoding()` can be used

Fixed in commit 791663e.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22285#discussion_r1851201235

From haosun at openjdk.org  Thu Nov 21 02:44:22 2024
From: haosun at openjdk.org (Hao Sun)
Date: Thu, 21 Nov 2024 02:44:22 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <c02yPuK_WOM8ZheMpEUTkhvPxcbI3T-nRJ3si6BpLdQ=.10de7e87-19d9-44e2-8afe-b5dee9e78fc5@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

Hi. Better to update the copyright year to 2024 for the following modified files:


src/hotspot/share/adlc/output_h.cpp
src/hotspot/share/opto/connode.cpp
src/hotspot/share/opto/connode.hpp
src/hotspot/share/opto/constantTable.cpp
src/hotspot/share/opto/divnode.cpp
src/hotspot/share/opto/divnode.hpp
src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java
test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2489949430

From cjplummer at openjdk.org  Thu Nov 21 02:47:14 2024
From: cjplummer at openjdk.org (Chris Plummer)
Date: Thu, 21 Nov 2024 02:47:14 GMT
Subject: RFR: 8344646: The libjsig deprecation warning should go to stderr
 not stdout
In-Reply-To: <r4C6D0qAUwFsILFtI6rMOEq4uqgpgUjoAUoxVhKO76I=.20a4dd98-931d-4ecc-b90e-4d1a117afab1@github.com>
References: <r4C6D0qAUwFsILFtI6rMOEq4uqgpgUjoAUoxVhKO76I=.20a4dd98-931d-4ecc-b90e-4d1a117afab1@github.com>
Message-ID: <6IYCTF3jG7Dg0uSDXDxo7aRt6voKIiW1KDdgYgFQd08=.69f5910e-eeac-4cef-b6e0-1d783981b9a0@github.com>

On Wed, 20 Nov 2024 21:18:01 GMT, David Holmes <dholmes at openjdk.org> wrote:

> In JDK 16 we deprecated the old signal and sigset signal-chaining interfaces under [JDK-8257572](https://bugs.openjdk.org/browse/JDK-8257572). The deprecation warning was written to stdout but all other warnings go to stderr. Having the warning be on stdout causes interference with application output so we change it to stderr.
> 
> Testing
>  - examined signal test output (see JBS issue)
>  - tiers 1-3 sanity
> 
> Thanks

Marked as reviewed by cjplummer (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22283#pullrequestreview-2450107678

From duke at openjdk.org  Thu Nov 21 03:01:18 2024
From: duke at openjdk.org (monk)
Date: Thu, 21 Nov 2024 03:01:18 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <GQc-KfnD4fOl-uvjkvpXX91667JVPbNQNuwHmF4Jqss=.e0952e63-82ab-4a32-9868-5eb18bab8e1e@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <GQc-KfnD4fOl-uvjkvpXX91667JVPbNQNuwHmF4Jqss=.e0952e63-82ab-4a32-9868-5eb18bab8e1e@github.com>
Message-ID: <IhbO3McWn5psNv5GWfJK3q_J82lF5pmXL4C1Rj4gvek=.66c8e5bd-893b-477e-b3aa-5a10c5167a41@github.com>

On Tue, 19 Nov 2024 14:16:47 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
>> 
>> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
>> 
>> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
>> 
>> Testing: tier 1-5 green
>
> I tested with the particular test case given in the original test, which is not a strict benchmark; still with the virtual method switched to MH accessor, average time is about 1/10 of before.

Hi @liach,I am the original bug reporter,happy to see the patch.Because of the bug report web can not submit new comment with some web error,I want to tell you new imformation here.
I run some new test and get new result:
1.I confirm Object.hashcode has the same issue.
2.toString() also has a slight decrease in performance,but not as exaggerated as the native methods, about -20%,I don't should is be expected.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2489963193

From rriggs at openjdk.org  Thu Nov 21 03:04:16 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Nov 2024 03:04:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <KyPlVx9JH3V0jTJotK1VB555adIiFYHtzzwNKW8-pIs=.f53af89c-6fe1-4366-8ac6-d352ab2e070d@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

lgtm

-------------

Marked as reviewed by rriggs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2450121759

From liach at openjdk.org  Thu Nov 21 03:31:15 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Nov 2024 03:31:15 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
Message-ID: <iM5eRAb6zYxQV72lVNSiEUgdVBZ_boeeJd3YKrtFjAI=.0e373b0b-6905-4483-b089-80ea66b179e4@github.com>

On Fri, 15 Nov 2024 22:17:10 GMT, Chen Liang <liach at openjdk.org> wrote:

> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
> 
> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
> 
> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
> 
> Testing: tier 1-5 green

Thanks for the test on `Object.hashCode` and `Thread.currentThread` to confirm my guess.

For the `toString` test:
1. I don't think I will fix it as part of this PR; we will create a new issue for it once we confirm it.
2. To reproduce, I think first we will test with JDK 17 and 21. Core reflection reimplementation happened in JDK 18.
3. For reliable results, I suggest using the JMH tool https://github.com/openjdk/jmh; there is a gradle plugin for it https://github.com/melix/jmh-gradle-plugin and it has a gradle project example https://github.com/melix/jmh-gradle-plugin/tree/master/samples/simple-java/groovy-dsl, as your raw "setup" and system-time based checks have a lot of disturbance.

> Because of the bug report web can not submit new comment with some web error

I am sorry, but OpenJDK infrastructure currently has some known issues; even we are automatically logged out. Thank you for coming to the github PR for comments, @moooonk!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2489991784

From liach at openjdk.org  Thu Nov 21 03:34:18 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Nov 2024 03:34:18 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <hfGbYuJnUAScWOTFMFFyiuB3alAP5uMBEa6aQZNoywo=.84cebc75-a8fd-4116-aea9-6fc6815db1a1@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <8-11iSlDurp5uruEU9oyF0302kSMtS5cU5lf3gtiiqQ=.28dc19b7-06b9-4487-a8f1-6bb1d91c1679@github.com>
 <2uZCbedHs4fAKMGE8MGrZeRBxTM6sdjQsiPOX5z0zak=.eae9d186-8bcb-4aab-9300-24947f79b7fa@github.com>
 <ipZHgeOPRp9nFUpi0j1ozWSaWZmGlhYQwxQ5ex0KJ58=.bd830307-aa28-4087-9cb9-b2ba26094f02@github.com>
 <kWWjp7-JMpy0O7vWMKUnSLmD96cZMs-_kOq9IVQtP7Q=.997b2b24-014c-4d23-96ad-bac4a1149246@github.com>
 <hfGbYuJnUAScWOTFMFFyiuB3alAP5uMBEa6aQZNoywo=.84cebc75-a8fd-4116-aea9-6fc6815db1a1@github.com>
Message-ID: <eMXmMa-VUVJq9Ao_FZ144_pipBPbNsfJucxUflG5Y_A=.c352b4d8-6ce3-4934-91b3-baf2f5b097a5@github.com>

On Tue, 19 Nov 2024 17:15:22 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Okay, in that case it's probably fine - I assume there's also no easy way to ensure in a test that all signature polymorphic methods are covered by these checks?
>
> These checks are 1-1 to the JVMS 2.9.3/JLS 15.12.3, where definitions of signature polymorphic methods reside.
> 
> Actually, since you've asked, I checked the usage of `PolymorphicSignature` - it's not used by javac at all! The only usages I can find is in JVMCI tests. And I don't find any test that verify the set of all `PolymorphicSignature` annotated methods is the set of all signature polymorphic methods. (A similar test exists for `CallerSensitive`).

Consulted hotspot and javac engineers offline and confirmed they aren't relying on this particular annotation. Since this annotation was added back when langtools (javac) and jdk were separate repos, it's now hard to track how this annotation was used originally; it could have been used by javac but was abandoned later. For now, `@PolymorphicSignature` is a decorative annotation used by some tests.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22169#discussion_r1851265537

From iris at openjdk.org  Thu Nov 21 04:29:16 2024
From: iris at openjdk.org (Iris Clark)
Date: Thu, 21 Nov 2024 04:29:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <Pk4loyifwdPDW98BXGdaGmb0e0h6La5JAAhnuwMIcBY=.3b4be0de-334a-41ab-a427-b6f0a496a5d6@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Marked as reviewed by iris (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2450202981

From duke at openjdk.org  Thu Nov 21 04:32:50 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Thu, 21 Nov 2024 04:32:50 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v5]
In-Reply-To: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
Message-ID: <VsLU2J92-1_RSmWIRDnAoqA2vOzM5xIT_hA1pxGXuNc=.0cff32d8-a082-404a-a853-c6e252ca4c8f@github.com>

> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 437". This ensures that the English message "No Instance(s) Available." is output on localized windows platforms.
> 
> I have referred to the following for how to use chcp:
> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
> 
> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
> 
> Thanks

Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:

 - Fix conflict
 - Fix about size of cmdline
 - Fix indent
 - Merge branch 'fix_Win8301247Test_bug' of https://github.com/kurashige23/jdk into fix_Win8301247Test_bug
 - Merge branch 'openjdk:master' into fix_Win8301247Test_bug
 - Chenge code page from 65001 to 437
 - Fix how to execute chcp command
 - Change setWinEnableUTF8 to setWinRunWithEnglishOutput
 - Suppress the output of chcp command
 - Fix comment
 - ... and 5 more: https://git.openjdk.org/jdk/compare/a01aa220...f013d9fb

-------------

Changes: https://git.openjdk.org/jdk/pull/22142/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22142&range=04
  Stats: 36 lines in 2 files changed: 27 ins; 1 del; 8 mod
  Patch: https://git.openjdk.org/jdk/pull/22142.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22142/head:pull/22142

PR: https://git.openjdk.org/jdk/pull/22142

From duke at openjdk.org  Thu Nov 21 04:41:16 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Thu, 21 Nov 2024 04:41:16 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v5]
In-Reply-To: <VsLU2J92-1_RSmWIRDnAoqA2vOzM5xIT_hA1pxGXuNc=.0cff32d8-a082-404a-a853-c6e252ca4c8f@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <VsLU2J92-1_RSmWIRDnAoqA2vOzM5xIT_hA1pxGXuNc=.0cff32d8-a082-404a-a853-c6e252ca4c8f@github.com>
Message-ID: <kPOww39B5SG8goynFG94ms8rrBH07HKKlSWjTdkSP7k=.6e2b0934-f7d7-4eec-85bf-72087e60d045@github.com>

On Thu, 21 Nov 2024 04:32:50 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

>> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 437". This ensures that the English message "No Instance(s) Available." is output on localized windows platforms.
>> 
>> I have referred to the following for how to use chcp:
>> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
>> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
>> 
>> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
>> 
>> Thanks
>
> Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix conflict
>  - Fix about size of cmdline
>  - Fix indent
>  - Merge branch 'fix_Win8301247Test_bug' of https://github.com/kurashige23/jdk into fix_Win8301247Test_bug
>  - Merge branch 'openjdk:master' into fix_Win8301247Test_bug
>  - Chenge code page from 65001 to 437
>  - Fix how to execute chcp command
>  - Change setWinEnableUTF8 to setWinRunWithEnglishOutput
>  - Suppress the output of chcp command
>  - Fix comment
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a01aa220...f013d9fb

Thank you for your review.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22142#issuecomment-2490063433

From dholmes at openjdk.org  Thu Nov 21 04:46:16 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Nov 2024 04:46:16 GMT
Subject: RFR: 8344540: Remove superseded wildcard description from java
 manpage [v2]
In-Reply-To: <3UvLupHPQtWPOuWUuEOjasx4aZrkqT1SswqQihJY8KM=.78f14adb-a573-47ec-9da1-90f7feff6231@github.com>
References: <IX-jo6P0nLWkVZJrUcDwyuo3T8VVmRYoG0C-hkM439k=.c6e06daa-7aed-4c56-a92e-43642147e9b6@github.com>
 <3UvLupHPQtWPOuWUuEOjasx4aZrkqT1SswqQihJY8KM=.78f14adb-a573-47ec-9da1-90f7feff6231@github.com>
Message-ID: <XmCUe6Eqiw2Bx-Vr8qViM3SsrcgUiPLU7WjOeG-35pc=.1c4946b0-845d-4787-aa54-3cd25ac642bc@github.com>

On Wed, 20 Nov 2024 11:20:38 GMT, Christian Stein <cstein at openjdk.org> wrote:

>> Please review this follow-up PR to improve `java`'s manpage section about wildcards in argument files: the confusing sentence is now removed.
>> 
>> This is a cleanup of commit https://github.com/openjdk/jdk/commit/5cb0d438231383d491b2fcca455d09af7f2ee016
>
> Christian Stein has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Update section as suggested

Can I also suggest some grammatical tweaks to the arg file section:

    The launcher doesn't expand wildcards that are present within an argument
    file. That means, an asterisk  `*` is passed on as-is to the starting VM.

There is an extra space after "asterisk". No comma needed after "means" and the asterisk character should be in parentheses e.g.

    file. That means an asterisk (`*`) is passed on as-is to the starting VM.



    For example `*.java` stays `*.java` and is not expanded to `Foo.java`,
    `Bar.java`, etc. like on some command line shell.

Suggestion

    For example `*.java` stays `*.java` and is not expanded to `Foo.java
    Bar.java ...`,  as would happen with some command line shells.

src/java.base/share/man/java.md line 283:

> 281: message. `@`-files are supported as they are specified in the command line.
> 282: Any wildcard literal `*` in the `JDK_JAVA_OPTIONS` environment variable
> 283: content isn't expanded and is passed as-is to the java launcher. In order to

Suggestion:

content isn't expanded and is passed as-is to the starting VM. In order to

The env var is not passed to the launcher but used by the launcher to set the args for the VM. Using "starting VM" is consistent with what was changed in the arg file section.

-------------

Changes requested by dholmes (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22236#pullrequestreview-2450201052
PR Review Comment: https://git.openjdk.org/jdk/pull/22236#discussion_r1851307007

From duke at openjdk.org  Thu Nov 21 04:48:16 2024
From: duke at openjdk.org (Taizo Kurashige)
Date: Thu, 21 Nov 2024 04:48:16 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v5]
In-Reply-To: <VsLU2J92-1_RSmWIRDnAoqA2vOzM5xIT_hA1pxGXuNc=.0cff32d8-a082-404a-a853-c6e252ca4c8f@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <VsLU2J92-1_RSmWIRDnAoqA2vOzM5xIT_hA1pxGXuNc=.0cff32d8-a082-404a-a853-c6e252ca4c8f@github.com>
Message-ID: <mY2qRbxCc-J_VFhV87zBYLDHxQIzaJ8J5_u1GIRbOh8=.4a59b0c5-84bd-4dd9-bf4a-94ae72d394d2@github.com>

On Thu, 21 Nov 2024 04:32:50 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

>> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 437". This ensures that the English message "No Instance(s) Available." is output on localized windows platforms.
>> 
>> I have referred to the following for how to use chcp:
>> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
>> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
>> 
>> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
>> 
>> Thanks
>
> Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix conflict
>  - Fix about size of cmdline
>  - Fix indent
>  - Merge branch 'fix_Win8301247Test_bug' of https://github.com/kurashige23/jdk into fix_Win8301247Test_bug
>  - Merge branch 'openjdk:master' into fix_Win8301247Test_bug
>  - Chenge code page from 65001 to 437
>  - Fix how to execute chcp command
>  - Change setWinEnableUTF8 to setWinRunWithEnglishOutput
>  - Suppress the output of chcp command
>  - Fix comment
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a01aa220...f013d9fb

Sorry, I fixed conflict. Please review again.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22142#issuecomment-2490069575

From dholmes at openjdk.org  Thu Nov 21 05:08:23 2024
From: dholmes at openjdk.org (David Holmes)
Date: Thu, 21 Nov 2024 05:08:23 GMT
Subject: RFR: 8344646: The libjsig deprecation warning should go to stderr
 not stdout
In-Reply-To: <6IYCTF3jG7Dg0uSDXDxo7aRt6voKIiW1KDdgYgFQd08=.69f5910e-eeac-4cef-b6e0-1d783981b9a0@github.com>
References: <r4C6D0qAUwFsILFtI6rMOEq4uqgpgUjoAUoxVhKO76I=.20a4dd98-931d-4ecc-b90e-4d1a117afab1@github.com>
 <6IYCTF3jG7Dg0uSDXDxo7aRt6voKIiW1KDdgYgFQd08=.69f5910e-eeac-4cef-b6e0-1d783981b9a0@github.com>
Message-ID: <oXLvKlivu7TdlYI0lrVYyP0lFIhcB5rGmlIJyd_eDsc=.fe72744f-9c4a-4e71-a14f-669110273014@github.com>

On Thu, 21 Nov 2024 02:45:06 GMT, Chris Plummer <cjplummer at openjdk.org> wrote:

>> In JDK 16 we deprecated the old signal and sigset signal-chaining interfaces under [JDK-8257572](https://bugs.openjdk.org/browse/JDK-8257572). The deprecation warning was written to stdout but all other warnings go to stderr. Having the warning be on stdout causes interference with application output so we change it to stderr.
>> 
>> Testing
>>  - examined signal test output (see JBS issue)
>>  - tiers 1-3 sanity
>> 
>> Thanks
>
> Marked as reviewed by cjplummer (Reviewer).

Thanks for the review @plummercj !

I will wait the ~24 hours then integrate.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22283#issuecomment-2490088583

From jpai at openjdk.org  Thu Nov 21 05:16:54 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 05:16:54 GMT
Subject: RFR: 8341184: Clean up the interaction between the launcher native
 code and the LauncherHelper [v8]
In-Reply-To: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
References: <gHfdyCGu8wddx_pAvdVwBAJG8SqzbCwuuiVNZ0dZ7JE=.fa653644-3ed8-4f88-90ae-28bb445db699@github.com>
Message-ID: <zLz7pGdu6f6hMhmi4wW5MDIXwmq80sjj7MSF2-DfFCA=.87670789-feb3-442a-ab0a-b3c501dac4e1@github.com>

> Can I please get a review of this change, which simplifies the interaction between the `java` launcher's native code with the `sun.launcher.LauncherHelper`? 
> 
> As noted in https://bugs.openjdk.org/browse/JDK-8341184, this proposed change reduces the back and forth between the launcher's native code and the `LauncherHelper` class. This also removes the additional reflective lookups from the native code after the main class and main method have been determined by the `LauncherHelper`. 
> 
> Although this is a clean up of the code, the changes in the `LauncherHelper` to return a `MainEntry` have been done in a way to facilitate additional upcoming changes in this area, which propose to get rid of the JAR manifest parsing from the launcher's native code.
> 
> No new tests have been added. Existing tests in tier1, tier2 and tier3 continue to pass.

Jaikiran Pai has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains eight additional commits since the last revision:

 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - merge latest from master branch
 - 8341184: Clean up the interaction between the launcher native code and the LauncherHelper

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21256/files
  - new: https://git.openjdk.org/jdk/pull/21256/files/042b76ca..34b35911

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=07
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21256&range=06-07

  Stats: 12025 lines in 474 files changed: 5036 ins; 4937 del; 2052 mod
  Patch: https://git.openjdk.org/jdk/pull/21256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21256/head:pull/21256

PR: https://git.openjdk.org/jdk/pull/21256

From jpai at openjdk.org  Thu Nov 21 05:27:16 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 05:27:16 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
Message-ID: <yLxZaNr1P2ha8_nCCRroiZBqtU6iS5ALjyKVVU2NyYQ=.d7228d8b-7476-4cac-9d42-e437d57e5c84@github.com>

On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple patch which adds a new external system property `jdk.patched` when the runtime has been patched with the `--patch-module` switch. This is useful for two reasons: 1) it allows one to determine at run-time whether or not `--patch-module` has been used (by querying the said property) 2) allows tools, such as `jlink` doing the same without needing to expose internal properties the JVM sets on initialization.
> 
> Testing:
> 
> - [x] GHA (includes new test)
> - [x] New jtreg test 
> 
> Thoughts?

src/hotspot/share/runtime/arguments.cpp line 2272:

> 2270:       if (res == JNI_OK) {
> 2271:         // Add jdk.patched system property when processing of args was OK
> 2272:         PropertyList_unique_add(&_system_properties, "jdk.patched", "true",

Hello Severin, in addition, should we explicitly set this system property to `false` (or remove the system property) when `--patch-module` isn't used? I think that would then prevent applications from passing `-Djdk.patched=true` when the runtime hasn't been patched. 
While at it, should there be additional guards to prevent applications from changing the value of this system property by doing `System.setProperty("jdk.patched")` at runtime?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22277#discussion_r1851376171

From jpai at openjdk.org  Thu Nov 21 05:52:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 05:52:24 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
Message-ID: <iexTQKHJnFUtjrDNirk5QkorUFMDvP0d_QqkUEUIfGk=.b385fbac-29b4-45f4-a2ab-0a2a4bc4a3c9@github.com>

On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple patch which adds a new external system property `jdk.patched` when the runtime has been patched with the `--patch-module` switch. This is useful for two reasons: 1) it allows one to determine at run-time whether or not `--patch-module` has been used (by querying the said property) 2) allows tools, such as `jlink` doing the same without needing to expose internal properties the JVM sets on initialization.
> 
> Testing:
> 
> - [x] GHA (includes new test)
> - [x] New jtreg test 
> 
> Thoughts?

Having now looked at https://github.com/openjdk/jdk/pull/22037/ which is what motivated this change, I now have a more basic question.

The `--patch-module` option is an option for the `java` command. The code changes in this current PR is proposing to set a system property if `java` was launched with `--patch-module=...`. The other PR is about image creation using `jlink` command. Looking at the other PR, it proposes to look for the presence of this system property to do some decisions during image creation. However, when that `jlink` command is invoked, it's a completely different process/runtime, so how would `--patch-module` for `java` setting a system property propagate to that image creation `jlink` process?

I am feeling that I have misunderstood what's being proposed here.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2490133685

From bchristi at openjdk.org  Thu Nov 21 05:58:22 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 21 Nov 2024 05:58:22 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
Message-ID: <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>

On Wed, 20 Nov 2024 09:19:39 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
>> 
>> I'll put performance data in a separate comment.
>> 
>> Additional testing:
>>  - [x] Original reproducer improves drastically
>>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>>  - [x] `java/lang/ref` tests in release 
>>  - [x] `all` tests in fastdebug
>
> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Check all elements are removable after random test

test/micro/org/openjdk/bench/java/lang/ref/CleanerGC.java line 45:

> 43: 
> 44:     // Deliberately a linked list to avoid exposing external parallelism to GC.
> 45:     Target prev;

Is `CleanerGC.prev` used?

test/micro/org/openjdk/bench/java/lang/ref/CleanerGC.java line 57:

> 55:     @Benchmark
> 56:     public void test() {
> 57:         System.gc();

How confident are we that most/all/(any?) `Target` objects are being collected?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1851391803
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1851402011

From aturbanov at openjdk.org  Thu Nov 21 06:50:18 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 21 Nov 2024 06:50:18 GMT
Subject: RFR: 8344587: Reduce number of "jdk.jpackage.internal" classes
 used from other packages
In-Reply-To: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
References: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
Message-ID: <ALTqZrMdfFZnbGJioa_56DARHo2-ynL-96meVn6-brk=.c9ce4f9b-3dca-4f0b-a91c-3dfa843b3c10@github.com>

On Tue, 19 Nov 2024 22:31:28 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Stop using internal AppImageFile, ApplicationLayout, and PackageFile classes in the tests. Replace them with stubs.
> 
> Stop referencing IOUtils class from XmlUtils and PathUtils classes.

test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java line 220:

> 218:         String appImage = getArgumentValue("--app-image");
> 219:         if (appImage != null) {
> 220:             String name =  AppImageFile.load(Path.of(appImage)).mainLauncherName();

Suggestion:

            String name = AppImageFile.load(Path.of(appImage)).mainLauncherName();

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22261#discussion_r1851452856

From aturbanov at openjdk.org  Thu Nov 21 06:52:19 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 21 Nov 2024 06:52:19 GMT
Subject: RFR: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules
In-Reply-To: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
References: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
Message-ID: <fn8SSbiw9rH3y-4y9ZPs3txugx2PilULGSMfFuVZmO8=.889837c1-c801-4b5e-bd9d-36205754e708@github.com>

On Tue, 19 Nov 2024 20:43:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Now that JEP 486 has been integrated, `java.security.jgss` and `jdk.security.jgss` module dependencies on `System.getSecurityManager` and `AccessController.doPrivileged*` can be removed.
> 
> There is an undocumented property named "sun.security.krb5.autodeducerealm" that can probably be removed as it only affected behavior when an SM was enabled; however I have left the code that reads the property as-is (see sun/security/krb5/Realm.java) and have opened a separate issue to determine if it can be safely removed.

src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 115:

> 113:                  }
> 114:                  Oid[] mechs = GSSLibStub.indicateMechs();
> 115:                  HashMap<String,String> map = new HashMap<>();

Suggestion:

                 HashMap<String, String> map = new HashMap<>();

src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java line 349:

> 347:                 DEBUG.println(">>> KDCCommunication: kdc=" + kdc
> 348:                         + " " + proto + ":"
> 349:                         +  port +  ", timeout="

Suggestion:

                        + port + ", timeout="

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22256#discussion_r1851454369
PR Review Comment: https://git.openjdk.org/jdk/pull/22256#discussion_r1851453729

From jpai at openjdk.org  Thu Nov 21 06:53:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 06:53:24 GMT
Subject: RFR: 8344235: Revisit SecurityManager usage in java.logging after
 JEP 486 integration
In-Reply-To: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
References: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
Message-ID: <5l77CiaoalA8-CC6S7olVjdqLQILNZ4F6-1KWgjQXTg=.77b08815-151e-4805-9e7e-a1b8605a01fa@github.com>

On Wed, 20 Nov 2024 19:39:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This PR remove usage of SecurityManager, doPrivileges, etc... from `java.logging` and `java.base/jdk.internal.logger`
> 
> Only notable hack - Logger.checkPermission() no longer checks permissions, but has been renamed into `ensureLogManagerInitialized()` in order to avoid disturbing the initialization sequence of Logger/LogManager.
> 
> I am not 100% sure this is still needed - but I remember we had some entanglement issues in the past that had been hard to solve, so it seemed prudent to keep the call:
> 
> 
>     if (manager == null) {
>         manager = LogManager.getLogManager();
>     }
> 
> 
> where `manager` is a private volatile field in Logger.

Hello Daniel, the changes look good to me. However, these changes appear to include both JEP 486 related updates as well as the JEP 491 (the reverting of `ReentrantLock` usage in favour of `synchronized`). Doing this clean up together I think is fine. However, I think we should update the issue title to also include JEP 491 in addition to JEP 486.

-------------

PR Review: https://git.openjdk.org/jdk/pull/22281#pullrequestreview-2450405988

From aturbanov at openjdk.org  Thu Nov 21 06:53:26 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 21 Nov 2024 06:53:26 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v5]
In-Reply-To: <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
Message-ID: <MGk0o98ETKQ4juQ6cdWNMvxvR0AGvuhqer8FtHVcKf8=.422d7edd-b310-4409-9920-af2fd922e9bc@github.com>

On Wed, 20 Nov 2024 22:43:44 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation fixes

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 133:

> 131:         isUserRootWritable = userRootDir.canWrite();
> 132:         String USER_NAME = System.getProperty("user.name");
> 133:         userLockFile = new File (userRootDir,".user.lock." + USER_NAME);

Suggestion:

        userLockFile = new File(userRootDir, ".user.lock." + USER_NAME);

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 177:

> 175:     private static void setupSystemRoot() {
> 176:         String systemPrefsDirName =
> 177:           System.getProperty("java.util.prefs.systemRoot","/etc/.java");

Suggestion:

          System.getProperty("java.util.prefs.systemRoot", "/etc/.java");

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 207:

> 205:         systemLockFile = new File(systemRootDir, ".system.lock");
> 206:         systemRootModFile =
> 207:                        new File (systemRootDir,".systemRootModFile");

Suggestion:

                       new File(systemRootDir, ".systemRootModFile");

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 577:

> 575:                 XmlSupport.importMap(fis, m);
> 576:             }
> 577:         } catch(Exception e) {

Suggestion:

        } catch (Exception e) {

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 580:

> 578:             if (e instanceof InvalidPreferencesFormatException) {
> 579:                 getLogger().warning("Invalid preferences format in "
> 580:                                             +  prefsFile.getPath());

Suggestion:

                                            + prefsFile.getPath());

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 617:

> 615:                 throw new BackingStoreException("Can't rename " +
> 616:                 tmpFile + " to " + prefsFile);
> 617:         } catch(BackingStoreException e) {

Suggestion:

        } catch (BackingStoreException e) {

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 619:

> 617:         } catch(BackingStoreException e) {
> 618:             throw e;
> 619:         } catch(Exception e) {

Suggestion:

        } catch (Exception e) {

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851455289
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851455506
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851455757
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851455947
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851456103
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851456204
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851456285

From jlu at openjdk.org  Thu Nov 21 06:53:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Nov 2024 06:53:58 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v4]
In-Reply-To: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
Message-ID: <xTxbdWdErCsY1XF0SBmcUb7t4iKeuyw6fVFHkEjQ49E=.ac5332aa-f18d-466a-ba74-7e21d8e552d8@github.com>

> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change.
> 
> APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
> Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html

Justin Lu has updated the pull request incrementally with one additional commit since the last revision:

  reflect review

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22192/files
  - new: https://git.openjdk.org/jdk/pull/22192/files/c8dd75cc..871d635a

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22192&range=03
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22192&range=02-03

  Stats: 4 lines in 1 file changed: 0 ins; 0 del; 4 mod
  Patch: https://git.openjdk.org/jdk/pull/22192.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22192/head:pull/22192

PR: https://git.openjdk.org/jdk/pull/22192

From jlu at openjdk.org  Thu Nov 21 06:53:58 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Nov 2024 06:53:58 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v3]
In-Reply-To: <sRqt5oxkg9xl7W2Pxwnz0CtKbqJpMNjZ8c996a84CBQ=.67c3ab45-f6c2-496a-95cd-be406ac0f194@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <vE7O7eohfvzyh6dyKqtUwNl2MgZutk8iz79kckxSttY=.762a5087-9176-4d8d-8bcc-a205d545034f@github.com>
 <sRqt5oxkg9xl7W2Pxwnz0CtKbqJpMNjZ8c996a84CBQ=.67c3ab45-f6c2-496a-95cd-be406ac0f194@github.com>
Message-ID: <Kx4d5jR9rCf_7XbBX1Gizp9V-NoC3E36FmEofEbm-rY=.3b202788-5fe3-448d-a535-f4f9948ef59a@github.com>

On Wed, 20 Nov 2024 18:20:04 GMT, Naoto Sato <naoto at openjdk.org> wrote:

>> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   address Naoto's comments
>
> src/java.base/share/classes/java/util/Locale.java line 1256:
> 
>> 1254: 
>> 1255:     /**
>> 1256:      * {@return an array of deployed locales}
> 
> Since "deployed" is the term from ServiceLoader, it might mean only referring to SPI impls, so how about simply "available"?

Both comments addressed. CSR will be updated once the JBS login issues get resolved :-).

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22192#discussion_r1851456088

From alanb at openjdk.org  Thu Nov 21 07:00:18 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Nov 2024 07:00:18 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v2]
In-Reply-To: <F0UOh57K-vnzYfmMdk-RxCCD-7WIkFWgRSmNU_ZKsVM=.2529c11c-1138-4b54-b973-0a93e37cbe34@github.com>
References: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
 <F0UOh57K-vnzYfmMdk-RxCCD-7WIkFWgRSmNU_ZKsVM=.2529c11c-1138-4b54-b973-0a93e37cbe34@github.com>
Message-ID: <FIu1QkosnnySnJnreB2GEyon1vhzUtWCAwtjbtra6IU=.76bdae8c-d2fc-4b53-b659-229b00b94ed7@github.com>

On Wed, 20 Nov 2024 21:03:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>> 
>> Refresh of PR#22168 Including review comments made there.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove latent permission and checkPermission.

I did another pass over this, looks okay.

-------------

Marked as reviewed by alanb (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22282#pullrequestreview-2450415549

From aturbanov at openjdk.org  Thu Nov 21 07:00:20 2024
From: aturbanov at openjdk.org (Andrey Turbanov)
Date: Thu, 21 Nov 2024 07:00:20 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v5]
In-Reply-To: <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
Message-ID: <fIT3506xziLfrfyDaKkyINN35sj6sqhvkWp6rMlyu_M=.ed69d95e-bfc7-462b-899a-a75c19e69ebe@github.com>

On Wed, 20 Nov 2024 22:43:44 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation fixes

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 208:

> 206:         systemRootModFile =
> 207:                        new File (systemRootDir,".systemRootModFile");
> 208:         if (!systemRootModFile.exists() && isSystemRootWritable)

let's add braces here too

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1851461711

From sundar at openjdk.org  Thu Nov 21 07:08:25 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 21 Nov 2024 07:08:25 GMT
Subject: RFR: 8337422: spelling error in jlink documentation
In-Reply-To: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
References: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
Message-ID: <j6szbNfYt-hUEjWOnXX7vMKxByhEneCtUSQA2kAEJ1s=.fddc342b-dd9b-4cc1-9d86-c39db4bfb086@github.com>

On Fri, 6 Sep 2024 06:26:47 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> fixed spelling to be consistent with the rest of the man page.

closed because of conflicts

-------------

PR Comment: https://git.openjdk.org/jdk/pull/20882#issuecomment-2490229186

From sundar at openjdk.org  Thu Nov 21 07:08:25 2024
From: sundar at openjdk.org (Athijegannathan Sundararajan)
Date: Thu, 21 Nov 2024 07:08:25 GMT
Subject: Withdrawn: 8337422: spelling error in jlink documentation
In-Reply-To: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
References: <PexLl073eYb_KujPLquVFajhrBfuYJ6ZzE3pnDUQP_4=.07089243-5ccf-4bdc-802c-aa59f1bcfb64@github.com>
Message-ID: <vTcW7ztDucrUByJ67Q_j0y9Fa4_mu4jfDW7ddiiTrYY=.076c8ef7-c9ad-40d7-818f-c39e532620e7@github.com>

On Fri, 6 Sep 2024 06:26:47 GMT, Athijegannathan Sundararajan <sundar at openjdk.org> wrote:

> fixed spelling to be consistent with the rest of the man page.

This pull request has been closed without being integrated.

-------------

PR: https://git.openjdk.org/jdk/pull/20882

From shade at openjdk.org  Thu Nov 21 07:13:18 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Nov 2024 07:13:18 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
 <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>
Message-ID: <DJyCJZwSTn5kYnP3BrOsYvklgxa82tKD1IGgLw5IWmo=.b50e7d38-4829-49fa-bbe4-bbb3327efbae@github.com>

On Thu, 21 Nov 2024 05:42:09 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Aleksey Shipilev has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Check all elements are removable after random test
>
> test/micro/org/openjdk/bench/java/lang/ref/CleanerGC.java line 45:
> 
>> 43: 
>> 44:     // Deliberately a linked list to avoid exposing external parallelism to GC.
>> 45:     Target prev;
> 
> Is `CleanerGC.prev` used?

Yes. It maintains the root of a reachable linked list of `Target`-s.

> test/micro/org/openjdk/bench/java/lang/ref/CleanerGC.java line 57:
> 
>> 55:     @Benchmark
>> 56:     public void test() {
>> 57:         System.gc();
> 
> How confident are we that most/all/(any?) `Target` objects are being collected?

The point of this test is not collecting `Target`-s -- they are all reachable. The point of this test is to make GC walk the large linked list of `PhantomCleanable`-s during GC, which replicates what we see in prod-like scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1851475659
PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1851474396

From alanb at openjdk.org  Thu Nov 21 07:49:14 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Nov 2024 07:49:14 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
Message-ID: <hDKzS_beMAldQjUlB_KZ6Hpn5sFJJPIclEqbiFSLss0=.633a7e6c-a2c5-460b-ac73-f2e6378ec168@github.com>

On Wed, 20 Nov 2024 14:26:27 GMT, Severin Gehwolf <sgehwolf at openjdk.org> wrote:

> Please review this simple patch which adds a new external system property `jdk.patched` when the runtime has been patched with the `--patch-module` switch. This is useful for two reasons: 1) it allows one to determine at run-time whether or not `--patch-module` has been used (by querying the said property) 2) allows tools, such as `jlink` doing the same without needing to expose internal properties the JVM sets on initialization.
> 
> Testing:
> 
> - [x] GHA (includes new test)
> - [x] New jtreg test 
> 
> Thoughts?

> Having now looked at #22037 which is what motivated this change, I now have a more basic question.
> 
> The `--patch-module` option is an option for the `java` command. The code changes in this current PR is proposing to set a system property if `java` was launched with `--patch-module=...`. The other PR is about image creation using `jlink` command. Looking at the other PR, it proposes to look for the presence of this system property to do some decisions during image creation. However, when that `jlink` command is invoked, it's a completely different process/runtime, so how would `--patch-module` for `java` setting a system property propagate to that image creation `jlink` process?
> 
> I am feeling that I have misunderstood what's being proposed here.

This is the corner case of jlink being run with -J--patch-module or "in-process" with ToolProvider. I see Severin recently added to the link of restrictions in JEP 493 but I'm not sure that it rises to the level that it should be mentioned in the JEP.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2490292591

From bkilambi at openjdk.org  Thu Nov 21 08:32:23 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 21 Nov 2024 08:32:23 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <c02yPuK_WOM8ZheMpEUTkhvPxcbI3T-nRJ3si6BpLdQ=.10de7e87-19d9-44e2-8afe-b5dee9e78fc5@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <c02yPuK_WOM8ZheMpEUTkhvPxcbI3T-nRJ3si6BpLdQ=.10de7e87-19d9-44e2-8afe-b5dee9e78fc5@github.com>
Message-ID: <5JP6jPC2kBjgbzZa1397E5ROgo5xY9QpusWzUDMN6jg=.c4735599-b1d0-4a02-a5e6-d5f7eeefce8e@github.com>

On Thu, 21 Nov 2024 02:41:47 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 6. Auto-vectorization of newly supported scalar operations.
>> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
>> 9. Functional and Performance validation tests.
>> 
>> **Missing Pieces:-**
>> **-  AARCH64 Backend.**
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Hi,
> 
> Better to update the copyright year to 2024 for the following modified files:
> 
> 
> src/hotspot/share/adlc/output_h.cpp
> src/hotspot/share/opto/connode.cpp
> src/hotspot/share/opto/connode.hpp
> src/hotspot/share/opto/constantTable.cpp
> src/hotspot/share/opto/divnode.cpp
> src/hotspot/share/opto/divnode.hpp
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java
> test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java
> 
> 
> I encountered one JTreg IR failure on AArch64 machine with SVE feature for `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java` case. Here shows a snippet of the error log.
> If AArch64 backend part is not implemented, we'd better skip the IR verification on AArch64+SVE side.
> 
> 
> One or more @IR rules failed:                                                                                                                                                    
>                                                                                                                                                                                  
> Failed IR Rules (9) of Methods (9)                                                                                                                                               ----------------------------------                                                                                                                                               
> 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]:                                                               * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"avx512_fp16", "true", "sve", "true"}, counts={"_#ADD_VHF#_", ">= 1"
> }, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"                  
>      > Phase "PrintIdeal":                                                                                                                                                       
>        - counts: Graph contains wrong number of nodes:                                                                                                                           
>          * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*)"                                                                                                ...

Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - https://github.com/jatin-bhateja/jdk/pull/6. Do you think it's ok to keep the code as is for some more time until my patch is rebased and merged?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2490369622

From jbhateja at openjdk.org  Thu Nov 21 09:06:18 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 21 Nov 2024 09:06:18 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v6]
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <08UceifyOK3Ybhgtsa0PoYYLUXfNNh0yr4cMRd6EsZQ=.6d7c8ab6-b78c-463e-8be0-dcd14a443528@github.com>

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:

  Review comments + extending IR tests with instruction level checks

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21244/files
  - new: https://git.openjdk.org/jdk/pull/21244/files/84f2e04f..c128291c

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21244&range=04-05

  Stats: 40 lines in 2 files changed: 19 ins; 1 del; 20 mod
  Patch: https://git.openjdk.org/jdk/pull/21244.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21244/head:pull/21244

PR: https://git.openjdk.org/jdk/pull/21244

From jbhateja at openjdk.org  Thu Nov 21 09:06:20 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 21 Nov 2024 09:06:20 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v2]
In-Reply-To: <chcOYl_NgVxCgglUI_Nt-nAw1HFLT6td8ab4K_aLfJU=.9bb5ca76-4a7c-421b-9dec-5206bb411b37@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <E_OaRT6hx77ia4uB1iLLUb1j9x7xYNle5B6Out_fN4g=.d34599d3-a062-445f-b330-1e2800f79d32@github.com>
 <SSVxidFPgTWwzjXSgiId1Rj1GpHKIci2JSp2k0khNk4=.f2719035-4d04-41d8-b056-c72a9a4648ca@github.com>
 <IwXC8gTLD1LKFMu6DpulYxgbt5Zp1WTaL6Cc19V2dJw=.80a1e2a3-178b-4f10-9431-ea41e1c3ddd8@github.com>
 <chcOYl_NgVxCgglUI_Nt-nAw1HFLT6td8ab4K_aLfJU=.9bb5ca76-4a7c-421b-9dec-5206bb411b37@github.com>
Message-ID: <Ppo_7wr2yhGORJ8e6QvynVnSeJPlPJFRqhi7nWD0eSI=.16cecfb1-1a96-40a3-a452-e27e693ee06d@github.com>

On Tue, 12 Nov 2024 21:49:22 GMT, Vladimir Ivanov <vlivanov at openjdk.org> wrote:

>>> In the latest version you added new Ideal nodes (`MulIVL` and `MulUIVL`). I don't see a compelling reason to do so. IMO matcher functionality is more than enough to cover `VPMULDQ` case. `MulIVL` is equivalent to `MulVL` + `has_int_inputs()` predicate. For `MulUIVL` you additionally do input rewiring (using `forward_masked_input`), but (1) `AndV src (Replicate 0xFFFFFFFF))` operands can be easily detected on matcher side (with an extra AD instruction); and (2) such optimization is limited because it is valid only for `0xFFFFFFFF` case while `has_uint_inputs() == true` for `C <= 0xFFFFFFFF`.
>>> 
>>> So, IMO `MulIVL` and `MulUIVL` nodes just add noise in Ideal graph without improving situation during matching.
>> 
>> Hi @iwanowww ,
>> Problem occurs only if AndV gets shared; in such a case, matcher will not be able to identify the constrained multiplication pattern and absorb the masking pattern. Specialized IR overrules such limitations and shields the pattern from downstream optimization passes, thereby removing any non-determinism. In addition, it facilitates forwarding inputs to the multiplier, the new IR is explicit in its semantics of considering only lower doublewords of quadword lanes for multiplication, hence we can safely save emitting redundant input masking instructions. We already have specialized IR nodes like MulAddVS2VINode and I see these new IR nodes similar to it.
>
> @jatin-bhateja in case when `AndV` is shared, it can't be eliminated unless all users absorb it. For such cases, matcher can perform adhoc node cloning, but in this particular case it looks like an overkill either way. IMO the pattern is too niche to focus on it (either to justify input forwarding or adhoc handling on matcher side). 
> 
> It's good you mentioned `MulAddVS2VI`. On one hand, VNNI operations are more complex (similar to FMA), so such complexity *may* be justified there. On the other hand, it doesn't look like VNNI support in C2 age well. It is tied to auto-vectorizer and, by now, Vector API doesn't benefit from it. So, instead of doubling down on `MulAddVS2VI` path, I'd prefer to leave it aside and reimplement it later in a more maintainable manner.

Hi @iwanowww , your closing comments addressed, kindly re-approve, the change is mainly in newly added test file.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21244#issuecomment-2490437406

From jpai at openjdk.org  Thu Nov 21 09:07:26 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 09:07:26 GMT
Subject: RFR: 8342380: Implement JEP 498: Warn upon Use of Memory-Access
 Methods in sun.misc.Unsafe [v3]
In-Reply-To: <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
 <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
Message-ID: <ZurrZmqmsHwt-wTGcNUihs09db2qbHKrp0e8n2rXrig=.5081b54c-8bdb-4e48-8804-27797747821b@github.com>

On Mon, 18 Nov 2024 09:42:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Change default value of the command line option --sun-misc-unsafe-memory-access from "allow" to "warn".
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8342380
>  - Merge branch 'master' into JDK-8342380
>  - Update test
>  - Merge branch 'master' into JDK-8342380
>  - Update usage/man page
>  - Initial commit

test/jdk/sun/misc/UnsafeMemoryAccessWarnings.java line 51:

> 49:     @ValueSource(strings = {
> 50:             "allocateMemory+freeMemory",
> 51:             "objectFieldOffset+putLong+getLong"

Is the removal of `invokeCleaner` method name from these method names intentional?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21762#discussion_r1851629738

From vklang at openjdk.org  Thu Nov 21 09:07:30 2024
From: vklang at openjdk.org (Viktor Klang)
Date: Thu, 21 Nov 2024 09:07:30 GMT
Subject: RFR: 8336707: Contention of ForkJoinPool grows when stealing works
 [v30]
In-Reply-To: <jdXX1VI1LqZh-s8G-mqnEBTj460KfGSz7uL532mSHtM=.8999d2a6-e629-4181-a0b1-190759275c87@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
 <jdXX1VI1LqZh-s8G-mqnEBTj460KfGSz7uL532mSHtM=.8999d2a6-e629-4181-a0b1-190759275c87@github.com>
Message-ID: <_nfYo7diXf110knoz-UWkG6aC75iAv3wAbMoHmy26ok=.49ac1b69-6f8b-4a3d-9355-74a9f8afbd2c@github.com>

On Tue, 19 Nov 2024 22:51:04 GMT, Doug Lea <dl at openjdk.org> wrote:

>> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),
>
> Doug Lea has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 52 additional commits since the last revision:
> 
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Add comments
>  - Ensure InnocuousForkJoinWorkerThread usable with or without SecurityManager
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Rename variable
>  - Merge branch 'openjdk:master' into JDK-8336707
>  - Improve readbility; tweak runState checks
>  - Address review comments
>  - Merge remote-tracking branch 'refs/remotes/origin/JDK-8336707' into JDK-8336707
>  - ... and 42 more: https://git.openjdk.org/jdk/compare/544bc3cc...b0fe90e0

Great work, @DougLea!

-------------

Marked as reviewed by vklang (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21507#pullrequestreview-2450684522

From jbhateja at openjdk.org  Thu Nov 21 09:08:22 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 21 Nov 2024 09:08:22 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <c02yPuK_WOM8ZheMpEUTkhvPxcbI3T-nRJ3si6BpLdQ=.10de7e87-19d9-44e2-8afe-b5dee9e78fc5@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <c02yPuK_WOM8ZheMpEUTkhvPxcbI3T-nRJ3si6BpLdQ=.10de7e87-19d9-44e2-8afe-b5dee9e78fc5@github.com>
Message-ID: <T1ZkMnzkl3ZmHJ7yGR1mFlcTUR1mzpOLCyZ1ECTyZts=.cd868428-4470-45a2-880f-91e1474f46c5@github.com>

On Thu, 21 Nov 2024 02:41:47 GMT, Hao Sun <haosun at openjdk.org> wrote:

>> Hi All,
>> 
>> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
>> 
>> Following is the summary of changes included with this patch:-
>> 
>> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
>> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
>> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
>> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
>> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
>> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
>> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
>> 6. Auto-vectorization of newly supported scalar operations.
>> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
>> 9. Functional and Performance validation tests.
>> 
>> **Missing Pieces:-**
>> **-  AARCH64 Backend.**
>> 
>> Kindly review and share your feedback.
>> 
>> Best Regards,
>> Jatin
>
> Hi,
> 
> Better to update the copyright year to 2024 for the following modified files:
> 
> 
> src/hotspot/share/adlc/output_h.cpp
> src/hotspot/share/opto/connode.cpp
> src/hotspot/share/opto/connode.hpp
> src/hotspot/share/opto/constantTable.cpp
> src/hotspot/share/opto/divnode.cpp
> src/hotspot/share/opto/divnode.hpp
> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java
> test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java
> 
> 
> I encountered one JTreg IR failure on AArch64 machine with SVE feature for `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java` case. Here shows a snippet of the error log.
> If AArch64 backend part is not implemented, we'd better skip the IR verification on AArch64+SVE side.
> 
> 
> One or more @IR rules failed:                                                                                                                                                    
>                                                                                                                                                                                  
> Failed IR Rules (9) of Methods (9)                                                                                                                                               ----------------------------------                                                                                                                                               
> 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]:                                                               * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"avx512_fp16", "true", "sve", "true"}, counts={"_#ADD_VHF#_", ">= 1"
> }, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"                  
>      > Phase "PrintIdeal":                                                                                                                                                       
>        - counts: Graph contains wrong number of nodes:                                                                                                                           
>          * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*)"                                                                                                ...

> Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - [jatin-bhateja#6](https://github.com/jatin-bhateja/jdk/pull/6). Do you think it's ok to keep the code (regarding aarch64) in this patch as is for some more time until my patch is rebased and merged?

Hi @Bhavana-Kilambi , As @PaulSandoz  suggested, please file a follow-up PR on top of these changes with AARCH64 backend changes.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2490445899

From alanb at openjdk.org  Thu Nov 21 09:26:27 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Nov 2024 09:26:27 GMT
Subject: RFR: 8342380: Implement JEP 498: Warn upon Use of Memory-Access
 Methods in sun.misc.Unsafe [v3]
In-Reply-To: <ZurrZmqmsHwt-wTGcNUihs09db2qbHKrp0e8n2rXrig=.5081b54c-8bdb-4e48-8804-27797747821b@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
 <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
 <ZurrZmqmsHwt-wTGcNUihs09db2qbHKrp0e8n2rXrig=.5081b54c-8bdb-4e48-8804-27797747821b@github.com>
Message-ID: <ZuLu-uF4IHt9XZdJeDi0lYig9FHM8-9r4_Eo40p3i3I=.aebd7a59-84d3-4db5-b4e4-698117096408@github.com>

On Thu, 21 Nov 2024 09:04:47 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

>> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
>> 
>>  - Merge branch 'master' into JDK-8342380
>>  - Merge branch 'master' into JDK-8342380
>>  - Update test
>>  - Merge branch 'master' into JDK-8342380
>>  - Update usage/man page
>>  - Initial commit
>
> test/jdk/sun/misc/UnsafeMemoryAccessWarnings.java line 51:
> 
>> 49:     @ValueSource(strings = {
>> 50:             "allocateMemory+freeMemory",
>> 51:             "objectFieldOffset+putLong+getLong"
> 
> Is the removal of `invokeCleaner` method name from these method names intentional?

Yes because testOneWarning is only useful when called with two or more method names.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21762#discussion_r1851660061

From jpai at openjdk.org  Thu Nov 21 09:32:13 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 09:32:13 GMT
Subject: RFR: 8342380: Implement JEP 498: Warn upon Use of Memory-Access
 Methods in sun.misc.Unsafe [v3]
In-Reply-To: <ZuLu-uF4IHt9XZdJeDi0lYig9FHM8-9r4_Eo40p3i3I=.aebd7a59-84d3-4db5-b4e4-698117096408@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
 <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
 <ZurrZmqmsHwt-wTGcNUihs09db2qbHKrp0e8n2rXrig=.5081b54c-8bdb-4e48-8804-27797747821b@github.com>
 <ZuLu-uF4IHt9XZdJeDi0lYig9FHM8-9r4_Eo40p3i3I=.aebd7a59-84d3-4db5-b4e4-698117096408@github.com>
Message-ID: <Pnm-5fVU7cmFEEddkVMI_6edBhAlBW-b5TjuywPdVZU=.23356b9b-fe43-4a08-80db-83c5219c12e2@github.com>

On Thu, 21 Nov 2024 09:23:26 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> test/jdk/sun/misc/UnsafeMemoryAccessWarnings.java line 51:
>> 
>>> 49:     @ValueSource(strings = {
>>> 50:             "allocateMemory+freeMemory",
>>> 51:             "objectFieldOffset+putLong+getLong"
>> 
>> Is the removal of `invokeCleaner` method name from these method names intentional?
>
> Yes because testOneWarning is only useful when called with two or more method names.

Sorry I wasn't clear - what I meant was including `invokeCleaner` in the long list of method names like it was previously - `allocateMemory+freeMemory+objectFieldOffset+putLong+getLong+invokeCleaner`, not as an individual method name on its own. It's not a big deal to leave it out though, since these are not the complete set of method names anyway.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21762#discussion_r1851673746

From dfuchs at openjdk.org  Thu Nov 21 09:38:14 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 09:38:14 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v2]
In-Reply-To: <F0UOh57K-vnzYfmMdk-RxCCD-7WIkFWgRSmNU_ZKsVM=.2529c11c-1138-4b54-b973-0a93e37cbe34@github.com>
References: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
 <F0UOh57K-vnzYfmMdk-RxCCD-7WIkFWgRSmNU_ZKsVM=.2529c11c-1138-4b54-b973-0a93e37cbe34@github.com>
Message-ID: <IRg5ck7DOst_bV9BxAgAxb47fZ3PQnpsU-MzNxzvMCQ=.2717ef69-1dd3-49c3-b4ee-2360acce30e1@github.com>

On Wed, 20 Nov 2024 21:03:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>> 
>> Refresh of PR#22168 Including review comments made there.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove latent permission and checkPermission.

Thanks for the updates to LoggerFinder. LGTM now.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22282#pullrequestreview-2450775806

From jpai at openjdk.org  Thu Nov 21 09:43:18 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 09:43:18 GMT
Subject: RFR: 8342380: Implement JEP 498: Warn upon Use of Memory-Access
 Methods in sun.misc.Unsafe [v3]
In-Reply-To: <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
References: <OOhBHY7b2HAE-arrL5Qwhk6wYCCD6F0lz9PF8BA14PI=.6b08d17a-72d8-4fe7-9271-b0d3b99d68de@github.com>
 <_BDz1D_Eun9zRgfNSP22AUpmuZ1kbJa-yHZ7Yhv5wRk=.bac1bb8e-fa12-46c9-af35-c440482655d4@github.com>
Message-ID: <t48daG08Al-Hz4hfLBI9fO9Ngqk08SCa-Hr8PLXr9lA=.13f0a285-41a4-47c2-9985-4bf5a5ef0201@github.com>

On Mon, 18 Nov 2024 09:42:20 GMT, Alan Bateman <alanb at openjdk.org> wrote:

>> Change default value of the command line option --sun-misc-unsafe-memory-access from "allow" to "warn".
>
> Alan Bateman has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains six commits:
> 
>  - Merge branch 'master' into JDK-8342380
>  - Merge branch 'master' into JDK-8342380
>  - Update test
>  - Merge branch 'master' into JDK-8342380
>  - Update usage/man page
>  - Initial commit

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21762#pullrequestreview-2450790061

From bkilambi at openjdk.org  Thu Nov 21 09:54:24 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 21 Nov 2024 09:54:24 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <T1ZkMnzkl3ZmHJ7yGR1mFlcTUR1mzpOLCyZ1ECTyZts=.cd868428-4470-45a2-880f-91e1474f46c5@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
 <c02yPuK_WOM8ZheMpEUTkhvPxcbI3T-nRJ3si6BpLdQ=.10de7e87-19d9-44e2-8afe-b5dee9e78fc5@github.com>
 <T1ZkMnzkl3ZmHJ7yGR1mFlcTUR1mzpOLCyZ1ECTyZts=.cd868428-4470-45a2-880f-91e1474f46c5@github.com>
Message-ID: <L71yEqh47VG-jV54ecJhtk5xOlqQaMqKP6CzWQkaVY0=.bf80d162-ebec-4568-9e23-83ae1a10cdf3@github.com>

On Thu, 21 Nov 2024 09:05:23 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> Hi,
>> 
>> Better to update the copyright year to 2024 for the following modified files:
>> 
>> 
>> src/hotspot/share/adlc/output_h.cpp
>> src/hotspot/share/opto/connode.cpp
>> src/hotspot/share/opto/connode.hpp
>> src/hotspot/share/opto/constantTable.cpp
>> src/hotspot/share/opto/divnode.cpp
>> src/hotspot/share/opto/divnode.hpp
>> src/jdk.internal.vm.ci/share/classes/jdk/vm/ci/amd64/AMD64.java
>> test/hotspot/jtreg/compiler/lib/ir_framework/test/IREncodingPrinter.java
>> 
>> 
>> I encountered one JTreg IR failure on AArch64 machine with SVE feature for `test/hotspot/jtreg/compiler/vectorization/TestFloat16VectorOperations.java` case. Here shows a snippet of the error log.
>> If AArch64 backend part is not implemented, we'd better skip the IR verification on AArch64+SVE side.
>> 
>> 
>> One or more @IR rules failed:                                                                                                                                                    
>>                                                                                                                                                                                  
>> Failed IR Rules (9) of Methods (9)                                                                                                                                               ----------------------------------                                                                                                                                               
>> 1) Method "public void compiler.vectorization.TestFloat16VectorOperations.vectorAddFloat16()" - [Failed IR rules: 1]:                                                               * @IR rule 1: "@compiler.lib.ir_framework.IR(phase={DEFAULT}, applyIfPlatformAnd={}, applyIfCPUFeatureOr={"avx512_fp16", "true", "sve", "true"}, counts={"_#ADD_VHF#_", ">= 1"
>> }, failOn={}, applyIfPlatform={}, applyIfPlatformOr={}, applyIfOr={}, applyIfCPUFeatureAnd={}, applyIf={}, applyIfCPUFeature={}, applyIfAnd={}, applyIfNot={})"                  
>>      > Phase "PrintIdeal":                                                                                                                                                       
>>        - counts: Graph contains wrong number of nodes:                                                                                                                           
>>          * Constraint 1: "(\d+(\s){2}(AddVHF.*)+(\s){2}===.*)"                                          ...
>
>> Hi @shqking , thanks for your review. I am currently working on adding the aarch64 port for these operations. It's being done here - [jatin-bhateja#6](https://github.com/jatin-bhateja/jdk/pull/6). Do you think it's ok to keep the code (regarding aarch64) in this patch as is for some more time until my patch is rebased and merged?
> 
> Hi @Bhavana-Kilambi , As @PaulSandoz  suggested, please file a follow-up PR on top of these changes with AARCH64 backend changes.

Hi @jatin-bhateja , I am resolving some errors on an aarch64 machine and if I have to raise a separate PR for aarch64, would you please remove all the aarch64 related IR checks until I have added the aarch64 backend? I might take some time to put the changes up for review. Thanks!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21490#issuecomment-2490607729

From dfuchs at openjdk.org  Thu Nov 21 10:20:19 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 10:20:19 GMT
Subject: RFR: 8344235: Revisit SecurityManager usage in java.logging after
 JEP 486 and JEP 491 integration
In-Reply-To: <5l77CiaoalA8-CC6S7olVjdqLQILNZ4F6-1KWgjQXTg=.77b08815-151e-4805-9e7e-a1b8605a01fa@github.com>
References: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
 <5l77CiaoalA8-CC6S7olVjdqLQILNZ4F6-1KWgjQXTg=.77b08815-151e-4805-9e7e-a1b8605a01fa@github.com>
Message-ID: <lA3tvBc8zbX_uWYL3pSu1v2gmfAVa70ApS_2TG83rHY=.0ed23250-2ed7-4b10-8896-061ca71d9598@github.com>

On Thu, 21 Nov 2024 06:50:48 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> Hello Daniel, the changes look good to me. However, these changes appear to include both JEP 486 related updates as well as the JEP 491 (the reverting of ReentrantLock usage in favour of synchronized). Doing this clean up together I think is fine. However, I think we should update the issue title to also include JEP 491 in addition to JEP 486.

Oh right. I should have mentioned that in the summary. This is now done, I modified the JBS and PR titles as suggested too.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22281#issuecomment-2490703222

From dfuchs at openjdk.org  Thu Nov 21 10:24:28 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 10:24:28 GMT
Subject: RFR: 8344235: Revisit SecurityManager usage in java.logging after
 JEP 486 and JEP 491 integration [v2]
In-Reply-To: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
References: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
Message-ID: <hBgstPIzP2xKl_11ULTUGr2wagYOoquY6UVlwqlYLEM=.2e2548aa-94fa-4bff-82c0-ca7ff3d3961a@github.com>

> This PR remove usage of SecurityManager, doPrivileges, etc... from `java.logging` and `java.base/jdk.internal.logger`
> 
> Only notable hack - Logger.checkPermission() no longer checks permissions, but has been renamed into `ensureLogManagerInitialized()` in order to avoid disturbing the initialization sequence of Logger/LogManager.
> 
> I am not 100% sure this is still needed - but I remember we had some entanglement issues in the past that had been hard to solve, so it seemed prudent to keep the call:
> 
> 
>     if (manager == null) {
>         manager = LogManager.getLogManager();
>     }
> 
> 
> where `manager` is a private volatile field in Logger.
> 
> I also took the opportunity to remove the locking workaround that had been introduced to support Virtual Threads and revert to using synchronized in the Handler classes now that JEP 491 has been integrated.

Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:

  Review feedback

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22281/files
  - new: https://git.openjdk.org/jdk/pull/22281/files/169e8c20..ef8b71e1

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22281&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22281&range=00-01

  Stats: 3 lines in 1 file changed: 0 ins; 2 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22281.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22281/head:pull/22281

PR: https://git.openjdk.org/jdk/pull/22281

From dfuchs at openjdk.org  Thu Nov 21 10:24:29 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 10:24:29 GMT
Subject: RFR: 8344235: Revisit SecurityManager usage in java.logging after
 JEP 486 and JEP 491 integration [v2]
In-Reply-To: <gGR8r4gr9nKfZvAVhHdh_cJ2vlFAaJEFxGMb2Lo3lbU=.08cc03a8-0754-4d56-aa48-8c1a5bc28ba7@github.com>
References: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
 <gGR8r4gr9nKfZvAVhHdh_cJ2vlFAaJEFxGMb2Lo3lbU=.08cc03a8-0754-4d56-aa48-8c1a5bc28ba7@github.com>
Message-ID: <bDlKeGZcOiOSszb07trXZ-HyJXondg1iuB2YOTyDPvM=.b07caddd-bc4b-42ce-9a61-fa731c5ab184@github.com>

On Wed, 20 Nov 2024 20:29:06 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Review feedback
>
> src/java.base/share/classes/jdk/internal/logger/LoggerFinderLoader.java line 114:
> 
>> 112: 
>> 113:     private static Iterator<System.LoggerFinder> findLoggerFinderProviders() {
>> 114:         final Iterator<System.LoggerFinder> iterator =
> 
> Could be simply be `return ` ... no need for a local var.

Done

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22281#discussion_r1851774290

From rotanolexandr842 at gmail.com  Thu Nov 21 10:25:35 2024
From: rotanolexandr842 at gmail.com (Olexandr Rotan)
Date: Thu, 21 Nov 2024 12:25:35 +0200
Subject: Range API
In-Reply-To: <CAL5bRt_COc7apvQbWucbwzNWdQa+vYggrRhB_fnLNtZKUNvP=Q@mail.gmail.com>
References: <CAL5bRt--u7b36v_h=+JBuRX7sFRfXtYpf3hKc6umiHpYJjU+MQ@mail.gmail.com>
 <CACzrW9C778kWhV40zT3iLbQWuShnELdR3LuAG4KVY_p_-U0GxQ@mail.gmail.com>
 <CAL5bRt96AF3P4k3bGHUx0Tx9T9Z-xa8dMRFtROubHT5fuF_agQ@mail.gmail.com>
 <CAL5bRt9RWhMFdEPUqU1TvBoKR=kKSiV0szYRJTOK5m0M4KoQMA@mail.gmail.com>
 <5320CD47-A9EB-44BE-994B-F296FC281D3A@cbfiddle.com>
 <CAL5bRt9zu_WtHUi-0J2L5LThpWfCaGWCrd5cxLHNkJJ52uHHxA@mail.gmail.com>
 <f8fda70c-9eb5-4cdc-beb7-04a4c83616b8@oracle.com>
 <CAL5bRt_COc7apvQbWucbwzNWdQa+vYggrRhB_fnLNtZKUNvP=Q@mail.gmail.com>
Message-ID: <CAL5bRt_+HQb5r+Avz=y+kyrZzKt36gh9H1SGVabZvWA5JPV4Zw@mail.gmail.com>

Text copied from PR draft since no one really goes through 2-month old
drafts ;)

For anyone wondering what's up with this PR, I have decided to take a
little break from coding itself and focus on the more fundamental part of
ranges. Most of the time I was thinking about the range lifecycle, how the
range that was acquired from the chain of operations is fundamentally
different from the plain range created using Range.of and stuff like that.
Also I have been thinking about how exactly should custom comparators be
consoled with range operations, which is obviously the point of most
friction regarding comparators for ranges.

1. Lifecycle

Generally, I see 4 use cases for ranges. I will put them in "popularity"
order, speaking from my experience
1. Receive boolean value (does contain, does intersect etc.)
2. iterate over (It may become more popular as ranges are present in jdk,
but as Brian Goetz once mentioned in mail, no one is really hurt by the
necessity to write for loop instead of foreach over range, so I don't
consider stuff like for(var i : Range.of(0, 10) a valuable use case).
3. Provide as input (also known as slicing in python and things alike in
other languages)
4. Receiving range as result of method (not really a terminal operation,
but case is huge enough to acknowledge it separately)

I have been through multiple iterations of use-case investigation. At some
point, I have even thought about dropping range operation completely. What
stopped me, though, is one of the tasks I have received at work recently,
which completely changed my mind. The one particular use case that I find
huge enough to be worth support in API is scheduling with only one task per
moment, i.e. scheduling lessons for teachers. for example, accounting for
business hours and stuff like that. I believe this is one of the most
common things business logic programmers deal with when talking about
datetime ranges.

>From this point, I have been looking at this topic from a somewhat
different perspective. I believe that most of the time (dominating majority
of times) results of range operations would be used to acquire boolean
value. Passing it as input would be a mess to handle as range can be
interrupting/continuous. Iterating over ranges like that may lead to
confusing behaviour, for example, consider:

[1;4] U [5;10] with step 3. Should it be like 1,4,7,5,8 or 1,4,5,7,8 or
maybe 1,4,5,8 ? This is just too confusing to consider.

On the other hand, continuous, as-is ranges (ones that are created directly
with factory method), would be a much better candidate for iteration, for
many cases, from safe iteration over substring indexes to just plain for
loop replacement (people for some reason want this a little bit too much).

So, summarizing everything above: range operation is a valid request,
although support for everything available to "plain" ranges would be
inappropriate for more complex ranges, specifically unions. Unions are
mostly used for boolean operations, while plain ranges can have a broader
number of use cases. For iteration over unions, the best option I see is to
provide a method that returns a List of their components so people can
by-hand decide which behaviour exactly do they want.

2. Range operations and comparators rivalry

I think everyone could in 5 seconds come up with at least one case when
these two conflict. I was thinking a lot about this. Prototyping some sorts
of operation contexts (something like java.math.MathContext), creating
classes that were responsible for range operations that required providing
comparator for each action (this one I brushed off for multiple reasons: 3
parameters for each method sounds horrific, many implementation
intricacies, and generally not intuitive way to operate on rages
considering 95% of use cases will be bound to datetime and numerics and
things backed by them), and other stuff. Surprisingly, where I found
similar problems is in the collection framework, specifically in sets. The
problems here were really much more alike to range then I have expected
(basically the same except for the fact that set has only one 2 possible
relations to element: contains or not, while ranges have 5 possible
relations to other ranges (one can be before, after, contained, or
intersect at start or end with other) which obviously complicates things).
Collections framework just state behaviour in operations between sets that
use different equality metrics as well, not undefined, but confusing for
anyone who doesn't know implementation details. I am planning to prototype
something with the same kind of behaviour for ranges, but I still haven't
decided how 2 ranges will communicate with each other (analogy for how sets
communicate using contains).

That's basically it for now, i will continue with investigation, maybe work
will also give some food for though as with schedule, and when I feel like
I have some common ground for all of the things I would want to see in the
API, I will proceed with some sort of more mature API description

On Thu, Sep 26, 2024 at 11:00?PM Olexandr Rotan <rotanolexandr842 at gmail.com>
wrote:

> but I also don't sense people beating down the doors for that (even if the
>> language had range literals, like `0..<100`).
>
>
> True, that what I was thinking also: "is iteration over numeric range is
> so important to challenge general versatility of API?", but
>
> for (int j=index; j<index+target.length(); j++)
>
>
> is the use case that I haven't even thought of. After some research, I
> found a family of methods across jdk that could benefit from ranges. Their
> names match X::indexOf(X) or X::indexOfSubX(X) or similar patterns. I did
> some research and found it surprising that the only young language, which
> all now have first-class support for ranges, that takes advantage of range
> return types is Swift and its string::range(of: substring) (maybe there is
> similar methods for sublists in Swift, I think it is not that significant).
> Others either return an optional int or int itself.
>
> Much more languages, though, have adapted ranges as input parameters for
> slicing and other range-specifying operations, not lastly due to issues like
>
> Similarly, I see errors in API usage because sometimes we specify range by
>> (start, end) and sometimes by (start, length)
>
>
> Though, there are some differences with the vast majority of languages and
> this API currently, mostly with the fact that almost all languages do not
> support any range algebra out-of-the-box (closest I have seen were
> itertools in Rust), and, subsequently, there is nowhere to emerge for unios
> from, unlike current implementation. Adapting return types for being
> three-state algebraic data types (i.e. result of passing empty range,
> result of passing uninterrupted and result of passing union) is not that
> hard, but just another work to do in case similar APIs would be adopted in
> jdk.
>
> My research about iterability of ranges in other languages showed that
> there is, unfortunately, no magic pill invented. Basically, there are two
> approaches to making range iterable:
>
> 1) Implement iterator
> 2) Implement increment/decrement
>
> The concrete way might vary from traits in Rust (and something like this
> in Haskell I suppose) to operator overloading in c++, but concepts are the
> same. Most languages also provide out-of-the-box support for integer
> ranges.
>
> And that is what I concluded on, at least for now. I think that API should
> provide support for any custom iteration strategy using something like
> Collector/Gatherer wrappers over a functional interface that will transform
> increment/decrement function into iterator. Besides that, I think that it
> makes sense to create separate Range.OfInts(int, int) or just
> Range.of(int,int) overload, that will return thin extension of
> Range<Integer> (noone convinces me to create new specialized class), that
> implements iterable using simple int increments, which would both benefit
> the performance and address most of the use cases for "obviously iterable"
> ranges. I also think there is no need for open iterable ranges, even if
> start-closed. I think it is better to have some method to return Stream
> than implement Iterable, since this might lead to unexpected problems.
>
> Best regards
>
> On Thu, Sep 26, 2024 at 4:30?PM Brian Goetz <brian.goetz at oracle.com>
> wrote:
>
>> Sorry for the not-good news, but I'm not too surprised.  Computational
>> domains like "32 bit integers" seem like they should have a lot in common
>> with algebraic structures like groups and rings, but when you start poking
>> at them, the compromises we make to fit them into hardware registers start
>> to bite.  (And let's not get started on floating point...)  Lots of
>> research into numeric towers in various languages, or capturing fundamental
>> properties in type classes like Haskell's `Eq` and `Ord`, offers plenty of
>> compromise to go with its promise.
>>
>> I think a big part of what you are running into is that you've started
>> with a _concept_ (a deceptively simple one, at that), rather than
>> _requirements_.  And it is the open-endedness of this concept (discrete vs
>> continuous, bounded vs half-open, including endpoints or not, etc) that
>> resists abstraction.  Plus, without clear requirements, you will be subject
>> to an endless barrage of "what about my pet use case" (e.g., "what about
>> the numbers zero to ten, advancing by two").  Meanwhile, domain-specific
>> libraries such as java.time will invent their own domain-specific answers,
>> like Interval.
>>
>> Rather than starting from the algebraic properties, perhaps start from
>> the other end: what are the use cases where the lack of a range abstraction
>> is problematic.  I get that
>>
>>     for (int i=0; i<100; i++) { ... }
>>
>> is uglier and less abstract than
>>
>>     for (int i : Range.of(0, 100)) { ... }
>>
>> but I also don't sense people beating down the doors for that (even if
>> the language had range literals, like `0..<100`).
>>
>> Where I do see people having trouble is that many range computations are
>> error prone.  For example, `String::indexOf` returns the starting index of
>> a match; if you want to actually iterate over the characters of such a
>> match, you have to do something like
>>
>>     for (int j=index; j<index+target.length(); j++)
>>
>> and you are at risk for fencepost errors when recreating the range.
>> Whereas an indexOf method (under a more suitable name) that returned a
>> range, would be more amenable to downstream processing.  Similarly, I see
>> errors in API usage because sometimes we specify range by (start, end) and
>> sometimes by (start, length), and since both are ints, we get no type
>> checking when you pass the wrong kinds of ints to such a method.
>>
>> But, the mere existence of a Range type would do little to help String,
>> Arrays, and other range-happy APIs, because we would have to update them to
>> include new overloads that dispense and consume ranges.  So that's a big
>> project.
>>
>> Still, I think investigating use cases involving libraries that work
>> intensively with ranges like this would likely yield useful information for
>> what a Range type would want to provide.
>>
>> HTH,
>> -Brian
>>
>>
>>
>>
>>
>>
>> On 9/26/2024 9:07 AM, Olexandr Rotan wrote:
>>
>> Researching the of deriving some iterable representations from ranges,
>> and I am not here with the good news.
>>
>> Unlike range algebra and boolean operations, which generalize
>> extremely well, iterability of ranges... Well, it's safe to say it
>> doesn't generalize at all. Analyzing key features people expect iterable
>> ranges to have, I ended up concluding there are basically two groups / two
>> use cases for them. First is plain and simple, arguably the most popular
>> one: iterating over a range of integer numbers, i.e. `for (i : Range.of(1,
>> 10))`. Another use case is for more complex iterations over ranges of
>> reference types, most commonly dates/time.
>>
>> There are two groups of values by their nature: discrete and continuous.
>> Most of the types belong to the second group, as there is no direct
>> increment AND decrement for them (we will omit hardware limitations for
>> simplicity), such as floating point values. What is the increment of 1,3?
>> 1.31 or 1.30000000001, or maybe something even more unreadable? On the
>> other hand, the increment of LocalDate in context of range iteration that
>> represents today is rather obvious - it is tomorrow.
>>
>> There is a pretty limited number of discrete types in jdk. Dates, whole
>> numbers and basically that's it. The discrete types that are not present in
>> jdk can be really various. For example, users can define a comparable
>> type "F1Team" and compare them based on their position in the last race.
>> There, increment would most likely be the next team in rating. There are
>> many domain-specific cases like this.
>>
>> This is where the problem comes from. If the user would always have to
>> pass a comparator to create a range, it would be consistent to make the
>> user define increment/decrement as well. But we don't want users to pass a
>> comparator if the type is already comparable. Similarly, we don't want
>> users to define increment/decrement if there is already one in the
>> language! I think defining increments for dates (say LocalDate.plusDays(1))
>> would be acceptable, even defining increments for floats in context of
>> ranges might be acceptable, but making people define increments for
>> integers is, in my opinion, completely not. Besides performance impact,
>> this is a terrible user experience.
>>
>> There are a few solutions to this:
>> 1) Define ton of overrides for factory methods and specialized types for
>> this (uhh, sounds awful)
>> 2) Introduce new interface, say Discrete<T>, that defines T increment()
>> (and possible T decrement()) methods. From now on, there are 2 branches:
>> 2.1) Leave things as is, allow users to define incrementation logic for
>> their types, but don't touch integers and other built-ins.I see this option
>> as extremely inconsistent and not solving the main issue, which is
>> iterability of integers.
>> 2.2) Retrofit (scary) existing types to implement this interface. This
>> should not have any compatibility nor security implications, but still
>> sneaking into java.lang every time we need some new API to be more
>> user-friendly is obviously not a way to go. This basically comes down to a
>> question about how deep we want to integrate ranges into language, and is
>> range  generalization even worth the invasion into the core of
>> language (imo yes).
>> 3) Leave things as they are, just let users derive iterables using
>> something like range.asIterableWithStep(IncremetStartegy increment). I
>> think this would make an API too narrow as no one will use it for routine
>> tasks the same way people do in Rust, Kotlin and other languages.
>>
>> I would love to hear community opinion on this matter. Which option is
>> the most preferable, maybe some compromise between a few of them, or maybe
>> there is a better way to go that I didn't mention here?
>>
>> Best regards
>>
>> On Tue, Sep 24, 2024 at 5:11?PM Alan Snyder <javalists at cbfiddle.com>
>> wrote:
>>
>>> I have another example: I have a datatype that represents a region of an
>>> audio track, for example, one tune in a medley of tunes. I allow the region
>>> to
>>> specify both a start and end time, but the end time is optional (and
>>> mostly not used). When the end time is not specified, the region ends at
>>> the start of the next region, or at
>>> the end of the track if there is no next region. The latter case is
>>> useful because the exact track length may not be known. The optionality of
>>> the end time
>>> is not represented in the type system.
>>>
>>> Having said that, I?m not sure that a general abstract interface would
>>> be useful for this example.
>>>
>>> On Sep 24, 2024, at 2:13?AM, Olexandr Rotan <rotanolexandr842 at gmail.com>
>>> wrote:
>>>
>>> As part of the redesigning  process , I am researching whether or not
>>> there are use cases that require asserting that the range is exactly
>>> half-bounded. This is important because I plan to switch to
>>> BoundedAtEnd/BoundedAtStart sealed interfaces instead of flags and runtime
>>> checks: Here is what I gathered for now.
>>>
>>>
>>>    - *Date/Time Handling (Historical or Forecast Data)*: When dealing
>>>    with events that started at a specific time but have no known end (e.g.,
>>>    open-ended employment contracts or ongoing subscriptions)
>>>    - *Stream Processing (Real-time Event Streams)*: In real-time
>>>    systems, you might process data that has a start time but no defined end,
>>>    such as monitoring a live video feed or logging system. The range is
>>>    bounded at the start and unbounded at the end as more data will
>>>    continuously arrive.
>>>    - *Data Pagination (Fetch Until Condition)*: When implementing
>>>    pagination, sometimes you might want to fetch items starting from a
>>>    specific index up to an unbounded limit (e.g., fetching all items after a
>>>    certain point until memory runs out or a condition is met).
>>>    - *Auditing and Monitoring*: In systems where audit trails or
>>>    logging data should capture all events after a certain point (bounded
>>>    start) with no foreseeable end (unbounded end), such as monitoring changes
>>>    to records in a database starting from a fixed timestamp.
>>>    - *Scientific or Statistical Ranges*: When modeling physical systems
>>>    or statistical ranges, you might want to capture measurements that begin at
>>>    a known threshold but theoretically have no upper or lower bound. For
>>>    example, recording temperature data starting at absolute zero and
>>>    increasing without any known upper limit.
>>>    - *Inventory or Resource Allocation*: Resource allocation policies,
>>>    such as those for virtual machines, may be based on known minimum
>>>    allocation thresholds but have flexible or unbounded resource caps,
>>>    depending on availability.
>>>
>>>    I am writing to ask whether anyone who worked with such systems
>>>    could confirm/deny that those are real use cases. If so, would it be
>>>    satisfying enough to assert one-way unboundness with instanceof checks,
>>>    i.e. range instanceof UnboundedEndRange && !(range instanceof
>>>    UnboundedStartRange). Would appreciate any feedback.
>>>
>>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241121/e42785b5/attachment-0001.htm>

From sgehwolf at openjdk.org  Thu Nov 21 10:32:16 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 21 Nov 2024 10:32:16 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <yLxZaNr1P2ha8_nCCRroiZBqtU6iS5ALjyKVVU2NyYQ=.d7228d8b-7476-4cac-9d42-e437d57e5c84@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
 <yLxZaNr1P2ha8_nCCRroiZBqtU6iS5ALjyKVVU2NyYQ=.d7228d8b-7476-4cac-9d42-e437d57e5c84@github.com>
Message-ID: <RMSHZmOEF88p7mQOxL8f17b0OjWBj0PMqMTbv45k6uc=.715f9e78-6683-4559-b1b4-39696852b217@github.com>

On Thu, 21 Nov 2024 05:24:26 GMT, Jaikiran Pai <jpai at openjdk.org> wrote:

> in addition, should we explicitly set this system property to false (or remove the system property) when --patch-module isn't used? I think that would then prevent applications from passing -Djdk.patched=true when the runtime hasn't been patched.

Sure, I can add this.

> While at it, should there be additional guards to prevent applications from changing the value of this system property by doing System.setProperty("jdk.patched") at runtime?

The JVM sets this property as read-only. So setting `jdk.patched=true` at command line or in code won't work to override. I'll add tests for these scenarios.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22277#discussion_r1851788164

From sgehwolf at openjdk.org  Thu Nov 21 10:41:14 2024
From: sgehwolf at openjdk.org (Severin Gehwolf)
Date: Thu, 21 Nov 2024 10:41:14 GMT
Subject: RFR: 8344560: Add system property for patched runtime
In-Reply-To: <hDKzS_beMAldQjUlB_KZ6Hpn5sFJJPIclEqbiFSLss0=.633a7e6c-a2c5-460b-ac73-f2e6378ec168@github.com>
References: <4Qi0P7txOJvWqfSGnZ-vxxsm4CqPPOmlxCVxBZzUzU0=.53c71ff6-e642-481f-80e1-c3bf8867ef00@github.com>
 <hDKzS_beMAldQjUlB_KZ6Hpn5sFJJPIclEqbiFSLss0=.633a7e6c-a2c5-460b-ac73-f2e6378ec168@github.com>
Message-ID: <H1coP_NrvvtsHab4m4VE5Fs2xSR5DV1B0U_4lGdrvGk=.4e821b35-fcd4-457c-9e9e-17d6c800c0dd@github.com>

On Thu, 21 Nov 2024 07:46:46 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Having now looked at #22037 which is what motivated this change, I now have a more basic question.
> > The `--patch-module` option is an option for the `java` command. The code changes in this current PR is proposing to set a system property if `java` was launched with `--patch-module=...`. The other PR is about image creation using `jlink` command. Looking at the other PR, it proposes to look for the presence of this system property to do some decisions during image creation. However, when that `jlink` command is invoked, it's a completely different process/runtime, so how would `--patch-module` for `java` setting a system property propagate to that image creation `jlink` process?
> > I am feeling that I have misunderstood what's being proposed here.
> 
> This is the corner case of jlink being run with -J--patch-module or "in-process" with ToolProvider.

Correct. For example, during testing of the implementation of JEP 493, a failure was observed in a completely unrelated langtools test, `test/langtools/tools/javac/plugin/AutostartPlugins.java` with a linkable runtime build. That test uses `jlink` via `ToolProvider` and wasn't being run with `/othervm`. At the same time, jtreg itself patches the test JDK runtime with `JTRegModuleHelper`.

> I see Severin recently added to the link of restrictions in JEP 493 but I'm not sure that it rises to the level that it should be mentioned in the JEP.

Happy to remove it from the JEP, but I don't think it does any harm. Does it?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2490753599
PR Comment: https://git.openjdk.org/jdk/pull/22277#issuecomment-2490755637

From asotona at openjdk.org  Thu Nov 21 10:59:23 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Nov 2024 10:59:23 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v4]
In-Reply-To: <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
Message-ID: <JjINc3y25QXD_9-3aAiquEnbZXLmMIfXhtt7bFAx2qQ=.4cb957b9-0984-4c82-9057-d8788a7655ec@github.com>

On Wed, 20 Nov 2024 23:03:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - typo
>  - More cleanup
>  - Remove a few confusions around bad modeling, some missing exceptions, also the labelless info models
>  - Non-int constant values

src/java.base/share/classes/java/lang/classfile/instruction/ConvertInstruction.java line 44:

> 42:  * Delivered as a {@link CodeElement} when traversing the elements of a {@link CodeModel}.
> 43:  * <p>
> 44:  * Conceptually, a primitive conversion instruction is a record:

Here remains "Conceptually, ... is a record"

src/java.base/share/classes/java/lang/classfile/instruction/DiscontinuedInstruction.java line 69:

> 67:      * instruction model is written by a {@link CodeBuilder}.
> 68:      * <p>
> 69:      * Jump subroutine instructions push a {@link TypeKind##returnAddress

I don't think we have a TypeKind##returnAddress.

src/java.base/share/classes/java/lang/classfile/instruction/DiscontinuedInstruction.java line 130:

> 128:      * <p>
> 129:      * {@link StoreInstruction astore} series of instructions store a {@link
> 130:      * TypeKind##returnAddress returnAddress} value to a local variable slot,

And the same here.

src/java.base/share/classes/java/lang/classfile/instruction/InvokeInstruction.java line 51:

> 49:  * Delivered as a {@link CodeElement} when traversing the elements of a {@link CodeModel}.
> 50:  * <p>
> 51:  * Conceptually, a method invocation instruction is a record:

And here

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1851832104
PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1851829395
PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1851829969
PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1851835367

From asotona at openjdk.org  Thu Nov 21 11:16:20 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Nov 2024 11:16:20 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v4]
In-Reply-To: <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
Message-ID: <-DfFxCoX5IygcBcF8b011NT5uqHFEtRh3tVi5bn2HdQ=.8d85460a-622b-4c67-9598-5acca1e055e0@github.com>

On Wed, 20 Nov 2024 23:03:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - typo
>  - More cleanup
>  - Remove a few confusions around bad modeling, some missing exceptions, also the labelless info models
>  - Non-int constant values

src/java.base/share/classes/java/lang/classfile/instruction/StoreInstruction.java line 76:

> 74:      * {@return the {@linkplain TypeKind##computational-type computational type}
> 75:      * of the value to be stored}  The {@link TypeKind#REFERENCE reference}
> 76:      * type store instructions also operate on the {@code returnAddress} type,

Where do we expose a TypeKind related to a return address?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1851860391

From asotona at openjdk.org  Thu Nov 21 11:21:17 2024
From: asotona at openjdk.org (Adam Sotona)
Date: Thu, 21 Nov 2024 11:21:17 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v4]
In-Reply-To: <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
Message-ID: <AZ-89WbW2RoOdpQdYhecqV7C3XM0mC7Mok_BvZPxcWQ=.72ce3e54-d66c-47a6-b95a-4f64ad8fd173@github.com>

On Wed, 20 Nov 2024 23:03:43 GMT, Chen Liang <liach at openjdk.org> wrote:

>> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
>> 
>> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
>> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
>> 
>> Please review the associated CSR as well.
>
> Chen Liang has updated the pull request incrementally with four additional commits since the last revision:
> 
>  - typo
>  - More cleanup
>  - Remove a few confusions around bad modeling, some missing exceptions, also the labelless info models
>  - Non-int constant values

It looks better to me now, much easier to understand.

@jddarcy what do you think about general formulations "Xy instruction can be viewed as a record..." describing code elements exposed as sealed interfaces in the API?

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21625#issuecomment-2490844359

From jpai at openjdk.org  Thu Nov 21 11:44:24 2024
From: jpai at openjdk.org (Jaikiran Pai)
Date: Thu, 21 Nov 2024 11:44:24 GMT
Subject: RFR: 8344235: Revisit SecurityManager usage in java.logging after
 JEP 486 and JEP 491 integration [v2]
In-Reply-To: <hBgstPIzP2xKl_11ULTUGr2wagYOoquY6UVlwqlYLEM=.2e2548aa-94fa-4bff-82c0-ca7ff3d3961a@github.com>
References: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
 <hBgstPIzP2xKl_11ULTUGr2wagYOoquY6UVlwqlYLEM=.2e2548aa-94fa-4bff-82c0-ca7ff3d3961a@github.com>
Message-ID: <C8HrL1YulDlKTrjjDzhQBuRsngHozSVccBxZOzwC8EA=.7813b173-1705-48ac-8d9a-2aa062bbf51b@github.com>

On Thu, 21 Nov 2024 10:24:28 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

>> This PR remove usage of SecurityManager, doPrivileges, etc... from `java.logging` and `java.base/jdk.internal.logger`
>> 
>> Only notable hack - Logger.checkPermission() no longer checks permissions, but has been renamed into `ensureLogManagerInitialized()` in order to avoid disturbing the initialization sequence of Logger/LogManager.
>> 
>> I am not 100% sure this is still needed - but I remember we had some entanglement issues in the past that had been hard to solve, so it seemed prudent to keep the call:
>> 
>> 
>>     if (manager == null) {
>>         manager = LogManager.getLogManager();
>>     }
>> 
>> 
>> where `manager` is a private volatile field in Logger.
>> 
>> I also took the opportunity to remove the locking workaround that had been introduced to support Virtual Threads and revert to using synchronized in the Handler classes now that JEP 491 has been integrated.
>
> Daniel Fuchs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review feedback

This looks good to me.

-------------

Marked as reviewed by jpai (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22281#pullrequestreview-2451121259

From lancea at openjdk.org  Thu Nov 21 11:44:22 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 21 Nov 2024 11:44:22 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <_XR76BkIfBM5JPHDyC8Y23nuAQgGXJAXceT5opavZ_c=.ab19fa43-cb53-40d6-a392-f76dd701efad@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Marked as reviewed by lancea (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2451120906

From dl at openjdk.org  Thu Nov 21 11:53:27 2024
From: dl at openjdk.org (Doug Lea)
Date: Thu, 21 Nov 2024 11:53:27 GMT
Subject: Integrated: 8336707: Contention of ForkJoinPool grows when stealing
 works
In-Reply-To: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
References: <e1EdyE2tkK6UoPpxLB-RjrbDNCmJnoWqxoVTHI2IO4M=.40ddd351-f496-4a06-9e35-b220b3844632@github.com>
Message-ID: <z6btxVJMaEXYW9nuDIYSEUM-1IynE3htK0wGGxZfgxw=.01fb2b99-f17c-4204-8215-5be5c21f2ce7@github.com>

On Mon, 14 Oct 2024 20:58:43 GMT, Doug Lea <dl at openjdk.org> wrote:

> This addresses tendencies in previous update to increase fencing, scanning, and signalling that can increase contention, and slow down performance especially on ARM platforms. It also uses more ARM-friendly constructions to reduce overhead (leading to several changes that all of the same form),

This pull request has now been integrated.

Changeset: 18df6fd5
Author:    Doug Lea <dl at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/18df6fd5ba93c3c2d5965c072d482dcf7cbfc675
Stats:     525 lines in 2 files changed: 181 ins; 105 del; 239 mod

8336707: Contention of ForkJoinPool grows when stealing works

Reviewed-by: vklang

-------------

PR: https://git.openjdk.org/jdk/pull/21507

From bkilambi at openjdk.org  Thu Nov 21 11:55:24 2024
From: bkilambi at openjdk.org (Bhavana Kilambi)
Date: Thu, 21 Nov 2024 11:55:24 GMT
Subject: RFR: 8342103: C2 compiler support for Float16 type and associated
 operations
In-Reply-To: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
References: <luYocs-bxscpkaNWERBT4akSNe_1MCt3rfCmmX32p_Y=.f4dd97ba-8bd9-4b80-a643-d40d128fe43b@github.com>
Message-ID: <28lnx2GvWiVFGMw9LSjjwMSeUPNjvqVGpVVQd_WluGI=.f50647e4-0895-462f-9d12-2050a3368088@github.com>

On Mon, 14 Oct 2024 11:40:01 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> Hi All,
> 
> This patch adds C2 compiler support for various Float16 operations added by [PR#22128](https://github.com/openjdk/jdk/pull/22128)
> 
> Following is the summary of changes included with this patch:-
> 
> 1. Detection of various Float16 operations through inline expansion or pattern folding idealizations.
> 2. Float16 operations like add, sub, mul, div, max, and min are inferred through pattern folding idealization.
> 3. Float16 SQRT and FMA operation are inferred through inline expansion and their corresponding entry points are defined in the newly added Float16Math class.
>       -    These intrinsics receive unwrapped short arguments encoding IEEE 754 binary16 values.
> 5. New specialized IR nodes for Float16 operations, associated idealizations, and constant folding routines.
> 6. New Ideal type for constant and non-constant Float16 IR nodes. Please refer to [FAQs ](https://github.com/openjdk/jdk/pull/21490#issuecomment-2482867818)for more details.
> 7. Since Float16 uses short as its storage type, hence raw FP16 values are always loaded into general purpose register, but FP16 ISA instructions generally operate over floating point registers, therefore compiler injectes reinterpretation IR before and after Float16 operation nodes to move short value to floating point register and vice versa.
> 8. New idealization routines to optimize redundant reinterpretation chains. HF2S + S2HF = HF
> 6. Auto-vectorization of newly supported scalar operations.
> 7. X86 and AARCH64 backend implementation for all supported intrinsics.
> 9. Functional and Performance validation tests.
> 
> **Missing Pieces:-**
> **-  AARCH64 Backend.**
> 
> Kindly review and share your feedback.
> 
> Best Regards,
> Jatin

src/hotspot/share/opto/convertnode.cpp line 260:

> 258:       in(1)->in(1)->Opcode() == Op_ConvHF2F &&
> 259:       in(1)->in(2)->Opcode() == Op_ConvHF2F) {
> 260:     if (Matcher::match_rule_supported(in(1)->Opcode()) &&

Here `match_rule_supported()` is being called on floating point IR (AddHF etc) but it should be called on the half float IR (AddHF for ex). Maybe add another routine to return the opcode for half float IR and then check if it's supported?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21490#discussion_r1851914140

From dfuchs at openjdk.org  Thu Nov 21 11:57:22 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 11:57:22 GMT
Subject: Integrated: 8344235: Revisit SecurityManager usage in java.logging
 after JEP 486 and JEP 491 integration
In-Reply-To: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
References: <FU8hWPfMtUubf11tNim6n2D73ccNxzFiYQMWsW0eLt0=.e847482e-8042-42d3-a393-a7ef10a4dfba@github.com>
Message-ID: <dVyDz8KG4AZdG1i4hAKE3FCyeBOg49WeXZmaiS7WEXc=.11f9ed3a-1055-4809-8ee0-7762228e36df@github.com>

On Wed, 20 Nov 2024 19:39:58 GMT, Daniel Fuchs <dfuchs at openjdk.org> wrote:

> This PR remove usage of SecurityManager, doPrivileges, etc... from `java.logging` and `java.base/jdk.internal.logger`
> 
> Only notable hack - Logger.checkPermission() no longer checks permissions, but has been renamed into `ensureLogManagerInitialized()` in order to avoid disturbing the initialization sequence of Logger/LogManager.
> 
> I am not 100% sure this is still needed - but I remember we had some entanglement issues in the past that had been hard to solve, so it seemed prudent to keep the call:
> 
> 
>     if (manager == null) {
>         manager = LogManager.getLogManager();
>     }
> 
> 
> where `manager` is a private volatile field in Logger.
> 
> I also took the opportunity to remove the locking workaround that had been introduced to support Virtual Threads and revert to using synchronized in the Handler classes now that JEP 491 has been integrated.

This pull request has now been integrated.

Changeset: a62279ca
Author:    Daniel Fuchs <dfuchs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/a62279ca0a520fdf4bce77dec4cb06d4d573c109
Stats:     954 lines in 17 files changed: 47 ins; 748 del; 159 mod

8344235: Revisit SecurityManager usage in java.logging after JEP 486 and JEP 491 integration

Reviewed-by: jpai

-------------

PR: https://git.openjdk.org/jdk/pull/22281

From lancea at openjdk.org  Thu Nov 21 12:09:17 2024
From: lancea at openjdk.org (Lance Andersen)
Date: Thu, 21 Nov 2024 12:09:17 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v2]
In-Reply-To: <F0UOh57K-vnzYfmMdk-RxCCD-7WIkFWgRSmNU_ZKsVM=.2529c11c-1138-4b54-b973-0a93e37cbe34@github.com>
References: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
 <F0UOh57K-vnzYfmMdk-RxCCD-7WIkFWgRSmNU_ZKsVM=.2529c11c-1138-4b54-b973-0a93e37cbe34@github.com>
Message-ID: <qXrdu2VejjH9Sra5bQ4TjO_3luN_wCK7jKCYIrAdT50=.a070101d-0b4d-49be-aa16-bd43b07d8a07@github.com>

On Wed, 20 Nov 2024 21:03:33 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

>> Removed use of SecurityManager to check permissions.
>> Relaxed defensive copying of byte arrays (due to lack of SM)
>> 
>> Refresh of PR#22168 Including review comments made there.
>
> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Remove latent permission and checkPermission.

Looks good jai

-------------

Marked as reviewed by lancea (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22282#pullrequestreview-2451178328

From liach at openjdk.org  Thu Nov 21 13:04:20 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Nov 2024 13:04:20 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v4]
In-Reply-To: <JjINc3y25QXD_9-3aAiquEnbZXLmMIfXhtt7bFAx2qQ=.4cb957b9-0984-4c82-9057-d8788a7655ec@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
 <vqtslRu8ravM4UHJ31flMG0SNIx80GEtz6TOcLROWvU=.fa212cd1-002a-43a2-965d-744f413a9068@github.com>
 <JjINc3y25QXD_9-3aAiquEnbZXLmMIfXhtt7bFAx2qQ=.4cb957b9-0984-4c82-9057-d8788a7655ec@github.com>
Message-ID: <zB-bZCfmELjtL5GWLS-vkaJOYRfU5VWB5Tex250n-xM=.a02bd934-6611-4ad7-9d01-bf94a38b3b9f@github.com>

On Thu, 21 Nov 2024 10:52:56 GMT, Adam Sotona <asotona at openjdk.org> wrote:

>> Chen Liang has updated the pull request incrementally with four additional commits since the last revision:
>> 
>>  - typo
>>  - More cleanup
>>  - Remove a few confusions around bad modeling, some missing exceptions, also the labelless info models
>>  - Non-int constant values
>
> src/java.base/share/classes/java/lang/classfile/instruction/DiscontinuedInstruction.java line 69:
> 
>> 67:      * instruction model is written by a {@link CodeBuilder}.
>> 68:      * <p>
>> 69:      * Jump subroutine instructions push a {@link TypeKind##returnAddress
> 
> I don't think we have a TypeKind##returnAddress.

This links to the index tag on returnAddress.

> src/java.base/share/classes/java/lang/classfile/instruction/StoreInstruction.java line 76:
> 
>> 74:      * {@return the {@linkplain TypeKind##computational-type computational type}
>> 75:      * of the value to be stored}  The {@link TypeKind#REFERENCE reference}
>> 76:      * type store instructions also operate on the {@code returnAddress} type,
> 
> Where do we expose a TypeKind related to a return address?

We do not. This just notes astore can store jsr addresses (see jvms). This is intended to be similar to the array load/store boolean note.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1852021242
PR Review Comment: https://git.openjdk.org/jdk/pull/21625#discussion_r1852020112

From davidalayachew at gmail.com  Thu Nov 21 14:01:20 2024
From: davidalayachew at gmail.com (David Alayachew)
Date: Thu, 21 Nov 2024 09:01:20 -0500
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <MW4PR10MB57745275F5926E35597C6812FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
 <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
 <MW4PR10MB577405D464DA1241736F8AF6FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57745275F5926E35597C6812FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
Message-ID: <CAA9v-_PG6r7QxbRrq2F-wxsFPovRL6HQE8X_ag77AvSs2AVU5w@mail.gmail.com>

Thanks for the context Viktor. I think I got to see that breadth vs depth
threshold myself when work with danielaveryj on reddit. They explained
largely in the way that you did, and we experimented with batch sizes until
we found the cutoff point where things broke off.

But thanks again for the context. If you have more thoughts or you ever do
make a decision on this, I would love to know!

On Tue, Nov 19, 2024, 7:42?AM Viktor Klang <viktor.klang at oracle.com> wrote:

> Another thing which might add some detail:
>
> This isn't really about short-circuiting under parallelization but rather
> a trade-off between depth-first vs breadth-first processing.
>
> For sequential evaluation you typically want to perform depth-first
> processing since that means that you occupy ~constant space.
>
> For parallel evaluation you *need to* perform [some level of]
> breadth-first processing (since otherwise there is no parallelism). So you
> need to decide what the evaluation strategy will be and where the
> join/merge-points are. For some operations which are inherently
> encounter-ordered you can "place a bet" (think: findFirst() where if you
> have multiple candidates each found in different chunks, you only keep the
> one which has the "earliest" encounter order), but for others, like
> *foldLeft* each subsequent value depends on the previous.
>
> In the *foldLeft* case what Gatherers provide is ofSequential, which
> essentially instructs the processing that there's no use trying to
> parallelize this at all, so under parallel evaluation this stage needs to
> run sequentially?and that means that it must run to completion before
> downstream operations can continue, and by implication this also means that
> the output needs intermittent storage, so you are now in a breadth-first
> scenario.
>
> In my experience, parallel streams are better suited for CPU-bound
> workloads where operations are trivially parallelizable (i.e. no
> encounter-order dependencies). Importantly, it's common to need to have a
> rather large set of elements in the stream to have the overhead of
> parallelization win over sequential evaluation. The only way to know what
> makes sense is to benchmark using realistic workloads.
>
> Personally, I wouldn't be surprised if sequential streams plus the
> occasional Gatherers.mapConcurrent() covers > 90% of all Stream use-cases.
>
> As a side-note, it is important to remember that Java Streams are
> push-style streams. (Push-style vs Pull-style vs Push-Pull-style is a
> longer conversation, but all of these strategies come with trade-offs)
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> Viktor Klang <viktor.klang at oracle.com>
> *Sent:* Tuesday, 19 November 2024 13:19
> *To:* David Alayachew <davidalayachew at gmail.com>
> *Cc:* Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> Hi David,
>
> I've been thinking about this topic for a few days and haven't arrived at
> a satisfactory solution. Keep in mind that this "situation" has been in
> place ever since Streams were released, and perhaps Gatherers may be a
> catalyst to have it be more noticeable?I'll keep thinking about what could
> be done to make it more predictable (besides thinking about what
> rearrangements might make the situation go away).
>
> In general though?short-circuiting in combination with parallelization
> requires a lot of tuning to make sure that the cost of processing more data
> doesn't overtake the benefit of "exiting early".
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Thursday, 14 November 2024 23:45
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> Oh ok. So it truly is a toss-up depending on each implementation when and
> where this occurs.
>
> Ok, then as my final request, I think even informing the user that this
> CAN occur is worth doing. If nothing else, the user scouring the
> documentation for documentation of this behaviour will know that it is
> simply something that can occur. They don't need to know all the details.
> Simply give it a official term, describe the behaviour, tell that it is
> implementation specific on when this happens, but that it is only possible
> during parallelism. Even just knowing the verbiage to describe the problem
> will enable them to better communicate with each other on what they want vs
> what they get. That helps searchability, if nothing else.
>
> On Thu, Nov 14, 2024, 8:45?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> I see what you're saying, the problem is that it depends on the Stream
> implementation (given that Stream is an interface).
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* David Alayachew <davidalayachew at gmail.com>
> *Sent:* Thursday, 14 November 2024 12:36
> *To:* Viktor Klang <viktor.klang at oracle.com>
> *Cc:* Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <
> core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
>
> Then let me correct myself again, while simplifying -- I just want that
> detail, that certain combinations might lead to pre-fetching everything, to
> be documented on the stream api. Package level, or on the Stream interface
> itself, seems like a good spot.
>
> On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
>
> The issue here is that the operation cannot advertise this, as it depends
> on the combination of operations.
>
>
> Cheers,
> ?
>
>
> *Viktor Klang*
> Software Architect, Java Platform Group
> Oracle
> ------------------------------
> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of David
> Alayachew <davidalayachew at gmail.com>
> *Sent:* Wednesday, 13 November 2024 14:07
> *To:* Rob Spoor <openjdk at icemanx.nl>
> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> fetching too many elements
>
> That is a good point Rob.
>
> Then let me correct myself -- I think the terminal operations don't do a
> great job of advertising whether or not they pre-fetch everything when
> parallelism is activated. Collector fetches as needed. FindAny pre-fetches
> everything. I understand that later releases might change their behaviour,
> but I still want to document the current behaviour in the official javadocs
> so that we can limit undocumented tripping hazards.
>
>
> On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl> wrote:
>
> distinct() doesn't require everything to be pulled. It can push elements
> to the downstream as they come along for the first time. When
> downstream.push returns false the gatherer is done.
>
> As part of some experimentation I've implemented all intermediary
> operations using gatherers. Most of them are pretty straightforward and
> will stop integrating once the downstream starts rejecting elements
> (although some use Gatherer.ofSequential to keep it easy). I only found
> two exceptions that don't return the result of downstream.push:
>
> * mapMulti. The downstream.push is passed as the mapper which is a
> Consumer - the return value is ignored. With some more effort it's
> probably possible to capture any false return value and return that from
> the integrator, but I haven't tried that yet.
>
> * sorted. Obviously every element needs to be inspected.
>
>
> On 13/11/2024 00:37, David Alayachew wrote:
> > Oh sure, I expect something like distinct() to pull everything. In order
> to
> > know if something is distinct, you have to do some variant of "check
> > against everyone else". Whether that is holding all instances in memory
> or
> > their hashes, it's clear from a glance that you will need to look at
> > everything, and therefore, pre-fetching makes intuitive sense to me.
> >
> > I 100% did not expect terminal operations like findAny() or reduce() to
> > pull the whole data set. That was a complete whiplash for me. The method
> > findAny() advertises itself as a short-circuiting operation, so to find
> out
> > that it actually pulls the whole data set anyways was shocking.
> >
> > And that was my biggest pain point -- looking at the documentation, it is
> > not clear to me at all that methods like findAny() would pull in all data
> > upon becoming parallel().
> >
> > Do you think it would make sense to add documentation about this to the
> > javadocs for Stream/java.util.stream? Or maybe it is already there and I
> > misunderstood it (even after reading through it thoroughly over 5 times).
> >
> >
> > On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com>
> wrote:
> >
> >>> We are told how Streams can process unbounded data sets, but when it
> >> tries to do a findAny() with parallel(), it runs into an OOME because it
> >> fetched all the data ahead of time. In fact, almost of the terminal
> >> operations will hit an OOME in the exact same way if they are parallel
> and
> >> have a big enough data set. It's definitely not the end of the world,
> but
> >> it seems that I have to fit everything into a Collector and/or a
> Gatherer
> >> if I want to avoid pre-fetching everything.
> >>
> >> Yeah, I think it is important to distinguish "can process unbounded data
> >> sets" from "always able to process unbounded data sets".
> >>
> >> Some operations inherently need the end of the stream, so even something
> >> somple like: stream.distinct() or stream.sorted() can end up pulling in
> all
> >> data (which of course won't terminate).
> >>
> >> Fortunately, I think Gatherers can unlock much more situations where
> >> unbounded streams can be processed.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 15:08
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Oh woah. I certainly did not. Or rather, I had dismissed the idea as
> soon
> >> as I thought of it.
> >>
> >>
> >> I hand-waved away the idea because I thought that the method would turn
> >> the stream pipeline parallel, thus, recreating the same problem I
> currently
> >> have of parallelism causing all of the elements to be fetched ahead of
> >> time, causing an OOME.
> >>
> >>
> >> It did NOT occur to me that the pipeline would stay sequential, and just
> >> kick these off sequentially, but have them executing in parallel. I
> can't
> >> see why I came to that incorrect conclusion. I have read the javadocs of
> >> this method several times. Though, to be fair, I came to the same,
> >> incorrect conclusion about Collectors.groupingByConcurrent(), and it
> wasn't
> >> until someone pointed out what the documentation was actually saying
> that I
> >> realized it's true properties.
> >>
> >> Thanks. That definitely solves at least part of my problem. Obviously, I
> >> would prefer to write to S3 in parallel too, but at the very least, the
> >> calculation part is being done in parallel. And worst case scenario, I
> can
> >> be really bad and just do the write to S3 in the mapConcurrent, and then
> >> just return the metadata of each write, and just bundle that up with
> >> collect.
> >>
> >>
> >> And that's ignoring the fact that I can just use the workaround too.
> >>
> >>
> >> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
> >> from a performance perspective, but is rather unintuitive to me from a
> >> usability perspective. We are told how Streams can process unbounded
> data
> >> sets, but when it tries to do a findAny() with parallel(), it runs into
> an
> >> OOME because it fetched all the data ahead of time. In fact, almost of
> the
> >> terminal operations will hit an OOME in the exact same way if they are
> >> parallel and have a big enough data set. It's definitely not the end of
> the
> >> world, but it seems that I have to fit everything into a Collector
> and/or a
> >> Gatherer if I want to avoid pre-fetching everything.
> >>
> >> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Have you considered Gatherers.mapConcurrent(?)?
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Tuesday, 12 November 2024 01:53
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >> Good to know, ty vm.
> >>
> >> At the very least, I have this workaround. This will meet my needs for
> now.
> >>
> >> I guess my final question would be -- is this type of problem better
> >> suited to something besides parallel streams? Maybe an ExecutorService?
> >>
> >> Really, all I am doing is taking a jumbo file, splitting it into
> batches,
> >> and then doing some work on those batches. My IO speeds are pretty fast,
> >> and the compute work is non-trivial, so there is performance being left
> on
> >> the table if I give up parallelism. And I am in a position where
> completion
> >> time is very important to us.
> >>
> >> I just naturally assumed parallel streams were the right choice because
> >> the compute work is simple. A pure function that I can break out, and
> then
> >> call in a map. Once I do that, I just call forEach to write the batches
> >> back out to S3. Maybe I should look into a different part of the std lib
> >> instead because I am using the wrong tool for the job? My nose says
> >> ExecutorService, but I figure I should ask before I dive too deep in.
> >>
> >>
> >> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> You're most welcome!
> >>
> >> In a potential future where all intermediate operations are
> >> Gatherer-based, and all terminal operations are Collector-based, it
> would
> >> just work as expected. But with that said, I'm not sure it is
> practically
> >> achievable because some operations might not have the same
> >> performance-characteristics as before.
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* David Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 18:32
> >> *To:* Viktor Klang <viktor.klang at oracle.com>
> >> *Cc:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* [External] : Re: Question about Streams, Gatherers, and
> >> fetching too many elements
> >>
> >>
> >> Thanks for the workaround. It's running beautifully.
> >>
> >> Is there a future where this island concept is extended to the rest of
> >> streams? Tbh, I don't fully understand it.
> >>
> >> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com>
> >> wrote:
> >>
> >> Hi David,
> >>
> >> This is the effect of how parallel streams are implemented, where
> >> different stages, which are not representible as a join-less Spliterator
> >> are executed as a series of "islands" where the next isn't started until
> >> the former has completed.
> >>
> >> If you think about it, parallelization of a Stream works best when the
> >> entire data set can be split amongst a set of worker threads, and that
> sort
> >> of implies that you want eager pre-fetch of data, so if your dataset
> does
> >> not fit in memory, that is likely to lead to less desirable outcomes.
> >>
> >> What I was able to do for Gatherers is to implement "gather(?) +
> >> collect(?)"-fusion so any number of consecutive gather(?)-operations
> >> immediately followed by a collect(?) is run in the same "island".
> >>
> >> So with that said, you could try something like the following:
> >>
> >> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T>
> *each*) {
> >>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e),
> (*l*,
> >> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
> >> }
> >>
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .collect(forEach(eachList -> println(eachList.getFirst())));
> >>
> >>
> >> Cheers,
> >> ?
> >>
> >>
> >> *Viktor Klang*
> >> Software Architect, Java Platform Group
> >> Oracle
> >> ------------------------------
> >> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org> on behalf of
> David
> >> Alayachew <davidalayachew at gmail.com>
> >> *Sent:* Monday, 11 November 2024 14:52
> >> *To:* core-libs-dev <core-libs-dev at openjdk.org>
> >> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
> >> elements
> >>
> >> And just to avoid the obvious question, I can hold about 30 batches in
> >> memory before the Out of Memory error occurs. So this is not an issue
> of my
> >> batch size being too high.
> >>
> >> But just to confirm, I set the batch size to 1, and it still ran into an
> >> out of memory error. So I feel fairly confident saying that the
> Gatherer is
> >> trying to grab all available data before sending any of it downstream.
> >>
> >> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com
> >
> >> wrote:
> >>
> >> Hello Core Libs Dev Team,
> >>
> >> I was trying out Gatherers for a project at work, and ran into a rather
> >> sad scenario.
> >>
> >> I need to process a large file in batches. Each batch is small enough
> that
> >> I can hold it in memory, but I cannot hold the entire file (and thus,
> all
> >> of the batches) in memory at once.
> >>
> >> Looking at the Gatherers API, I saw windowFixed and thought that it
> would
> >> be a great match for my use case.
> >>
> >> However, when trying it out, I was disappointed to see that it ran out
> of
> >> memory very quickly. Here is my attempt at using it.
> >>
> >> stream
> >> .parallel()
> >> .unordered()
> >> .gather(Gatherers.windowFixed(BATCH_SIZE))
> >> .forEach(eachList -> println(eachList.getFirst()))
> >> ;
> >>
> >> As you can see, I am just splitting the file into batches, and printing
> >> out the first of each batch. This is purely for example's sake, of
> course.
> >> I had planned on building even more functionality on top of this, but I
> >> couldn't even get past this example.
> >>
> >> But anyways, not even a single one of them printed out. Which leads me
> to
> >> believe that it's pulling all of them in the Gatherer.
> >>
> >> I can get it to run successfully if I go sequentially, but not parallel.
> >> Parallel gives me that out of memory error.
> >>
> >> Is there any way for me to be able to have the Gatherer NOT pull in
> >> everything while still remaining parallel and unordered?
> >>
> >> Thank you for your time and help.
> >> David Alayachew
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241121/5749abac/attachment-0001.htm>

From mullan at openjdk.org  Thu Nov 21 14:03:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Nov 2024 14:03:37 GMT
Subject: RFR: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules [v2]
In-Reply-To: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
References: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
Message-ID: <BCiTRH5aN6hgKuVeQlwvId66zJON58p5DbPauMRnsUk=.35d1c064-88ea-4f78-86d0-bb525f832562@github.com>

> Now that JEP 486 has been integrated, `java.security.jgss` and `jdk.security.jgss` module dependencies on `System.getSecurityManager` and `AccessController.doPrivileged*` can be removed.
> 
> There is an undocumented property named "sun.security.krb5.autodeducerealm" that can probably be removed as it only affected behavior when an SM was enabled; however I have left the code that reads the property as-is (see sun/security/krb5/Realm.java) and have opened a separate issue to determine if it can be safely removed.

Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:

  Fix minor spacing issues.

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22256/files
  - new: https://git.openjdk.org/jdk/pull/22256/files/3896a5a0..6e58b1cf

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22256&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22256&range=00-01

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22256.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22256/head:pull/22256

PR: https://git.openjdk.org/jdk/pull/22256

From mullan at openjdk.org  Thu Nov 21 14:03:37 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Nov 2024 14:03:37 GMT
Subject: RFR: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules [v2]
In-Reply-To: <fn8SSbiw9rH3y-4y9ZPs3txugx2PilULGSMfFuVZmO8=.889837c1-c801-4b5e-bd9d-36205754e708@github.com>
References: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
 <fn8SSbiw9rH3y-4y9ZPs3txugx2PilULGSMfFuVZmO8=.889837c1-c801-4b5e-bd9d-36205754e708@github.com>
Message-ID: <ZmLBmkAD2KYDgEh4TKgd4SzU8Tl6XRU1qro84QyRqTk=.3bc756e6-584a-42fd-9c9d-ae84b20fe105@github.com>

On Thu, 21 Nov 2024 06:49:10 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Fix minor spacing issues.
>
> src/java.security.jgss/share/classes/sun/security/jgss/wrapper/SunNativeProvider.java line 115:
> 
>> 113:                  }
>> 114:                  Oid[] mechs = GSSLibStub.indicateMechs();
>> 115:                  HashMap<String,String> map = new HashMap<>();
> 
> Suggestion:
> 
>                  HashMap<String, String> map = new HashMap<>();

Fixed.

> src/java.security.jgss/share/classes/sun/security/krb5/KdcComm.java line 349:
> 
>> 347:                 DEBUG.println(">>> KDCCommunication: kdc=" + kdc
>> 348:                         + " " + proto + ":"
>> 349:                         +  port +  ", timeout="
> 
> Suggestion:
> 
>                         + port + ", timeout="

Fixed.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22256#discussion_r1852176744
PR Review Comment: https://git.openjdk.org/jdk/pull/22256#discussion_r1852176203

From pminborg at openjdk.org  Thu Nov 21 14:05:36 2024
From: pminborg at openjdk.org (Per Minborg)
Date: Thu, 21 Nov 2024 14:05:36 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v18]
In-Reply-To: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
Message-ID: <PNj_pTERSQA3SilPhErmt6ABFXOHMA_P5FZdMAg7-A4=.d2c2e579-e5fe-4aaf-ab1d-75d466456e42@github.com>

> This PR prevents sequence layout with padding to be used with the Linker.

Per Minborg has updated the pull request incrementally with one additional commit since the last revision:

  Fix checking of padding layouts

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21041/files
  - new: https://git.openjdk.org/jdk/pull/21041/files/28b3ad6d..0102e568

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=17
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21041&range=16-17

  Stats: 47 lines in 2 files changed: 41 ins; 0 del; 6 mod
  Patch: https://git.openjdk.org/jdk/pull/21041.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21041/head:pull/21041

PR: https://git.openjdk.org/jdk/pull/21041

From duke at openjdk.org  Thu Nov 21 14:09:20 2024
From: duke at openjdk.org (Vladimir Kozelkov)
Date: Thu, 21 Nov 2024 14:09:20 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v13]
In-Reply-To: <NLAtK0ceKW46Xw1LCxDwF-sOP5HGoxndTHeo0wX96pM=.a2b069ae-0f60-461b-b866-f7aba435a67c@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <e5AoQnwnl2vLztV4xKNjhSxusEDjOk7cCb_4RwVdVk4=.003bb6ac-f1eb-40ed-a25c-dae005cbc727@github.com>
 <LawuEa23JaOsGyhzvMd2OBz8CsLM9svCKcIRvPANiMk=.3f16cca7-2188-4cd5-8045-fdd19f5fb965@github.com>
 <USOSWDBf9RVnSHwWTBLioLapegwVCQDYJ6N25uFTOXk=.2601aac7-1bc3-45aa-bc36-30e01f900961@github.com>
 <iPnni7OibP4hXdq5zUM7SEtkugZcE4LnZHF3R_Gj6N8=.9a6df19f-80f8-4ca1-ba57-c63cffb75f7a@github.com>
 <NLAtK0ceKW46Xw1LCxDwF-sOP5HGoxndTHeo0wX96pM=.a2b069ae-0f60-461b-b866-f7aba435a67c@github.com>
Message-ID: <v5fXqY35hBfCW45FaTSigPxL1DzjiWMEEG4_7JARd70=.90290a7a-7eff-4203-9dd8-f1c403bbd55f@github.com>

On Wed, 20 Nov 2024 19:15:28 GMT, Jorn Vernee <jvernee at openjdk.org> wrote:

> Though, I'm still wondering if we don't want to reject that at the layout API level instead. i.e. have withByteAlignment throw an exception for PaddingLayout

I still don't understand why this wasn't done from the start, so I fully approve of this idea.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21041#issuecomment-2491299715

From alanb at openjdk.org  Thu Nov 21 14:11:17 2024
From: alanb at openjdk.org (Alan Bateman)
Date: Thu, 21 Nov 2024 14:11:17 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
 <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
 <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>
Message-ID: <pSpDf4uYfeFsIsbsL4_csdh_MfVLWpbkhj1m4n34IfY=.dbe2ced9-c1e5-4236-ae14-39a0e823cdb2@github.com>

On Wed, 20 Nov 2024 18:20:35 GMT, jyxzwd <duke at openjdk.org> wrote:

> Should I submit the modifications mentioned above to a commit, or should I conduct further testing first?

I think it would be good to add a test and add it to this PR with the updated patch.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2491304990

From viktor.klang at oracle.com  Thu Nov 21 14:12:41 2024
From: viktor.klang at oracle.com (Viktor Klang)
Date: Thu, 21 Nov 2024 14:12:41 +0000
Subject: [External] : Re: Question about Streams, Gatherers, and fetching
 too many elements
In-Reply-To: <CAA9v-_PG6r7QxbRrq2F-wxsFPovRL6HQE8X_ag77AvSs2AVU5w@mail.gmail.com>
References: <CAA9v-_NVkU=xRz7KLcjnEpe739_keB0cKH5tkQoVcTiad8xVNg@mail.gmail.com>
 <CAA9v-_MjdwSQmb5tgg-L+pVeGfK6+pOnAVqUp6CS3CfD69atqw@mail.gmail.com>
 <MW4PR10MB57742196514025279F13352EFF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_ONzqGAkHQVARKzm7E7AaEAAv06Rk81YruuXURbv7otQA@mail.gmail.com>
 <MW4PR10MB57747DEC290F5786A4B0D300FF582@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_MJXNutXd9GU4Nou+emcWLdpU_r4cVQTm2S9Y7KLiJFhA@mail.gmail.com>
 <MW4PR10MB577418DCEDED087296867CBBFF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Ovny2MLNU7yfFehmXvRqEDxLqSghrYpPLbfByHoJr=hg@mail.gmail.com>
 <MW4PR10MB577421E8749C47C75D1DA7F8FF592@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_NHh-YsJC3OdinOr8BvNJJr5O=1oHBOo5wJXjFtFS1x8A@mail.gmail.com>
 <ad8f21a4-78ec-4a7e-9702-495be814d7b0@icemanx.nl>
 <CAA9v-_NpZSWRef_v5whUEOWFB+ifAZYf_q3csEm34pUjYUT4dA@mail.gmail.com>
 <MW4PR10MB5774234C1C8A2C03D343FAE7FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pqv=mVXWfUEO-_P4EGatgnPTiPPdBYFBwQmgAO1ny-2w@mail.gmail.com>
 <MW4PR10MB57741CEA50E42C6841A524C9FF5B2@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_Pg1Fz5A=Nno+2PKCwYYgTnMpfj+ndSJwdOQJdnON_DZA@mail.gmail.com>
 <MW4PR10MB577405D464DA1241736F8AF6FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
 <MW4PR10MB57745275F5926E35597C6812FF202@MW4PR10MB5774.namprd10.prod.outlook.com>
 <CAA9v-_PG6r7QxbRrq2F-wxsFPovRL6HQE8X_ag77AvSs2AVU5w@mail.gmail.com>
Message-ID: <MW4PR10MB57747B32427B3AE5E21D2687FF222@MW4PR10MB5774.namprd10.prod.outlook.com>

Hi David,

I might respond to the Reddit thread later, I need to wrap some other tasks up first.

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com>
Sent: Thursday, 21 November 2024 15:01
To: Viktor Klang <viktor.klang at oracle.com>
Cc: Rob Spoor <openjdk at icemanx.nl>; core-libs-dev <core-libs-dev at openjdk.org>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Thanks for the context Viktor. I think I got to see that breadth vs depth threshold myself when work with danielaveryj on reddit. They explained largely in the way that you did, and we experimented with batch sizes until we found the cutoff point where things broke off.

But thanks again for the context. If you have more thoughts or you ever do make a decision on this, I would love to know!

On Tue, Nov 19, 2024, 7:42?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
Another thing which might add some detail:

This isn't really about short-circuiting under parallelization but rather a trade-off between depth-first vs breadth-first processing.

For sequential evaluation you typically want to perform depth-first processing since that means that you occupy ~constant space.

For parallel evaluation you need to perform [some level of] breadth-first processing (since otherwise there is no parallelism). So you need to decide what the evaluation strategy will be and where the join/merge-points are. For some operations which are inherently encounter-ordered you can "place a bet" (think: findFirst() where if you have multiple candidates each found in different chunks, you only keep the one which has the "earliest" encounter order), but for others, like foldLeft each subsequent value depends on the previous.

In the foldLeft case what Gatherers provide is ofSequential, which essentially instructs the processing that there's no use trying to parallelize this at all, so under parallel evaluation this stage needs to run sequentially?and that means that it must run to completion before downstream operations can continue, and by implication this also means that the output needs intermittent storage, so you are now in a breadth-first scenario.

In my experience, parallel streams are better suited for CPU-bound workloads where operations are trivially parallelizable (i.e. no encounter-order dependencies). Importantly, it's common to need to have a rather large set of elements in the stream to have the overhead of parallelization win over sequential evaluation. The only way to know what makes sense is to benchmark using realistic workloads.

Personally, I wouldn't be surprised if sequential streams plus the occasional Gatherers.mapConcurrent() covers > 90% of all Stream use-cases.

As a side-note, it is important to remember that Java Streams are push-style streams. (Push-style vs Pull-style vs Push-Pull-style is a longer conversation, but all of these strategies come with trade-offs)

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Sent: Tuesday, 19 November 2024 13:19
To: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Cc: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>; core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Hi David,

I've been thinking about this topic for a few days and haven't arrived at a satisfactory solution. Keep in mind that this "situation" has been in place ever since Streams were released, and perhaps Gatherers may be a catalyst to have it be more noticeable?I'll keep thinking about what could be done to make it more predictable (besides thinking about what rearrangements might make the situation go away).

In general though?short-circuiting in combination with parallelization requires a lot of tuning to make sure that the cost of processing more data doesn't overtake the benefit of "exiting early".


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Thursday, 14 November 2024 23:45
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>; core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

Oh ok. So it truly is a toss-up depending on each implementation when and where this occurs.

Ok, then as my final request, I think even informing the user that this CAN occur is worth doing. If nothing else, the user scouring the documentation for documentation of this behaviour will know that it is simply something that can occur. They don't need to know all the details. Simply give it a official term, describe the behaviour, tell that it is implementation specific on when this happens, but that it is only possible during parallelism. Even just knowing the verbiage to describe the problem will enable them to better communicate with each other on what they want vs what they get. That helps searchability, if nothing else.

On Thu, Nov 14, 2024, 8:45?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
I see what you're saying, the problem is that it depends on the Stream implementation (given that Stream is an interface).

Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Thursday, 14 November 2024 12:36
To: Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
Cc: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>; core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements


Then let me correct myself again, while simplifying -- I just want that detail, that certain combinations might lead to pre-fetching everything, to be documented on the stream api. Package level, or on the Stream interface itself, seems like a good spot.

On Thu, Nov 14, 2024, 4:22?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
The issue here is that the operation cannot advertise this, as it depends on the combination of operations.


Cheers,
?


Viktor Klang
Software Architect, Java Platform Group
Oracle
________________________________
From: core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
Sent: Wednesday, 13 November 2024 14:07
To: Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>>
Cc: core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
Subject: Re: [External] : Re: Question about Streams, Gatherers, and fetching too many elements

That is a good point Rob.

Then let me correct myself -- I think the terminal operations don't do a great job of advertising whether or not they pre-fetch everything when parallelism is activated. Collector fetches as needed. FindAny pre-fetches everything. I understand that later releases might change their behaviour, but I still want to document the current behaviour in the official javadocs so that we can limit undocumented tripping hazards.


On Wed, Nov 13, 2024, 7:07?AM Rob Spoor <openjdk at icemanx.nl<mailto:openjdk at icemanx.nl>> wrote:
distinct() doesn't require everything to be pulled. It can push elements
to the downstream as they come along for the first time. When
downstream.push returns false the gatherer is done.

As part of some experimentation I've implemented all intermediary
operations using gatherers. Most of them are pretty straightforward and
will stop integrating once the downstream starts rejecting elements
(although some use Gatherer.ofSequential to keep it easy). I only found
two exceptions that don't return the result of downstream.push:

* mapMulti. The downstream.push is passed as the mapper which is a
Consumer - the return value is ignored. With some more effort it's
probably possible to capture any false return value and return that from
the integrator, but I haven't tried that yet.

* sorted. Obviously every element needs to be inspected.


On 13/11/2024 00:37, David Alayachew wrote:
> Oh sure, I expect something like distinct() to pull everything. In order to
> know if something is distinct, you have to do some variant of "check
> against everyone else". Whether that is holding all instances in memory or
> their hashes, it's clear from a glance that you will need to look at
> everything, and therefore, pre-fetching makes intuitive sense to me.
>
> I 100% did not expect terminal operations like findAny() or reduce() to
> pull the whole data set. That was a complete whiplash for me. The method
> findAny() advertises itself as a short-circuiting operation, so to find out
> that it actually pulls the whole data set anyways was shocking.
>
> And that was my biggest pain point -- looking at the documentation, it is
> not clear to me at all that methods like findAny() would pull in all data
> upon becoming parallel().
>
> Do you think it would make sense to add documentation about this to the
> javadocs for Stream/java.util.stream? Or maybe it is already there and I
> misunderstood it (even after reading through it thoroughly over 5 times).
>
>
> On Tue, Nov 12, 2024, 10:06?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>> wrote:
>
>>> We are told how Streams can process unbounded data sets, but when it
>> tries to do a findAny() with parallel(), it runs into an OOME because it
>> fetched all the data ahead of time. In fact, almost of the terminal
>> operations will hit an OOME in the exact same way if they are parallel and
>> have a big enough data set. It's definitely not the end of the world, but
>> it seems that I have to fit everything into a Collector and/or a Gatherer
>> if I want to avoid pre-fetching everything.
>>
>> Yeah, I think it is important to distinguish "can process unbounded data
>> sets" from "always able to process unbounded data sets".
>>
>> Some operations inherently need the end of the stream, so even something
>> somple like: stream.distinct() or stream.sorted() can end up pulling in all
>> data (which of course won't terminate).
>>
>> Fortunately, I think Gatherers can unlock much more situations where
>> unbounded streams can be processed.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 15:08
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Oh woah. I certainly did not. Or rather, I had dismissed the idea as soon
>> as I thought of it.
>>
>>
>> I hand-waved away the idea because I thought that the method would turn
>> the stream pipeline parallel, thus, recreating the same problem I currently
>> have of parallelism causing all of the elements to be fetched ahead of
>> time, causing an OOME.
>>
>>
>> It did NOT occur to me that the pipeline would stay sequential, and just
>> kick these off sequentially, but have them executing in parallel. I can't
>> see why I came to that incorrect conclusion. I have read the javadocs of
>> this method several times. Though, to be fair, I came to the same,
>> incorrect conclusion about Collectors.groupingByConcurrent(), and it wasn't
>> until someone pointed out what the documentation was actually saying that I
>> realized it's true properties.
>>
>> Thanks. That definitely solves at least part of my problem. Obviously, I
>> would prefer to write to S3 in parallel too, but at the very least, the
>> calculation part is being done in parallel. And worst case scenario, I can
>> be really bad and just do the write to S3 in the mapConcurrent, and then
>> just return the metadata of each write, and just bundle that up with
>> collect.
>>
>>
>> And that's ignoring the fact that I can just use the workaround too.
>>
>>
>> Yeah, the whole "pre-fetch all the data ahead of time" makes sense to me
>> from a performance perspective, but is rather unintuitive to me from a
>> usability perspective. We are told how Streams can process unbounded data
>> sets, but when it tries to do a findAny() with parallel(), it runs into an
>> OOME because it fetched all the data ahead of time. In fact, almost of the
>> terminal operations will hit an OOME in the exact same way if they are
>> parallel and have a big enough data set. It's definitely not the end of the
>> world, but it seems that I have to fit everything into a Collector and/or a
>> Gatherer if I want to avoid pre-fetching everything.
>>
>> On Tue, Nov 12, 2024, 6:36?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Have you considered Gatherers.mapConcurrent(?)?
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Tuesday, 12 November 2024 01:53
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>> Good to know, ty vm.
>>
>> At the very least, I have this workaround. This will meet my needs for now.
>>
>> I guess my final question would be -- is this type of problem better
>> suited to something besides parallel streams? Maybe an ExecutorService?
>>
>> Really, all I am doing is taking a jumbo file, splitting it into batches,
>> and then doing some work on those batches. My IO speeds are pretty fast,
>> and the compute work is non-trivial, so there is performance being left on
>> the table if I give up parallelism. And I am in a position where completion
>> time is very important to us.
>>
>> I just naturally assumed parallel streams were the right choice because
>> the compute work is simple. A pure function that I can break out, and then
>> call in a map. Once I do that, I just call forEach to write the batches
>> back out to S3. Maybe I should look into a different part of the std lib
>> instead because I am using the wrong tool for the job? My nose says
>> ExecutorService, but I figure I should ask before I dive too deep in.
>>
>>
>> On Mon, Nov 11, 2024, 2:34?PM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> You're most welcome!
>>
>> In a potential future where all intermediate operations are
>> Gatherer-based, and all terminal operations are Collector-based, it would
>> just work as expected. But with that said, I'm not sure it is practically
>> achievable because some operations might not have the same
>> performance-characteristics as before.
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 18:32
>> *To:* Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> *Cc:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* [External] : Re: Question about Streams, Gatherers, and
>> fetching too many elements
>>
>>
>> Thanks for the workaround. It's running beautifully.
>>
>> Is there a future where this island concept is extended to the rest of
>> streams? Tbh, I don't fully understand it.
>>
>> On Mon, Nov 11, 2024, 9:59?AM Viktor Klang <viktor.klang at oracle.com<mailto:viktor.klang at oracle.com>>
>> wrote:
>>
>> Hi David,
>>
>> This is the effect of how parallel streams are implemented, where
>> different stages, which are not representible as a join-less Spliterator
>> are executed as a series of "islands" where the next isn't started until
>> the former has completed.
>>
>> If you think about it, parallelization of a Stream works best when the
>> entire data set can be split amongst a set of worker threads, and that sort
>> of implies that you want eager pre-fetch of data, so if your dataset does
>> not fit in memory, that is likely to lead to less desirable outcomes.
>>
>> What I was able to do for Gatherers is to implement "gather(?) +
>> collect(?)"-fusion so any number of consecutive gather(?)-operations
>> immediately followed by a collect(?) is run in the same "island".
>>
>> So with that said, you could try something like the following:
>>
>> static <T> Collector<T, ?, Void> *forEach*(Consumer<? *super* T> *each*) {
>>      *return* Collector.of(() -> null, (*v*, *e*) -> each.accept(e), (*l*,
>> *r*) -> l, (*v*) -> null, Collector.Characteristics.IDENTITY_FINISH);
>> }
>>
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .collect(forEach(eachList -> println(eachList.getFirst())));
>>
>>
>> Cheers,
>> ?
>>
>>
>> *Viktor Klang*
>> Software Architect, Java Platform Group
>> Oracle
>> ------------------------------
>> *From:* core-libs-dev <core-libs-dev-retn at openjdk.org<mailto:core-libs-dev-retn at openjdk.org>> on behalf of David
>> Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> *Sent:* Monday, 11 November 2024 14:52
>> *To:* core-libs-dev <core-libs-dev at openjdk.org<mailto:core-libs-dev at openjdk.org>>
>> *Subject:* Re: Question about Streams, Gatherers, and fetching too many
>> elements
>>
>> And just to avoid the obvious question, I can hold about 30 batches in
>> memory before the Out of Memory error occurs. So this is not an issue of my
>> batch size being too high.
>>
>> But just to confirm, I set the batch size to 1, and it still ran into an
>> out of memory error. So I feel fairly confident saying that the Gatherer is
>> trying to grab all available data before sending any of it downstream.
>>
>> On Mon, Nov 11, 2024, 8:46?AM David Alayachew <davidalayachew at gmail.com<mailto:davidalayachew at gmail.com>>
>> wrote:
>>
>> Hello Core Libs Dev Team,
>>
>> I was trying out Gatherers for a project at work, and ran into a rather
>> sad scenario.
>>
>> I need to process a large file in batches. Each batch is small enough that
>> I can hold it in memory, but I cannot hold the entire file (and thus, all
>> of the batches) in memory at once.
>>
>> Looking at the Gatherers API, I saw windowFixed and thought that it would
>> be a great match for my use case.
>>
>> However, when trying it out, I was disappointed to see that it ran out of
>> memory very quickly. Here is my attempt at using it.
>>
>> stream
>> .parallel()
>> .unordered()
>> .gather(Gatherers.windowFixed(BATCH_SIZE))
>> .forEach(eachList -> println(eachList.getFirst()))
>> ;
>>
>> As you can see, I am just splitting the file into batches, and printing
>> out the first of each batch. This is purely for example's sake, of course.
>> I had planned on building even more functionality on top of this, but I
>> couldn't even get past this example.
>>
>> But anyways, not even a single one of them printed out. Which leads me to
>> believe that it's pulling all of them in the Gatherer.
>>
>> I can get it to run successfully if I go sequentially, but not parallel.
>> Parallel gives me that out of memory error.
>>
>> Is there any way for me to be able to have the Gatherer NOT pull in
>> everything while still remaining parallel and unordered?
>>
>> Thank you for your time and help.
>> David Alayachew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.openjdk.org/pipermail/core-libs-dev/attachments/20241121/1f0a0961/attachment-0001.htm>

From duke at openjdk.org  Thu Nov 21 14:23:27 2024
From: duke at openjdk.org (jyxzwd)
Date: Thu, 21 Nov 2024 14:23:27 GMT
Subject: RFR: 8331467: ImageReaderFactory can cause a
 ClassNotFoundException if the default FileSystemProvider is not the
 system-default provider [v2]
In-Reply-To: <pSpDf4uYfeFsIsbsL4_csdh_MfVLWpbkhj1m4n34IfY=.dbe2ced9-c1e5-4236-ae14-39a0e823cdb2@github.com>
References: <xJEmDjdqfk427F1-nc8KmO_C0UAZlkayz0EuPQ1wi14=.75a3242c-6256-4690-8fbb-9c8192f4ab2c@github.com>
 <WA2nhWXjxfV7-3NV6kblgETW9KXspsVBhhXjolhdn0E=.233e0078-b420-4428-bafe-194ae0603737@github.com>
 <8ykg-3hOKKZIsb1Q41dYDoAU-I4LBMT1gXobLZwL4ao=.ab2df9eb-d0f2-4902-8da3-d9dbd374c6dc@github.com>
 <HKRyYhPPL2CW5YWoiy4-YiOum3v0w_mFfgiiQwOAdlI=.b37bb196-01c2-42a4-bdaf-af254a67f0bd@github.com>
 <hCMhwgzXcc4qAH_gm7Kk8gi8dmdFZVKO-qAViG6SN0Q=.4ffbe1b8-75f0-48f1-a33c-69ac3c705836@github.com>
 <RLPGQ3q6Z14YpOlxlJZ8KK1HbFJvuMZgFFBJ1yRD6mI=.03881c9d-45d3-4c72-87d7-e9544d086545@github.com>
 <pSpDf4uYfeFsIsbsL4_csdh_MfVLWpbkhj1m4n34IfY=.dbe2ced9-c1e5-4236-ae14-39a0e823cdb2@github.com>
Message-ID: <jLjkZsfD1mwqmm-ZBmAiV3qIYradwy487DEhOUs0uPE=.956370a5-dada-44ff-942b-68ca8dc3f8af@github.com>

On Thu, 21 Nov 2024 14:08:33 GMT, Alan Bateman <alanb at openjdk.org> wrote:

> > Should I submit the modifications mentioned above to a commit, or should I conduct further testing first?
> 
> I think it would be good to add a test and add it to this PR with the updated patch.

ok,I will do this later.Thank you for your guidance.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21997#issuecomment-2491343078

From rriggs at openjdk.org  Thu Nov 21 15:09:17 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Nov 2024 15:09:17 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v5]
In-Reply-To: <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
Message-ID: <WvkafGhvrlNYhp-lqO_HG9-MrZ8CLCu-QILnrHdkkNw=.d0dc8356-22cb-4119-99e8-df31ec22a050@github.com>

On Wed, 20 Nov 2024 22:43:44 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.
>
> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
> 
>   indentation fixes

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 115:

> 113:         userRootDir =
> 114:               new File(System.getProperty("java.util.prefs.userRoot",
> 115:               System.getProperty("user.home")), ".java/.userPrefs");

This expression would be more readable if the 2nd line was indented.

src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 451:

> 449:         // Add shutdown hook to flush cached prefs on normal termination
> 450:         Runtime.getRuntime().addShutdownHook(
> 451:             new Thread(null, null, "Sync Timer Thread", 0, false) {

Future work, use a Virtual thread for this.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1852307160
PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1852315551

From dfuchs at openjdk.org  Thu Nov 21 15:18:16 2024
From: dfuchs at openjdk.org (Daniel Fuchs)
Date: Thu, 21 Nov 2024 15:18:16 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <We3p12lva2kkGDg1yrVFjgNTRnB3mR5XI9rbMM4VTv0=.262b6473-bfaa-4f32-b720-94c1e0f56b0f@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Looks good.

-------------

Marked as reviewed by dfuchs (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2451805562

From duke at openjdk.org  Thu Nov 21 15:27:23 2024
From: duke at openjdk.org (Abdelhak Zaaim)
Date: Thu, 21 Nov 2024 15:27:23 GMT
Subject: RFR: 8344659: Some uses of GetPropertyAction were not removed from
 java.io and java.nio [v2]
In-Reply-To: <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
 <VZMGOQSba_sgiRMzwSVVunr5HcKRl3vxOhtHYRBuOSI=.1d30b26b-2e52-4cc3-a7ae-82686fe36032@github.com>
Message-ID: <wGHKfu2oWdzPQbGwTiuCNYADYhxCw7nPBNuxecHiPxs=.e345b4d4-abda-42f0-a98f-79b1981e4194@github.com>

On Thu, 21 Nov 2024 01:45:56 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

>> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.
>
> Brian Burkhalter has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8344659: System.getProperty("sun.jnu.encoding") -> StaticProperty.jnuEncoding()

Marked as reviewed by abdelhak-zaaim at github.com (no known OpenJDK username).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22285#pullrequestreview-2451829858

From liach at openjdk.org  Thu Nov 21 16:13:55 2024
From: liach at openjdk.org (Chen Liang)
Date: Thu, 21 Nov 2024 16:13:55 GMT
Subject: RFR: 8342469: Improve API documentation for
 java.lang.classfile.instruction [v5]
In-Reply-To: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
References: <RzBr3VcahRG7VFQYHsQVQtzDOr2DGmVP5kKEXy26T0M=.7a9f0a51-5637-440e-a1de-a7fe22648ccb@github.com>
Message-ID: <XBPTh3tUcHLzX7d_pFPuLsI31LHZ1-fhif_fAol2Jfw=.547fc32c-f944-46ab-ac27-b989c6f01f57@github.com>

> Improve the documentation for classfile instructions. Includes links to all opcodes, usage notes for instructions, and other various fixes.
> 
> API Diff: https://cr.openjdk.org/~liach/apidiff/cf-instr/java.base/module-summary.html
> Javadoc: https://cr.openjdk.org/~liach/javadoc/cf-instr/java.base/java/lang/classfile/instruction/package-summary.html
> 
> Please review the associated CSR as well.

Chen Liang has updated the pull request incrementally with one additional commit since the last revision:

  Leftover problems

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/21625/files
  - new: https://git.openjdk.org/jdk/pull/21625/files/2dab7a2f..56683d8f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=21625&range=04
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=21625&range=03-04

  Stats: 2 lines in 2 files changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/21625.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/21625/head:pull/21625

PR: https://git.openjdk.org/jdk/pull/21625

From bpb at openjdk.org  Thu Nov 21 16:21:22 2024
From: bpb at openjdk.org (Brian Burkhalter)
Date: Thu, 21 Nov 2024 16:21:22 GMT
Subject: Integrated: 8344659: Some uses of GetPropertyAction were not removed
 from java.io and java.nio
In-Reply-To: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
References: <kM2Vq777Q755cqvJEMtV5PErcsjsf1c5nbLLjPtQS5k=.d6b1fdfd-a5ff-4c19-b29c-8b77cf3de5ac@github.com>
Message-ID: <xQpgV01vjtcG-eeXEUP7dRRMxRkMXY9dQ0BHz3Z-72I=.6d7798b8-a359-43b4-8bce-09032955cf93@github.com>

On Wed, 20 Nov 2024 22:36:12 GMT, Brian Burkhalter <bpb at openjdk.org> wrote:

> Remove some occurrences of `GetPropertyAction` overlooked in #22219 and #22132.

This pull request has now been integrated.

Changeset: 87be63f8
Author:    Brian Burkhalter <bpb at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/87be63f85dbbfd8695817a913ef2b2ae5b0d78e9
Stats:     25 lines in 9 files changed: 0 ins; 8 del; 17 mod

8344659: Some uses of GetPropertyAction were not removed from java.io and java.nio

Reviewed-by: lancea, rriggs, iris, dfuchs

-------------

PR: https://git.openjdk.org/jdk/pull/22285

From asemenyuk at openjdk.org  Thu Nov 21 16:41:01 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 21 Nov 2024 16:41:01 GMT
Subject: RFR: 8344275: tools/jpackage/windows/Win8301247Test.java fails on
 localized Windows platform [v5]
In-Reply-To: <VsLU2J92-1_RSmWIRDnAoqA2vOzM5xIT_hA1pxGXuNc=.0cff32d8-a082-404a-a853-c6e252ca4c8f@github.com>
References: <mVNk5MKzArQOFFKi-KT7shuTQy7SNNBF35R6BHFgYzM=.ed21edbe-9745-4a6c-8ba9-8899df33f09d@github.com>
 <VsLU2J92-1_RSmWIRDnAoqA2vOzM5xIT_hA1pxGXuNc=.0cff32d8-a082-404a-a853-c6e252ca4c8f@github.com>
Message-ID: <HZSYT5ag3lRO7O8X2N24Z_KrTihtYNOI-wKhOK4GmA8=.6c6e956a-b962-4cd6-9bf4-2f9e6b2ae20d@github.com>

On Thu, 21 Nov 2024 04:32:50 GMT, Taizo Kurashige <duke at openjdk.org> wrote:

>> To resolve tools/jpackage/windows/Win8301247Test.java failure, I made "wmic" executed with "chcp 437". This ensures that the English message "No Instance(s) Available." is output on localized windows platforms.
>> 
>> I have referred to the following for how to use chcp:
>> ?chcp | Microsoft Learn at https://learn.microsoft.com/en-us/windows-server/administration/windows-commands/chcp
>> ?Code Page Identifiers - Win32 apps | Microsoft Learn at https://learn.microsoft.com/en-us/windows/win32/intl/code-page-identifiers
>> 
>> After fix, I ran tools/jpackage tests importing jdk.jpackage.test.Executor or jdk.jpackage.test.WindowsHelper.killAppLauncherProcess on Windows Server 2019 (Japanese and English locales). I confirmed that they pass.
>> 
>> Thanks
>
> Taizo Kurashige has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 15 commits:
> 
>  - Fix conflict
>  - Fix about size of cmdline
>  - Fix indent
>  - Merge branch 'fix_Win8301247Test_bug' of https://github.com/kurashige23/jdk into fix_Win8301247Test_bug
>  - Merge branch 'openjdk:master' into fix_Win8301247Test_bug
>  - Chenge code page from 65001 to 437
>  - Fix how to execute chcp command
>  - Change setWinEnableUTF8 to setWinRunWithEnglishOutput
>  - Suppress the output of chcp command
>  - Fix comment
>  - ... and 5 more: https://git.openjdk.org/jdk/compare/a01aa220...f013d9fb

Marked as reviewed by asemenyuk (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22142#pullrequestreview-2452047639

From hannesw at openjdk.org  Thu Nov 21 17:17:14 2024
From: hannesw at openjdk.org (Hannes =?UTF-8?B?V2FsbG7DtmZlcg==?=)
Date: Thu, 21 Nov 2024 17:17:14 GMT
Subject: RFR: 8343598: Since Checker can mark some preview elements as new
 even if bytecode reference is identical
In-Reply-To: <_ynHDCQaQ6MOs0P_Tr8DdDke4j6jmokZFHin56WS2vQ=.1a6888b9-38e8-45fc-88ac-e54abfcc72cf@github.com>
References: <_ynHDCQaQ6MOs0P_Tr8DdDke4j6jmokZFHin56WS2vQ=.1a6888b9-38e8-45fc-88ac-e54abfcc72cf@github.com>
Message-ID: <_T499BPwZ-AAJ1PTNNcz3O7VFrb1rWE_IAERqbGO9GU=.31e6a359-69b4-43f4-a68e-c641297d6acf@github.com>

On Mon, 18 Nov 2024 17:06:03 GMT, Nizar Benalla <nbenalla at openjdk.org> wrote:

> Can I get a review for this test only change to the Since Checker?
> 
> I drop the distinction between classes and interfaces when generating ids and use a generic name "class" to describe both, as to not consider classes that get converted to interfaces (and vice versa) as new API (Something that may happen to APIs in preview).
> 
> TIA.

Looks good.

-------------

Marked as reviewed by hannesw (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22213#pullrequestreview-2452153761

From aph at openjdk.org  Thu Nov 21 17:26:26 2024
From: aph at openjdk.org (Andrew Haley)
Date: Thu, 21 Nov 2024 17:26:26 GMT
Subject: RFR: 8339916: AIOOBE due to Math.abs(Integer.MIN_VALUE) in tests
Message-ID: <homWspYkM-vp63SYt6Gwwuy9Vc3rxhVD6v0W83nW91c=.aed07065-c38d-4e41-b503-08411a7efbad@github.com>

Test bug.

Another bug caused by the result of `Math.abs()` being negative. I also tried `floorMod()`, which would have been cleaner, but it increased the runtime of this extremely time-sensitive benchmark.

-------------

Commit messages:
 - Fix integer overflow in abs()

Changes: https://git.openjdk.org/jdk/pull/22297/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22297&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8339916
  Stats: 2 lines in 1 file changed: 0 ins; 0 del; 2 mod
  Patch: https://git.openjdk.org/jdk/pull/22297.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22297/head:pull/22297

PR: https://git.openjdk.org/jdk/pull/22297

From jvernee at openjdk.org  Thu Nov 21 17:34:25 2024
From: jvernee at openjdk.org (Jorn Vernee)
Date: Thu, 21 Nov 2024 17:34:25 GMT
Subject: RFR: 8340205: Native linker allows MemoryLayout consisting of only
 PaddingLayout [v18]
In-Reply-To: <PNj_pTERSQA3SilPhErmt6ABFXOHMA_P5FZdMAg7-A4=.d2c2e579-e5fe-4aaf-ab1d-75d466456e42@github.com>
References: <Ow397n3PelN9_9FFNu04zS4OYfd17XHQXfegnjCJ07I=.7e8fa821-a35b-40f5-9712-3fb7c6396264@github.com>
 <PNj_pTERSQA3SilPhErmt6ABFXOHMA_P5FZdMAg7-A4=.d2c2e579-e5fe-4aaf-ab1d-75d466456e42@github.com>
Message-ID: <MhCk9LgzPuW_-POwVznrO19SzSQJTFDXK771VoUTVwA=.a90805f5-494b-47e5-acb5-2a6fd5c27ecc@github.com>

On Thu, 21 Nov 2024 14:05:36 GMT, Per Minborg <pminborg at openjdk.org> wrote:

>> This PR prevents sequence layout with padding to be used with the Linker.
>
> Per Minborg has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix checking of padding layouts

I think the latest version looks good. Thanks for sticking through the lengthy review process.

I think we can address the issue of padding alignment separately.

-------------

Marked as reviewed by jvernee (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/21041#pullrequestreview-2452192256

From vaivanov at openjdk.org  Thu Nov 21 17:37:29 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 21 Nov 2024 17:37:29 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v3]
In-Reply-To: <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
 <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
Message-ID: <_UtOzTfP-0389lqszrtdseSk_Gz-vWFMp5AEv5f77yU=.00e24dee-efad-4ca7-b514-96eb6e3a0f5b@github.com>

On Thu, 7 Nov 2024 18:30:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
>> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
>> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
>> Unit tests was not affected:
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp                                     516   516     0     0
>>    jtreg:test/jdk/javax/xml                             70    70     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> The tier1 is OK too.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317542: Specjvm::xml have scalability issue for high vCPU numbers

Thanks for your review!

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2491861665

From duke at openjdk.org  Thu Nov 21 17:37:29 2024
From: duke at openjdk.org (duke)
Date: Thu, 21 Nov 2024 17:37:29 GMT
Subject: RFR: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers [v3]
In-Reply-To: <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
 <he1I7R9Hx9kLUclFRF3S2j0udGXkg640UsGUR06sLT4=.816acb8d-71a8-4b7e-ad11-1e34f923a7ac@github.com>
Message-ID: <Rm2Cry-Ji6q9uEUK6YOMfIjQyZ-_ugegQ5DIVF3GvoM=.9a03809d-4998-4392-a196-d5f2e58ff4b9@github.com>

On Thu, 7 Nov 2024 18:30:22 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

>> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
>> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
>> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
>> Unit tests was not affected:
>> Test summary
>> ==============================
>>    TEST                                              TOTAL  PASS  FAIL ERROR
>>    jtreg:test/jaxp                                     516   516     0     0
>>    jtreg:test/jdk/javax/xml                             70    70     0     0
>> ==============================
>> TEST SUCCESS
>> 
>> The tier1 is OK too.
>
> Vladimir Ivanov has updated the pull request incrementally with one additional commit since the last revision:
> 
>   8317542: Specjvm::xml have scalability issue for high vCPU numbers

@IvaVladimir 
Your change (at version d9da6501dba27581e6592113efded011c5244b3e) is now ready to be sponsored by a Committer.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/21815#issuecomment-2491864620

From ascarpino at openjdk.org  Thu Nov 21 17:38:17 2024
From: ascarpino at openjdk.org (Anthony Scarpino)
Date: Thu, 21 Nov 2024 17:38:17 GMT
Subject: RFR: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules [v2]
In-Reply-To: <BCiTRH5aN6hgKuVeQlwvId66zJON58p5DbPauMRnsUk=.35d1c064-88ea-4f78-86d0-bb525f832562@github.com>
References: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
 <BCiTRH5aN6hgKuVeQlwvId66zJON58p5DbPauMRnsUk=.35d1c064-88ea-4f78-86d0-bb525f832562@github.com>
Message-ID: <w6nPhpHlJxu5z4ueH-mBD3dLl9GFKqWu1fE9aIOC7_Q=.d8234f7f-2634-4ac5-a3b5-1416f3ee36bd@github.com>

On Thu, 21 Nov 2024 14:03:37 GMT, Sean Mullan <mullan at openjdk.org> wrote:

>> Now that JEP 486 has been integrated, `java.security.jgss` and `jdk.security.jgss` module dependencies on `System.getSecurityManager` and `AccessController.doPrivileged*` can be removed.
>> 
>> There is an undocumented property named "sun.security.krb5.autodeducerealm" that can probably be removed as it only affected behavior when an SM was enabled; however I have left the code that reads the property as-is (see sun/security/krb5/Realm.java) and have opened a separate issue to determine if it can be safely removed.
>
> Sean Mullan has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Fix minor spacing issues.

Marked as reviewed by ascarpino (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/22256#pullrequestreview-2452201371

From mullan at openjdk.org  Thu Nov 21 17:48:29 2024
From: mullan at openjdk.org (Sean Mullan)
Date: Thu, 21 Nov 2024 17:48:29 GMT
Subject: Integrated: 8344248: Remove Security Manager dependencies from
 java.security.jgss and jdk.security.jgss modules
In-Reply-To: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
References: <ND6k8VNf389lNb3cPV3l6i7_G9Tb998-Rk8cIazvALs=.cebc265d-9b28-40b2-822e-4e9c28fa48fe@github.com>
Message-ID: <YG3nk3TY-JdTxxUxVLbHEQGzDs4ZndyAKqoenr14jC8=.f7026d09-d594-4e16-a1dd-ae3a908f9a36@github.com>

On Tue, 19 Nov 2024 20:43:25 GMT, Sean Mullan <mullan at openjdk.org> wrote:

> Now that JEP 486 has been integrated, `java.security.jgss` and `jdk.security.jgss` module dependencies on `System.getSecurityManager` and `AccessController.doPrivileged*` can be removed.
> 
> There is an undocumented property named "sun.security.krb5.autodeducerealm" that can probably be removed as it only affected behavior when an SM was enabled; however I have left the code that reads the property as-is (see sun/security/krb5/Realm.java) and have opened a separate issue to determine if it can be safely removed.

This pull request has now been integrated.

Changeset: 6113fa75
Author:    Sean Mullan <mullan at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/6113fa75035440aa211c9df291c02dc9d0d40b4b
Stats:     876 lines in 42 files changed: 23 ins; 589 del; 264 mod

8344248: Remove Security Manager dependencies from java.security.jgss and jdk.security.jgss modules

Reviewed-by: ascarpino

-------------

PR: https://git.openjdk.org/jdk/pull/22256

From bchristi at openjdk.org  Thu Nov 21 17:56:18 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 21 Nov 2024 17:56:18 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <DJyCJZwSTn5kYnP3BrOsYvklgxa82tKD1IGgLw5IWmo=.b50e7d38-4829-49fa-bbe4-bbb3327efbae@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
 <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>
 <DJyCJZwSTn5kYnP3BrOsYvklgxa82tKD1IGgLw5IWmo=.b50e7d38-4829-49fa-bbe4-bbb3327efbae@github.com>
Message-ID: <Kr-Nu7aIe-XMXUk7z-bcHLgETmFTydVL0Dhd-BEAk-c=.1057b873-0680-4712-acef-42798fad4114@github.com>

On Thu, 21 Nov 2024 07:11:00 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> test/micro/org/openjdk/bench/java/lang/ref/CleanerGC.java line 45:
>> 
>>> 43: 
>>> 44:     // Deliberately a linked list to avoid exposing external parallelism to GC.
>>> 45:     Target prev;
>> 
>> Is `CleanerGC.prev` used?
>
> Yes. It maintains the root of a reachable linked list of `Target`-s.

Doesn't it get covered by the local `prev` in `setup()`? Should that be removed?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1852608976

From vaivanov at openjdk.org  Thu Nov 21 18:02:22 2024
From: vaivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 21 Nov 2024 18:02:22 GMT
Subject: Integrated: 8317542: Specjvm::xml have scalability issue for high vCPU
 numbers
In-Reply-To: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
References: <BvMAkR3Ti86iDt2bbhU7EDW1Q5hf9_DOUsFCicwn7WA=.c0dd1f2e-258f-4dcb-9678-8bbe1c96b598@github.com>
Message-ID: <9XCIK9CoAhiGVyVLskfmImxK9JY6M1DAXGKSeHDgA94=.65862f33-d6cf-484b-8ab8-a45b669693f6@github.com>

On Thu, 31 Oct 2024 21:33:11 GMT, Vladimir Ivanov <vaivanov at openjdk.org> wrote:

> The synchronization block may be substituted by the 'volatile' variable smaller synchronization block.
> It reduce the total blocking time for the specjvm2008::xml.validation workload and improve the reported score.
> Scores for the 112vCPU on the with 28GB heap increased from 17915.83 to 22943.2.
> Unit tests was not affected:
> Test summary
> ==============================
>    TEST                                              TOTAL  PASS  FAIL ERROR
>    jtreg:test/jaxp                                     516   516     0     0
>    jtreg:test/jdk/javax/xml                             70    70     0     0
> ==============================
> TEST SUCCESS
> 
> The tier1 is OK too.

This pull request has now been integrated.

Changeset: 78e5008e
Author:    Vladimir Ivanov <vaivanov at openjdk.org>
Committer: Derek White <drwhite at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/78e5008e91610847bc11103e667fbe602b03d86a
Stats:     43 lines in 1 file changed: 9 ins; 4 del; 30 mod

8317542: Specjvm::xml have scalability issue for high vCPU numbers

Reviewed-by: joehw

-------------

PR: https://git.openjdk.org/jdk/pull/21815

From shade at openjdk.org  Thu Nov 21 18:05:24 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Nov 2024 18:05:24 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <Kr-Nu7aIe-XMXUk7z-bcHLgETmFTydVL0Dhd-BEAk-c=.1057b873-0680-4712-acef-42798fad4114@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
 <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>
 <DJyCJZwSTn5kYnP3BrOsYvklgxa82tKD1IGgLw5IWmo=.b50e7d38-4829-49fa-bbe4-bbb3327efbae@github.com>
 <Kr-Nu7aIe-XMXUk7z-bcHLgETmFTydVL0Dhd-BEAk-c=.1057b873-0680-4712-acef-42798fad4114@github.com>
Message-ID: <-fFVhjJW_mSK-o04Tqt_yM_tryDV12SVlZUkogHowv4=.09c52da1-be2d-4393-9bc4-aedc390e95ed@github.com>

On Thu, 21 Nov 2024 17:53:00 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> Yes. It maintains the root of a reachable linked list of `Target`-s.
>
> Doesn't it get covered by the local `prev` in `setup()`? Should that be removed?

No. Local `prev` variable goes out of scope when `setup()` finishes, making the whole thing eligible for GC. We need something that keeps the list alive, like a benchmark object field, which `CleanerGC.prev` is.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1852623921

From rriggs at openjdk.org  Thu Nov 21 18:06:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Nov 2024 18:06:22 GMT
Subject: RFR: 8344319: SM cleanup in jdk.dynalink module [v2]
In-Reply-To: <lNYFBGkoInEWGNJboEldmaL2DPTGK2xlNp6onJkfRA8=.f0b1385b-bb66-4147-bf15-e6dffe6f7334@github.com>
References: <79R1QnFEgi1V0DdPbtMnWmSZ5d5NSiWhzEMJljNipBI=.72879e2a-a56c-4053-b38a-6d9b7fabb6a2@github.com>
 <lNYFBGkoInEWGNJboEldmaL2DPTGK2xlNp6onJkfRA8=.f0b1385b-bb66-4147-bf15-e6dffe6f7334@github.com>
Message-ID: <ZUveamjbbjEpOGbvLx8mFM5XRWTxf0q2HaoRgV52V-U=.39f59815-b93c-4309-98cf-4afd89a0aa1e@github.com>

On Sat, 16 Nov 2024 15:57:28 GMT, Attila Szegedi <attila at openjdk.org> wrote:

>> Roger Riggs has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   Apply review comments:
>>   Retain public static constants for permission names to avoid source/binary compatible changes that affect cross version use.
>>   Remove obsolete mention of security considerations.
>>   (The protected constructor is retained to avoid changing the access for subclass use)
>
> Hey Roger, thanks for doing this no doubt unglamorous maintenance task. I reviewed it, and it mostly looks good, there's few things I thought about maybe taking a step further (and one thing I'd prefer was taken a step back ?)

@szegedi Please review again

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22152#issuecomment-2491923569

From rriggs at openjdk.org  Thu Nov 21 18:06:22 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Nov 2024 18:06:22 GMT
Subject: Integrated: 8344549: Cleanup AccessController in sun.misc.Unsafe
In-Reply-To: <k0e_3Hw7ViOlbX49AefxfoHtO2q7IbdyCKLxbRAUp0o=.43b2b136-70b1-41a4-a72c-a605873b1b83@github.com>
References: <k0e_3Hw7ViOlbX49AefxfoHtO2q7IbdyCKLxbRAUp0o=.43b2b136-70b1-41a4-a72c-a605873b1b83@github.com>
Message-ID: <vchxSIjY083T51WeB5h7CC5Cu7UjorUjnUhKrULh8W0=.afeaa045-c6a2-4598-b554-2525f628fdf3@github.com>

On Tue, 19 Nov 2024 15:58:30 GMT, Roger Riggs <rriggs at openjdk.org> wrote:

> Unwrap calls using doPrivileged in jdk.unsupported sun.misc.Unsafe.

This pull request has now been integrated.

Changeset: 191b38e7
Author:    Roger Riggs <rriggs at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/191b38e71279151d0444bb38b659e880e6f8a1e7
Stats:     16 lines in 1 file changed: 0 ins; 12 del; 4 mod

8344549: Cleanup AccessController in sun.misc.Unsafe

Reviewed-by: alanb

-------------

PR: https://git.openjdk.org/jdk/pull/22242

From duke at openjdk.org  Thu Nov 21 18:06:25 2024
From: duke at openjdk.org (monk)
Date: Thu, 21 Nov 2024 18:06:25 GMT
Subject: RFR: 8343377: Performance regression in reflective invocation of
 native methods
In-Reply-To: <iM5eRAb6zYxQV72lVNSiEUgdVBZ_boeeJd3YKrtFjAI=.0e373b0b-6905-4483-b089-80ea66b179e4@github.com>
References: <oIKquJomg_qFQffUi-t9kux0_PIDcZjiBzT8DdgUQ_E=.06a95414-fd30-4ada-b06e-ce5d9ede8765@github.com>
 <iM5eRAb6zYxQV72lVNSiEUgdVBZ_boeeJd3YKrtFjAI=.0e373b0b-6905-4483-b089-80ea66b179e4@github.com>
Message-ID: <P6oBh6bfBOdi-cMCm2XAJ4-6qqdsTeqto0P2jROaQJ4=.4a8fd7df-b471-4424-8db0-3360faf03aa6@github.com>

On Thu, 21 Nov 2024 03:28:29 GMT, Chen Liang <liach at openjdk.org> wrote:

>> When core reflection was migrated to be implemented by Method Handles, somehow, the method handles are not used for native methods, which are generally linkable by method handles.  This causes significant performance regressions when reflecting native methods, even if their overrides may be non-native methods.  This is evident in `Object.clone` and `Object.hashCode` as shown in the original report.
>> 
>> I believe the blanket restriction previously placed on the native methods was because of signature polymorphic methods ([JLS 15.12.3](https://docs.oracle.com/javase/specs/jls/se23/html/jls-15.html#jls-15.12.3), [JVMS 2.9.3](https://docs.oracle.com/javase/specs/jvms/se23/html/jvms-2.html#jvms-2.9.3)) for MethodHandle and VarHandle; method handles do not link to the backing implementation that throws UOE while core reflection is required to do so.  I have narrowed the restrictions to be specifically against these methods.
>> 
>> Additionally, I cleaned up another check for invalid varargs flag.  Together, I clarified the scenarios where native method accessors are used - all to bypass restrictions of java.lang.invoke.
>> 
>> Testing: tier 1-5 green
>
> Thanks for the test on `Object.hashCode` and `Thread.currentThread` to confirm my guess.
> 
> For the `toString` test:
> 1. I don't think I will fix it as part of this PR; we will create a new issue for it once we confirm it.
> 2. To reproduce, I think first we will test with JDK 17 and 21. Core reflection reimplementation happened in JDK 18.
> 3. For reliable results, I suggest using the JMH tool https://github.com/openjdk/jmh; there is a gradle plugin for it https://github.com/melix/jmh-gradle-plugin and it has a gradle project example https://github.com/melix/jmh-gradle-plugin/tree/master/samples/simple-java/groovy-dsl, as your raw "setup" and system-time based checks have a lot of disturbance.
> 
>> Because of the bug report web can not submit new comment with some web error
> 
> I am sorry, but OpenJDK infrastructure currently has some known issues; even we are automatically logged out. Thank you for coming to the github PR for comments, @moooonk!

Thank you for your suggestion, @liach 
I reimplement test case project with jmh,if you need to check the source code,see in [https://github.com/moooonk/reflect-test](https://github.com/moooonk/reflect-test)
Now we get more accurate new benchmark result:
JDK17:
Benchmark Mode Cnt Score Error Units
RunBenchmark.cloneCase1 thrpt 5 830871722.632 ? 14902415.558 ops/s
RunBenchmark.cloneCase2 thrpt 5 832256881.789 ? 9305066.153 ops/s
RunBenchmark.cloneCase3 thrpt 5 827842981.397 ? 8629836.251 ops/s
RunBenchmark.hashCodeCase1 thrpt 5 726644716.300 ? 4504879.585 ops/s
RunBenchmark.hashCodeCase2 thrpt 5 726540126.956 ? 7249056.369 ops/s
RunBenchmark.hashCodeCase3 thrpt 5 729054390.940 ? 11904383.303 ops/s
RunBenchmark.toStringCase1 thrpt 5 42906690.075 ? 268508.159 ops/s
RunBenchmark.toStringCase2 thrpt 5 41641490.800 ? 271577.545 ops/s
RunBenchmark.toStringCase3 thrpt 5 41824727.616 ? 440507.690 ops/s

JDK21;
Benchmark Mode Cnt Score Error Units
RunBenchmark.cloneCase1 thrpt 5 8783640.822 ? 46196.518 ops/s
RunBenchmark.cloneCase2 thrpt 5 13045394.145 ? 157121.364 ops/s
RunBenchmark.cloneCase3 thrpt 5 2320020521.800 ? 56423864.542 ops/s
RunBenchmark.hashCodeCase1 thrpt 5 11495229.964 ? 110515.482 ops/s
RunBenchmark.hashCodeCase2 thrpt 5 11488996.620 ? 72449.931 ops/s
RunBenchmark.hashCodeCase3 thrpt 5 1590063332.584 ? 15874384.555 ops/s
RunBenchmark.toStringCase1 thrpt 5 40532553.791 ? 349765.261 ops/s
RunBenchmark.toStringCase2 thrpt 5 40912699.225 ? 339420.788 ops/s
RunBenchmark.toStringCase3 thrpt 5 40991023.028 ? 280145.682 ops/s

I hope this can help you! If need any support just let me know.

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22169#issuecomment-2491923108

From vlivanov at openjdk.org  Thu Nov 21 18:12:25 2024
From: vlivanov at openjdk.org (Vladimir Ivanov)
Date: Thu, 21 Nov 2024 18:12:25 GMT
Subject: RFR: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction [v6]
In-Reply-To: <08UceifyOK3Ybhgtsa0PoYYLUXfNNh0yr4cMRd6EsZQ=.6d7c8ab6-b78c-463e-8be0-dcd14a443528@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
 <08UceifyOK3Ybhgtsa0PoYYLUXfNNh0yr4cMRd6EsZQ=.6d7c8ab6-b78c-463e-8be0-dcd14a443528@github.com>
Message-ID: <342FtKSYnO0pDLHx3TOInsQS2PnqrP_KdkD2p2v3Pvc=.e30f2f1f-f40e-4572-8889-9a95ac55698b@github.com>

On Thu, 21 Nov 2024 09:06:18 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

>> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>>   
>> 
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
>> 
>> 
>> 
>>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
>> 
>> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>>  
>> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
>> 
>> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>>  
>> 
>> Sierra Forest :-
>> ============
>> Baseline:-
>> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
>> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
>> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
>> 
>> With Optimizati...
>
> Jatin Bhateja has updated the pull request incrementally with one additional commit since the last revision:
> 
>   Review comments + extending IR tests with instruction level checks

Marked as reviewed by vlivanov (Reviewer).

-------------

PR Review: https://git.openjdk.org/jdk/pull/21244#pullrequestreview-2452281311

From jbhateja at openjdk.org  Thu Nov 21 18:16:32 2024
From: jbhateja at openjdk.org (Jatin Bhateja)
Date: Thu, 21 Nov 2024 18:16:32 GMT
Subject: Integrated: 8341137: Optimize long vector multiplication using x86
 VPMUL[U]DQ instruction
In-Reply-To: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
References: <9ce1Y2QVr-uGEPquCA1wytF7Sn4px-wQx5tuUQYQNb8=.253ecb32-0976-42ba-bfaa-1903168fdfe6@github.com>
Message-ID: <ORdsgXJEc1MPrIgpZSLadZ5TrQMsOwbkqFI87X6j__0=.49431b25-49d9-4722-ae0c-f2d4f5e7c0c4@github.com>

On Sun, 29 Sep 2024 04:21:19 GMT, Jatin Bhateja <jbhateja at openjdk.org> wrote:

> This patch optimizes LongVector multiplication by inferring VPMUL[U]DQ instruction for following IR pallets.
>   
> 
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF)   ( AndV  SRC2,  0xFFFFFFFF) 
>        MulVL   (URShiftVL SRC1 , 32) (URShiftVL SRC2, 32)
>        MulVL   (URShiftVL SRC1 , 32)  ( AndV  SRC2,  0xFFFFFFFF)
>        MulVL   ( AndV  SRC1,  0xFFFFFFFF) (URShiftVL SRC2 , 32)
>        MulVL   (VectorCastI2X SRC1) (VectorCastI2X SRC2)
>        MulVL   (RShiftVL SRC1 , 32) (RShiftVL SRC2, 32)
> 
> 
> 
>  A  64x64 bit multiplication produces 128 bit result, and can be performed by individually multiplying upper and lower double word of multiplier with multiplicand and assembling the partial products to compute full width result. Targets supporting vector quadword multiplication have separate instructions to compute upper and lower quadwords for 128 bit result. Therefore existing VectorAPI multiplication operator expects shape conformance between source and result vectors.
> 
> If upper 32 bits of quadword multiplier and multiplicand is always set to zero then result of multiplication is only dependent on the partial product of their lower double words and can be performed using unsigned 32 bit multiplication instruction with quadword saturation. Patch matches this pattern in a target dependent manner without introducing new IR node.
>  
> VPMUL[U]DQ instruction performs [unsigned] multiplication between even numbered doubleword lanes of two long vectors and produces 64 bit result.  It has much lower latency compared to full 64 bit multiplication instruction "VPMULLQ", in addition non-AVX512DQ targets does not support direct quadword multiplication, thus we can save redundant partial product for zeroed out upper 32 bits. This results into throughput improvements on both P and E core Xeons.
> 
> Please find below the performance of [XXH3 hashing benchmark ](https://mail.openjdk.org/pipermail/panama-dev/2024-July/020557.html)included with the patch:-
>  
> 
> Sierra Forest :-
> ============
> Baseline:-
> Benchmark                                 (SIZE)   Mode  Cnt    Score   Error   Units
> VectorXXH3HashingBenchmark.hashingKernel    1024  thrpt    2  806.228          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    2048  thrpt    2  403.044          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    4096  thrpt    2  200.641          ops/ms
> VectorXXH3HashingBenchmark.hashingKernel    8192  thrpt    2  100.664          ops/ms
> 
> With Optimization:-
> Benchmark                                 (SIZE)   Mode  ...

This pull request has now been integrated.

Changeset: dc9a6ef6
Author:    Jatin Bhateja <jbhateja at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/dc9a6ef6100d73a431cd0cfa2c252acf7743f8a3
Stats:     544 lines in 7 files changed: 543 ins; 0 del; 1 mod

8341137: Optimize long vector multiplication using x86 VPMUL[U]DQ instruction

Co-authored-by: Vladimir Ivanov <vlivanov at openjdk.org>
Reviewed-by: vlivanov, sviswanathan

-------------

PR: https://git.openjdk.org/jdk/pull/21244

From bchristi at openjdk.org  Thu Nov 21 18:23:17 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 21 Nov 2024 18:23:17 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <-fFVhjJW_mSK-o04Tqt_yM_tryDV12SVlZUkogHowv4=.09c52da1-be2d-4393-9bc4-aedc390e95ed@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
 <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>
 <DJyCJZwSTn5kYnP3BrOsYvklgxa82tKD1IGgLw5IWmo=.b50e7d38-4829-49fa-bbe4-bbb3327efbae@github.com>
 <Kr-Nu7aIe-XMXUk7z-bcHLgETmFTydVL0Dhd-BEAk-c=.1057b873-0680-4712-acef-42798fad4114@github.com>
 <-fFVhjJW_mSK-o04Tqt_yM_tryDV12SVlZUkogHowv4=.09c52da1-be2d-4393-9bc4-aedc390e95ed@github.com>
Message-ID: <W-LZ4X1hQU_ifhijXx5g4Fg7s8jRJjraPQGD9vyqQ2M=.56647498-d27c-47e1-abde-c4d1cdfe8ff1@github.com>

On Thu, 21 Nov 2024 18:02:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Doesn't it get covered by the local `prev` in `setup()`? Should that be removed?
>
> No. Local `prev` variable goes out of scope when `setup()` finishes, making the whole thing eligible for GC. We need something that keeps the list alive, like a benchmark object field, which `CleanerGC.prev` is.

Sorry for being dense, but where is a value being set to `CleanerGC.prev` ?

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1852645989

From shade at openjdk.org  Thu Nov 21 18:32:19 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Nov 2024 18:32:19 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <W-LZ4X1hQU_ifhijXx5g4Fg7s8jRJjraPQGD9vyqQ2M=.56647498-d27c-47e1-abde-c4d1cdfe8ff1@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
 <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>
 <DJyCJZwSTn5kYnP3BrOsYvklgxa82tKD1IGgLw5IWmo=.b50e7d38-4829-49fa-bbe4-bbb3327efbae@github.com>
 <Kr-Nu7aIe-XMXUk7z-bcHLgETmFTydVL0Dhd-BEAk-c=.1057b873-0680-4712-acef-42798fad4114@github.com>
 <-fFVhjJW_mSK-o04Tqt_yM_tryDV12SVlZUkogHowv4=.09c52da1-be2d-4393-9bc4-aedc390e95ed@github.com>
 <W-LZ4X1hQU_ifhijXx5g4Fg7s8jRJjraPQGD9vyqQ2M=.56647498-d27c-47e1-abde-c4d1cdfe8ff1@github.com>
Message-ID: <4cQDnwHm4g064xamIo5j-09IwV_wGezS1cjOFNzpaqo=.e9e54317-b54b-4104-9df5-c97ee92faa16@github.com>

On Thu, 21 Nov 2024 18:20:10 GMT, Brent Christian <bchristi at openjdk.org> wrote:

>> No. Local `prev` variable goes out of scope when `setup()` finishes, making the whole thing eligible for GC. We need something that keeps the list alive, like a benchmark object field, which `CleanerGC.prev` is.
>
> Sorry for being dense, but where is a value being set to `CleanerGC.prev` ?

Ah (facepalms), I see, I thought I assigned it! Damn. Let me fix and re-measure.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1852657935

From asemenyuk at openjdk.org  Thu Nov 21 18:41:29 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 21 Nov 2024 18:41:29 GMT
Subject: RFR: 8344770: Switch jpackage unit tests to use JUnit5
Message-ID: <uaz_lkvplj42oPKaBMezy3R6uti7ux6VMNkydnpoTMA=.3d22de63-033b-480b-b8a7-00a72972f02c@github.com>

Switched jpackage unit tests to use JUnit5.
Got rid of dependencies on the "hamcrest".

-------------

Commit messages:
 - All tests pass
 - Merge branch 'master' into JDK-8333571
 - Copyright year update
 - Run `bin/blessed-modifier-order.sh` script
 - 8333571: Replace ExpectedException with assertThrows() calls in jpackage unit tests

Changes: https://git.openjdk.org/jdk/pull/22302/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22302&range=00
  Issue: https://bugs.openjdk.org/browse/JDK-8344770
  Stats: 1142 lines in 11 files changed: 388 ins; 385 del; 369 mod
  Patch: https://git.openjdk.org/jdk/pull/22302.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22302/head:pull/22302

PR: https://git.openjdk.org/jdk/pull/22302

From rriggs at openjdk.org  Thu Nov 21 18:41:46 2024
From: rriggs at openjdk.org (Roger Riggs)
Date: Thu, 21 Nov 2024 18:41:46 GMT
Subject: RFR: 8344336: SM cleanup of java.lang.System, Runtime, String,
 StackWalker [v3]
In-Reply-To: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
References: <bLw-2QtMOTJHCgzkS3glb4huakYLqNQgpmeUmARx7Bg=.3a4b0354-0a16-475c-aaa7-b23f851fa70d@github.com>
Message-ID: <quCVLqdjRFAtGvdjv3VTfEOb4A0jikcj3KQHyBFEEQA=.d4a757f4-2177-4485-98c7-85ea6f813396@github.com>

> Removed use of SecurityManager to check permissions.
> Relaxed defensive copying of byte arrays (due to lack of SM)
> 
> Refresh of PR#22168 Including review comments made there.

Roger Riggs has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains five additional commits since the last revision:

 - Merge branch 'master' into 8344336-sm-lang-system-runtime
 - Remove latent permission and checkPermission.
 - Refactor package private method `codeSource` into Module where it is used.
   Cleanup doPrivileged in LoggerFinder `accessProvider`, no longer needed.
 - Review suggestions applied:
   Remove SecurityExceptions from LiveStackFrame
   Rename safeTrim to trimArray
 - 8344336: SM cleanup of java.lang.System, Runtime, String, StackWalker
   Removed use of SecurityManager to check permissions
   Relaxed defensive copying of byte arrays (due to lack of SM)

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22282/files
  - new: https://git.openjdk.org/jdk/pull/22282/files/a6e71664..909e4ca3

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22282&range=02
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22282&range=01-02

  Stats: 5502 lines in 213 files changed: 1859 ins; 2430 del; 1213 mod
  Patch: https://git.openjdk.org/jdk/pull/22282.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22282/head:pull/22282

PR: https://git.openjdk.org/jdk/pull/22282

From asemenyuk at openjdk.org  Thu Nov 21 18:51:38 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 21 Nov 2024 18:51:38 GMT
Subject: RFR: 8344587: Reduce number of "jdk.jpackage.internal" classes
 used from other packages [v2]
In-Reply-To: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
References: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
Message-ID: <kbpwR8axKg6zVt_rB6pMYdgVt7dE7YI757Ke1bJHKe8=.b91a2733-243b-4d03-aa45-64f2d9c6f8cb@github.com>

> Stop using internal AppImageFile, ApplicationLayout, and PackageFile classes in the tests. Replace them with stubs.
> 
> Stop referencing IOUtils class from XmlUtils and PathUtils classes.

Alexey Semenyuk has updated the pull request incrementally with one additional commit since the last revision:

  Update test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
  
  Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22261/files
  - new: https://git.openjdk.org/jdk/pull/22261/files/9d1f097d..e943bc93

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22261&range=01
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22261&range=00-01

  Stats: 1 line in 1 file changed: 0 ins; 0 del; 1 mod
  Patch: https://git.openjdk.org/jdk/pull/22261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22261/head:pull/22261

PR: https://git.openjdk.org/jdk/pull/22261

From shade at openjdk.org  Thu Nov 21 19:33:01 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Nov 2024 19:33:01 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v15]
In-Reply-To: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
Message-ID: <a2Bc7tmbi41kIk09Mn0gmAY0L_qBkeHmpxKOGQvPci8=.20e3f207-e130-4aff-989e-29e723275ada@github.com>

> See the bug for more discussion and reproducer. This PR replaces the ad-hoc linked list with segmented list of arrays. Arrays are easy targets for GC. There are possible improvements here, most glaring is parallelism that is currently knee-capped by global synchronization. The synchronization scheme follows what we have in original code, and I think it is safer to continue with it right now.
> 
> I'll put performance data in a separate comment.
> 
> Additional testing:
>  - [x] Original reproducer improves drastically
>  - [x] New microbenchmark shows no regression on "churning" tests, which covers insertion/removal perf
>  - [x] New microbenchmark shows improvement on Full GC times (crude, but repeatable), serves as a proxy for reproducer
>  - [x] `java/lang/ref` tests in release 
>  - [x] `all` tests in fastdebug

Aleksey Shipilev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 17 additional commits since the last revision:

 - Merge branch 'master' into JDK-8343704-cleaner-gc
 - Improve CleanerGC benchmark
 - Check all elements are removable after random test
 - Use RandomFactory in test
 - Touchups
 - Merge branch 'master' into JDK-8343704-cleaner-gc
 - Drop --add-exports from the test
 - prev is not needed
 - Do not need -ea -esa in tests, our testing infra adds them already
 - Add the node cache
 - ... and 7 more: https://git.openjdk.org/jdk/compare/50dada36...507401c7

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22043/files
  - new: https://git.openjdk.org/jdk/pull/22043/files/63322b76..507401c7

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=14
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22043&range=13-14

  Stats: 6634 lines in 338 files changed: 2518 ins; 2838 del; 1278 mod
  Patch: https://git.openjdk.org/jdk/pull/22043.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22043/head:pull/22043

PR: https://git.openjdk.org/jdk/pull/22043

From shade at openjdk.org  Thu Nov 21 19:33:02 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Nov 2024 19:33:02 GMT
Subject: RFR: 8343704: Bad GC parallelism with processing Cleaner queues
 [v14]
In-Reply-To: <4cQDnwHm4g064xamIo5j-09IwV_wGezS1cjOFNzpaqo=.e9e54317-b54b-4104-9df5-c97ee92faa16@github.com>
References: <RYZ0ABtcTzZaxCRg00dSAeAwoDGCZRbgt0zEAk5roI8=.c5442fe4-83d6-4d78-910a-b075c4e5d728@github.com>
 <civFTLvJRMLrAq8iYXI_2Z1zqN8AR-hLGiJAetkM5zA=.09c48290-8748-4b77-960a-8a769cac35df@github.com>
 <XZlnv040mBScDx1mn5af6SHpiG_a7T73odxsFwC1x6A=.e13449f8-3edd-4737-ba30-8d3e49bea850@github.com>
 <DJyCJZwSTn5kYnP3BrOsYvklgxa82tKD1IGgLw5IWmo=.b50e7d38-4829-49fa-bbe4-bbb3327efbae@github.com>
 <Kr-Nu7aIe-XMXUk7z-bcHLgETmFTydVL0Dhd-BEAk-c=.1057b873-0680-4712-acef-42798fad4114@github.com>
 <-fFVhjJW_mSK-o04Tqt_yM_tryDV12SVlZUkogHowv4=.09c52da1-be2d-4393-9bc4-aedc390e95ed@github.com>
 <W-LZ4X1hQU_ifhijXx5g4Fg7s8jRJjraPQGD9vyqQ2M=.56647498-d27c-47e1-abde-c4d1cdfe8ff1@github.com>
 <4cQDnwHm4g064xamIo5j-09IwV_wGezS1cjOFNzpaqo=.e9e54317-b54b-4104-9df5-c97ee92faa16@github.com>
Message-ID: <h8wEz8nQKdWYq849hZUI3PmQq51XGBe5U2PwKQssh8E=.4e423e66-59dc-4961-be84-cf7c6aa5ca22@github.com>

On Thu, 21 Nov 2024 18:29:24 GMT, Aleksey Shipilev <shade at openjdk.org> wrote:

>> Sorry for being dense, but where is a value being set to `CleanerGC.prev` ?
>
> Ah (facepalms), I see, I thought I assigned it! Damn. Let me fix and re-measure.

Redone the benchmark. We actually want all targets to be reachable, and only expose the Cleaner-side linked lists to the test. New performance data is updated here: https://github.com/openjdk/jdk/pull/22043#issuecomment-2470928360

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22043#discussion_r1852730179

From shade at openjdk.org  Thu Nov 21 19:38:15 2024
From: shade at openjdk.org (Aleksey Shipilev)
Date: Thu, 21 Nov 2024 19:38:15 GMT
Subject: RFR: 8339916: AIOOBE due to Math.abs(Integer.MIN_VALUE) in tests
In-Reply-To: <homWspYkM-vp63SYt6Gwwuy9Vc3rxhVD6v0W83nW91c=.aed07065-c38d-4e41-b503-08411a7efbad@github.com>
References: <homWspYkM-vp63SYt6Gwwuy9Vc3rxhVD6v0W83nW91c=.aed07065-c38d-4e41-b503-08411a7efbad@github.com>
Message-ID: <xvbJ-vpstSdfjkCt8DHtlKXoR-tmB_IIVU13IfRIqT4=.15856f74-799e-4a3e-be8d-c0c5bbae0132@github.com>

On Thu, 21 Nov 2024 17:21:07 GMT, Andrew Haley <aph at openjdk.org> wrote:

> Test bug.
> 
> Another bug caused by the result of `Math.abs()` being negative. I also tried `floorMod()`, which would have been cleaner, but it increased the runtime of this extremely time-sensitive benchmark.

It is like computers are bad at computing or something something.

-------------

Marked as reviewed by shade (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22297#pullrequestreview-2452452508

From jlu at openjdk.org  Thu Nov 21 19:42:19 2024
From: jlu at openjdk.org (Justin Lu)
Date: Thu, 21 Nov 2024 19:42:19 GMT
Subject: RFR: 8319993: Update Unicode Data Files to 16.0.0
In-Reply-To: <lhjftuxraeNfYcmqtLlHjH0COs5-oyjaZlz_oMsoUG0=.5c1fc0e0-781d-4610-ab0c-6ed8fd4b525c@github.com>
References: <lhjftuxraeNfYcmqtLlHjH0COs5-oyjaZlz_oMsoUG0=.5c1fc0e0-781d-4610-ab0c-6ed8fd4b525c@github.com>
Message-ID: <qpEBCQ6FDje5WPpgwF1kqPLsG-zQhqBa8ljB6mN_cVA=.f08fcd8c-2286-4c60-a909-5f3483e6fd53@github.com>

On Tue, 29 Oct 2024 18:01:55 GMT, Naoto Sato <naoto at openjdk.org> wrote:

> Updates the JDK to use the latest Unicode 16.0.0, which also updates the ICU4J along with it (8319992: Update ICU4J to Version 76.1). The corresponding CSR has already been approved.

Marked as reviewed by jlu (Committer).

src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 38:

> 36:      * See Unicode Standard Annex #29 Unicode Text Segmentation for the specification
> 37:      * for the extended grapheme cluster boundary rules. The following implementation
> 38:      * is based on the annex for Unicode version 15.1.

Could bump the version 15.1 to 16.0

src/java.base/share/classes/jdk/internal/util/regex/Grapheme.java line 272:

> 270:             //  Kirat Rai vowel sign
> 271:             if (cp >= 0xD7B0 && cp <= 0xD7C6 ||
> 272:                 cp == 0x16D63 ||

LGTM as this matches up with https://www.unicode.org/reports/tr29/tr29-45.html#V and the `case 0x113D1:` lines up with _TULU-TIGALARI REPHA_.

-------------

PR Review: https://git.openjdk.org/jdk/pull/21771#pullrequestreview-2450437524
PR Review Comment: https://git.openjdk.org/jdk/pull/21771#discussion_r1851471389
PR Review Comment: https://git.openjdk.org/jdk/pull/21771#discussion_r1852722645

From asemenyuk at openjdk.org  Thu Nov 21 19:48:31 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 21 Nov 2024 19:48:31 GMT
Subject: RFR: 8344587: Reduce number of "jdk.jpackage.internal" classes
 used from other packages [v3]
In-Reply-To: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
References: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
Message-ID: <305b0oe6_L0Dl_qgNvcfEUJk11nzOvC-s9rz2iFpYsQ=.94a79d97-a10c-4280-b5b4-3139c116ef32@github.com>

> Stop using internal AppImageFile, ApplicationLayout, and PackageFile classes in the tests. Replace them with stubs.
> 
> Stop referencing IOUtils class from XmlUtils and PathUtils classes.

Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:

 - Merge branch 'JDK-8344587' of https://github.com/alexeysemenyukoracle/jdk into JDK-8344587
 - Update test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
   
   Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
 - Merge branch 'master' into JDK-8344587
 - Minor improvements
 - Make IOUtils class package-private
 - Bugfix & cleanup
 - Merge branch 'master' into SplitIOUtils.DecoupleAppImageFile
 - Bad merge fix
 - Bad merge fix
 - Make AppImageFile and PackageFile classes package-private
 - ... and 17 more: https://git.openjdk.org/jdk/compare/93d4ad4d...4957927a

-------------

Changes: https://git.openjdk.org/jdk/pull/22261/files
  Webrev: https://webrevs.openjdk.org/?repo=jdk&pr=22261&range=02
  Stats: 381 lines in 21 files changed: 288 ins; 61 del; 32 mod
  Patch: https://git.openjdk.org/jdk/pull/22261.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22261/head:pull/22261

PR: https://git.openjdk.org/jdk/pull/22261

From asemenyuk at openjdk.org  Thu Nov 21 19:52:18 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 21 Nov 2024 19:52:18 GMT
Subject: RFR: 8344770: Switch jpackage unit tests to use JUnit5
In-Reply-To: <uaz_lkvplj42oPKaBMezy3R6uti7ux6VMNkydnpoTMA=.3d22de63-033b-480b-b8a7-00a72972f02c@github.com>
References: <uaz_lkvplj42oPKaBMezy3R6uti7ux6VMNkydnpoTMA=.3d22de63-033b-480b-b8a7-00a72972f02c@github.com>
Message-ID: <BRYhBUBwP7Vg0QU28isw35gH2NQm6fdt6ZBq6moKAoM=.2fafaf22-8235-4b24-895b-a3943346eb1d@github.com>

On Thu, 21 Nov 2024 18:35:56 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

> Switched jpackage unit tests to use JUnit5.
> Got rid of dependencies on the "hamcrest".

@sashamatveev ptal

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22302#issuecomment-2492126711

From eirbjo at openjdk.org  Thu Nov 21 20:07:23 2024
From: eirbjo at openjdk.org (Eirik =?UTF-8?B?QmrDuHJzbsO4cw==?=)
Date: Thu, 21 Nov 2024 20:07:23 GMT
Subject: Integrated: 8178966: Don't swallow early bootstrap exceptions in
 Boolean.getBoolean, Integer.getInteger and Long.getLong
In-Reply-To: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
References: <liN7XKvbi8PuzJtrT4u9zd9PcR30ZJAngoIdGVJ_CZA=.0fa74e23-45ae-41c6-be3d-2d7cd4721f66@github.com>
Message-ID: <_45XT7SR8CwmxsYa3r5IjSOUG5xG23K6BoZRcWepyQs=.9a83bf4b-869d-47af-9aef-fc37437306f6@github.com>

On Sun, 17 Nov 2024 14:52:06 GMT, Eirik Bj?rsn?s <eirbjo at openjdk.org> wrote:

> Please review this PR which removes exceptional control flow in `Boolean::getBoolean`, `Integer::getInteger` and `Long::getLong`.
> 
> These methods are catching `IllegalArgumentException` and `NullPointerException`, thrown by `System::getProperty` via `System::checkKey`. This PR replaces the exceptional control flow with explicit checks that the system property name is non-null and non-empty before calling into `System::getProperty`.
> 
> As JDK-8178966 points out, there is a possibility that System.getProperty could throw one of NPE and IAE for other reasons than the name being null or empty. This risk is reduced now that custom security managers cannot interfere. Adding to that, if such exceptions are thrown today, they are masked by these methods catching and swallowing them by returning false or default values. It's better to expose such  bugs if they exist.
> 
> GHA results pending. Local tier2 ran successfully.

This pull request has now been integrated.

Changeset: e03b1506
Author:    Eirik Bj?rsn?s <eirbjo at openjdk.org>
URL:       https://git.openjdk.org/jdk/commit/e03b1506d3644f9e4053630adc4c0620eaef71c0
Stats:     16 lines in 3 files changed: 0 ins; 13 del; 3 mod

8178966: Don't swallow early bootstrap exceptions in Boolean.getBoolean, Integer.getInteger and Long.getLong

Co-authored-by: Peter Levart <plevart at openjdk.org>
Reviewed-by: jpai, rriggs

-------------

PR: https://git.openjdk.org/jdk/pull/22183

From asemenyuk at openjdk.org  Thu Nov 21 20:25:18 2024
From: asemenyuk at openjdk.org (Alexey Semenyuk)
Date: Thu, 21 Nov 2024 20:25:18 GMT
Subject: RFR: 8344587: Reduce number of "jdk.jpackage.internal" classes
 used from other packages [v3]
In-Reply-To: <305b0oe6_L0Dl_qgNvcfEUJk11nzOvC-s9rz2iFpYsQ=.94a79d97-a10c-4280-b5b4-3139c116ef32@github.com>
References: <C_KBkZy2qmJaybdpbKAftjna0UgCDGjwF7hzal7wGb4=.4c568719-558e-46f1-8077-c2705af5233b@github.com>
 <305b0oe6_L0Dl_qgNvcfEUJk11nzOvC-s9rz2iFpYsQ=.94a79d97-a10c-4280-b5b4-3139c116ef32@github.com>
Message-ID: <jhfLYFhrT6L_cxF6OOoDIyCEaZhsNhDzr0izooCQvdY=.c5ea86a3-44c7-474e-9dbd-311155b410cd@github.com>

On Thu, 21 Nov 2024 19:48:31 GMT, Alexey Semenyuk <asemenyuk at openjdk.org> wrote:

>> Stop using internal AppImageFile, ApplicationLayout, and PackageFile classes in the tests. Replace them with stubs.
>> 
>> Stop referencing IOUtils class from XmlUtils and PathUtils classes.
>
> Alexey Semenyuk has updated the pull request with a new target base due to a merge or a rebase. The pull request now contains 27 commits:
> 
>  - Merge branch 'JDK-8344587' of https://github.com/alexeysemenyukoracle/jdk into JDK-8344587
>  - Update test/jdk/tools/jpackage/helpers/jdk/jpackage/test/JPackageCommand.java
>    
>    Co-authored-by: Andrey Turbanov <turbanoff at gmail.com>
>  - Merge branch 'master' into JDK-8344587
>  - Minor improvements
>  - Make IOUtils class package-private
>  - Bugfix & cleanup
>  - Merge branch 'master' into SplitIOUtils.DecoupleAppImageFile
>  - Bad merge fix
>  - Bad merge fix
>  - Make AppImageFile and PackageFile classes package-private
>  - ... and 17 more: https://git.openjdk.org/jdk/compare/93d4ad4d...4957927a

Suggestions addressed. Please review again

-------------

PR Comment: https://git.openjdk.org/jdk/pull/22261#issuecomment-2492193997

From bchristi at openjdk.org  Thu Nov 21 20:32:24 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 21 Nov 2024 20:32:24 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v5]
In-Reply-To: <MGk0o98ETKQ4juQ6cdWNMvxvR0AGvuhqer8FtHVcKf8=.422d7edd-b310-4409-9920-af2fd922e9bc@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
 <zQyQpIWDntULsBt7sYtsRLEqPdt0NA0Y4teWRUn8Jns=.4bc93d94-fb7c-4749-abd5-fa026b406b22@github.com>
 <MGk0o98ETKQ4juQ6cdWNMvxvR0AGvuhqer8FtHVcKf8=.422d7edd-b310-4409-9920-af2fd922e9bc@github.com>
Message-ID: <s04fWvJxn4UldDcxRXFxPQCXey5sn_Cn4_x8MXj_0L4=.e41bb2e0-d56f-405a-841c-d3fb812d5d7d@github.com>

On Thu, 21 Nov 2024 06:50:42 GMT, Andrey Turbanov <aturbanov at openjdk.org> wrote:

>> Brent Christian has updated the pull request incrementally with one additional commit since the last revision:
>> 
>>   indentation fixes
>
> src/java.prefs/unix/classes/java/util/prefs/FileSystemPreferences.java line 577:
> 
>> 575:                 XmlSupport.importMap(fis, m);
>> 576:             }
>> 577:         } catch(Exception e) {
> 
> Suggestion:
> 
>         } catch (Exception e) {

Most catch statements in this file do not have a space.

-------------

PR Review Comment: https://git.openjdk.org/jdk/pull/22252#discussion_r1852840179

From naoto at openjdk.org  Thu Nov 21 20:38:20 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Nov 2024 20:38:20 GMT
Subject: RFR: 8341923: java.util.Locale class specification improvements
 [v4]
In-Reply-To: <xTxbdWdErCsY1XF0SBmcUb7t4iKeuyw6fVFHkEjQ49E=.ac5332aa-f18d-466a-ba74-7e21d8e552d8@github.com>
References: <a8ibOqDLUAn4-KOJtPQtD-FKDX73ZnvMI51UWLuDhPY=.f48b60d9-fe3b-401a-a952-38bbcc6cd843@github.com>
 <xTxbdWdErCsY1XF0SBmcUb7t4iKeuyw6fVFHkEjQ49E=.ac5332aa-f18d-466a-ba74-7e21d8e552d8@github.com>
Message-ID: <sS6Ljxuqd80UqGuVgyEyHVijbHFfC6g5jOzkbzY965M=.ee93eaab-547d-4d2c-9026-c07f4bccd1e2@github.com>

On Thu, 21 Nov 2024 06:53:58 GMT, Justin Lu <jlu at openjdk.org> wrote:

>> Please review this PR and corresponding CSR which includes a wide range of specification improvements for java.util.Locale. See the CSR for further detail. Other changes/suggestions are welcomed to be included as part of this change.
>> 
>> APIDiff: https://cr.openjdk.org/~jlu/8341923_apidiff/java.base/java/util/Locale.html
>> Javadoc: https://cr.openjdk.org/~jlu/api/java.base/java/util/Locale.html
>
> Justin Lu has updated the pull request incrementally with one additional commit since the last revision:
> 
>   reflect review

LGTM. Thanks for the update.

-------------

Marked as reviewed by naoto (Reviewer).

PR Review: https://git.openjdk.org/jdk/pull/22192#pullrequestreview-2452646951

From bchristi at openjdk.org  Thu Nov 21 20:41:36 2024
From: bchristi at openjdk.org (Brent Christian)
Date: Thu, 21 Nov 2024 20:41:36 GMT
Subject: RFR: 8344337: SecurityManager cleanup in java.prefs module [v6]
In-Reply-To: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
References: <VzUNjKENhJUvoZeuh2mnl1tAUytYzsSo4HozecFrWxk=.a4afd437-363a-4989-a292-267999bcd62b@github.com>
Message-ID: <nkt-w9wlVaA_MdFEw40jyWFuRhRiMPC0SdB5ZxSlQhw=.64e5b891-866c-48d7-91b8-4267a45630a5@github.com>

> Remove usages of SecurityManager, doPrivildged, and AccessController from the java.prefs module.

Brent Christian has updated the pull request incrementally with one additional commit since the last revision:

  spacing changes

-------------

Changes:
  - all: https://git.openjdk.org/jdk/pull/22252/files
  - new: https://git.openjdk.org/jdk/pull/22252/files/cddc4e2f..10d3cb4f

Webrevs:
 - full: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=05
 - incr: https://webrevs.openjdk.org/?repo=jdk&pr=22252&range=04-05

  Stats: 19 lines in 1 file changed: 1 ins; 0 del; 18 mod
  Patch: https://git.openjdk.org/jdk/pull/22252.diff
  Fetch: git fetch https://git.openjdk.org/jdk.git pull/22252/head:pull/22252

PR: https://git.openjdk.org/jdk/pull/22252

From naoto at openjdk.org  Thu Nov 21 20:42:57 2024
From: naoto at openjdk.org (Naoto Sato)
Date: Thu, 21 Nov 2024 20:42:57 GMT
Subject: RFR: 8319993: Update Unicode Data Files to 16.0.0 [v2]
In-Reply-To: <lhjftuxraeNfYcmqtLlHjH0COs5-oyjaZlz_oMsoUG0=.5c1fc0e0-781d-4610-ab0c-6ed8fd4b525c@github.com>
References: <lhjftuxraeNfYcmqtLlHjH0COs5-oyjaZlz_oMsoUG0=.5c1fc0e0-781d-4610-ab0c-6ed8fd4b525c@github.com>
Message-ID: <BrxHySXQqOjVuMIYhJ3b4QZrOsiGWxd3sTYUXNhKegY=.73a489a0-d39a-424b-a452-f60c578d05a6@github.com>

> Updates the JDK to use the latest Unicode 16.0.0, which also updates the ICU4J along with it (8319992: Update ICU4J to Version 76.1). The corresponding CSR has already been approved.

Naoto Sato has updated the p